10 prostych sposobów, aby programiści znienawidzili cię

Jeśli pracujesz jako tester, możesz wiedzieć coś na temat relacji tester vs. programista. Musimy współpracować, aby projekt szedł naprzód. Oto dziesięć sposobów, aby zniszczyć tę kruchą równowagę.

  1. Zgłaszaj błędy opisane jak najbardziej ogólnie
    • Tytuł: „System nie działa”
    • Opis: „System po pewnym czasie przestaje działać na moim komputerze
    • Priorytet: krytyczny
  2. Programiści często czują się źle, kiedy w ich kodzie zostanie znaleziony błąd. Możesz wzmocnić ten efekt dokładnie wskazując, kto napisał dany fragment kodu.
  3. Krytykuj publiczne.
  4. Przetestuj nieaktualny build. Zgłoś krytyczny błąd. Pozwól programiście spędzić dzień na analizie problemu. Kiedy w końcu zorientuje się, że testowałeś na starej wersji, na pewno zapamięta twoje imię.
  5. Jeśli masz taką możliwość, wskaż sposób poprawienia błędu i wyznacz deadline.
  6. Nalegaj, aby każdy znaleziony przez ciebie błąd został poprawiony. Nawet jeśli czujesz, że nie warto tego poprawiać.
  7. Eskaluj do przełożonych w projekcie. Zaangażuj ich w długie, techniczne dyskusje prowadzone wyłącznie drogą mailową.
  8. Najlepsze zachowaj na koniec. Blokujący dostawę, krytyczny błąd zgłaszaj tuż przed końcem etapu testów. Liczy się efekt WOW i miny deweloperów.
  9. Zgłaszaj zduplikowane raporty błędów. Nie spędzaj swojego czasu na przeglądnięcie listy istniejących defektów.
  10. Przerywaj im regularnie, kiedy kodują. Powrót do rytmu pracy zajmuje średnio 20 minut. Ale to nie twoje minuty.

Bug priority vs. bug severity

Zgłaszając błąd aplikacji, oprócz jego opisu, wersji środowiska, zrzutu ekranu czy załączników, określamy również jego priorytet i wpływ na działanie aplikacji.

Defect severity – określa jak bardzo krytyczny dla aplikacji jest zgłaszany błąd.
Defect priority – oznacza jak pilne jest poprawienie błędu.

Opis na przykładzie:
1. High Severity and Low Priority : Testujemy aplikację bankową generującą raporty tygodniowy, miesięczny i roczny. W raporcie rocznym jest błąd, który powoduje generowanie niewłaściwych danych. Jest to błąd krytyczny (high severity) jednak może zostać poprawiony w następnej wersji aplikacji (low priority).

2. Low Severity and High Priority : Błąd ortograficzny na głównej stronie popularnego serwisu internetowego. Pomimo, że nie ma on wpływu na funkcjonowanie strony, może przyczynić się do obniżenia wizerunku witryny.

3. High Severity and High Priority : Ponownie aplikacja bankowa. Tym razem błąd występuje w raporcie tygodniowym. Oprócz zagrożenia dla poprawności generowanych wyników, decydujący jest czas od zgłoszenia do naprawy błędu.

4. Low Severity and Low Priority : Błąd ortograficzny występuje na podstronie o oglądalności kilku wejść na miesiąc.

Testy ad-hoc, eksploracyjne

Ten typ testów przeprowadzany jest bez tworzenia formalnego Test Planu czy pisania przypadków testowych. Testy typu ad-hoc pomagają planować zakres i czas trwania innych rodzajów testów, pomagają także testerom nauczyć się aplikacji przed rozpoczęciem zaplanowanych, innych rodzajów testów. Jest to najmniej formalna metoda testowania.

Testy ad-hoc (eksploracyjne) oznaczają jednoczesne poznawanie testowanej aplikacji, przygotowywanie dokumentacji testowej i wykonywanie testów. Oznacza to, że testerzy przystępują do pracy bez przygotowanych wcześniej przypadków użycia (test cases), ale za to z wyznaczonym celem. Testy oprogramowania tą metodą pozwalają na odkrycie nowych, zależności pomiędzy np. modułami systemu. To z kolei może wpłynąć na przyjętą strategię testowania i akcje podejmowane w kolejnych iteracjach testów.

Jednym z najlepszych powodów do stosowania tego rodzaju testów jest “odkrywanie”. Czytanie wymagań czy specyfikacji (jeśli istnieje) nie daje kompletnego obrazu działania systemu. Również dokumentacja użytkownika (pliki help, tutoriale) nie oddaje całkowicie tego w jaki sposób system działa i jak zachowuje się w określonych sytuacjach.

Testy metodą ad-hoc pozwalają na znalezienie “dziur” w strategii testowania i ujawnienie np. brakujących przypadków testowych (Test Cases).

Błędy znalezione przy testowaniu metodą ad-hoc są często sygnałem o istnieniu całych klas nieopracowanych przypadków testowych. To z kolei sugeruje dokonanie analizy przyczyn powstania błędu w testowanej części aplikacji.

Drugim zastosowaniem techniki ad-hoc jest określanie priorytetów dla poszczególnych przypadków testowych. Funkcjonalności, które działają poprawnie podczas testów ad-hoc, mogą otrzymać niższy priorytet lub zostać odłożone podczas fazy formalnych testów.

Jednym z problemów związanych z testami eksploracyjnymi są metryki, a właściwie ich brak. Zazwyczaj projekt jest zainteresowany informacją na temat postępu testów (procentowym pokryciem testami funkcjonalności, ilością wykonanych przypadków testowych, których przecież nie ma, itp.) wyrażoną choćby w postaci cyfr. Rozwiązaniem mogą być np. organizowane okresowo sesje na których zespół testowy wraz z osobami zainteresowanymi takimi informacjami, przedstawia i dyskutuje bieżącą sytuację. Taka forma pomiaru sprawdza się w projektach prowadzonych wg metodologii Agile.

Jak efektywnie zgłaszać błędy

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
– Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

– Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

– Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

– Nie wyolbrzymiaj znaczenia błędu w opisie.

– Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Testy regresywne

Celem przeprowadzania testów regresywnych jest upewnienie się, że aplikacja działa po dokonaniu w niej modyfikacji, poprawieniu błędów lub po dodaniu nowej funkcjonalności.

Cecha: powtarzalność

Co dają testy regresywne:

  • Wyszukanie błędów powstałych w wyniku zmian kodu/środowiska.
  • Ujawnienie wcześniej nie odkrytych błędów.
  • Jest to dobry kandydat do automatyzacji ze względu na swoją powtarzalność.

Iteracyjne metodologie oraz krótkie cykle w których dostarczane są kolejne funkcjonalności powodują, że testy regresywne pozwalają upewnić się czy nowe funkcjonalności nie wpłynęły negatywnie na istniejące już i działające części systemu.

Testy regresywne mogą być przeprowadzane dla kompletnego produktu lub jego części.  Jeżeli pomiędzy cyklami testów nie można przeprowadzić pełnych testów regresywnych aplikacji (koszty, czas), przypadki testowe, które włączamy do testu, powinny być dobierane na podstawie:

  • Jakie błędy zostały poprawione, jakie rozszerzenia czy zmiany zostały wprowadzone
  • Których obszarów aplikacji zmiany te dotyczą najbardziej
  • Jaki jest wpływ wprowadzonych zmian na inne części systemu

Testy regresywne powinny być przeprowadzane po smoke testach lub testach typu sanity. Ten typ testów pozwala upewnić się czy otrzymana nowa wersja aplikacji jest “testowalna” i czy warto zaczynać z nią pracę.

Kiedy należy przestać testować

Testować potencjalnie można bez końca. Nie możemy jednak kontynuować testów do momentu znalezienia ostatniego błędu w systemie. To oczywiście niemożliwe.

W pewnym momencie należy przerwać i dostarczyć system do klienta. Pytanie brzmi, kiedy uznać, że oprogramowanie jest wystarczająco dobrze sprawdzone.

Testowanie mieści się pomiędzy budżetem projektu, czasem na jego realizację i jakością dostarczanego rozwiązania. Project Triangle

Pesymistyczny scenariusz zakłada przerwanie testowania w momencie, kiedy jeden z trzech wymienionych zasobów ulegnie wyczerpaniu.

Przykłady:

  • zbliżająca się data wypuszczenia oprogramowania na rynek
  • wyczerpany budżet projektu
  • upłynięcie czasu przeznaczonego na testy Alfa, Beta
  • założony procent wykonanych przypadków testowych uzyskał status “passed”.
  • pokrycie kodu/funkcjonalności/wymagań, osiągnęło założony poziom
  • liczba wykrywanych błędów spadła poniżej zakładanego progu

W optymistycznej wersji zakończenie testów następuje gdy:
– oprogramowanie spełnia założone wymagania jakości
– korzyści z kontynuowania testów przestają rekompensować koszty ponoszone na testowanie

Przykłady:

  • częstotliwość występowania błędów jest na akceptowalnym (wystarczająco niskim) poziomie
  • pokrycie kodu,funkcjonalności,wymagań osiągnęło pożądany procent
  • liczba wykonań przypadków testowych, ukończonych sukcesem jest na pożądanym poziomie

Bumper Stickers for Software Testers

Zbiór sentencji i cytatów na temat roli i pracy testera.

  • Ask me about my latest bug.
  • Honk if you love to crash software.
  • My other car is a bug.
  • Have you hugged your software tester today?
  • Software Testers: Always looking for trouble.
  • Software Testing is Like Fishing, But You Get Paid.
  • Software Testers: “Depraved minds…Usefully employed.” ~Rex Black
  • Software Testing: Where failure is always an option.
  • Software Testing: When Your System Actually Has to Work
  • Software Quality: Don’t ship without it.
  • I don’t make software; I make software better.
  • Improving the world one bug at a time.
  • Software Testing: You make it, we break it.
  • Software Testers don’t break software; it’s broken when we get it.
  • Software Testers: We break it because we care.
  • To err is human; to find the errors requires a tester.
  • If developers are so smart, why do testers have such job security?
  • My software can beat up your software.
  • A good tester has the heart of a developer…in a jar on the desk.
  • Test is my copilot.
  • If your software works, thank a tester.
  • Old Model-Based Testers Never Die; They Just Transition to a Higher State.
  • Life is too short for manual testing.
  • Friends don’t let friends do capture-replay.
  • Support spec-based testing: Be code-dependent no more!
  • People should think and machines should test.
  • Test never sleeps.
  • Visualize Great Software
  • Trust, But Verify.
  • Pertempto ergo sum – I test, therefore I am.
  • Testers don’t like to break things; they like to dispel the illusion that things work. ~ Kaner, Bach, Pettichord
  • I came, I saw, I found lots of #$@% bugs in your %$#@ spaghetti code!
  • I test, therefore it works.
  • Testers don’t go to work to make friends.
  • Bad Code is Not Bad, Its Just Misunderstood.
  • Test everything. Hold on to that which is good.” – 1 Thessalonians 5:21
  • Brain on, eyes open…test.” ~ James Whittaker
  • There’s always one more bug.
  • Testing…a target-rich environment.
  • It did what? Well, it’s not supposed to do that.
  • My software never has bugs. It just develops random features.
  • The Definition of an Upgrade: Take old bugs out, put new ones in.
  • We break software so you don’t have to.
  • I used to build software…now I break it! Its a lot more fun!!
  • We travel fast and we travel light – let’s hunt some bugs!
  • Bugs, bugses, we finds them, Preciousss.
  • Software Testing: That Which Does Not Kill Us, Still Hurts A Lot
  • We don’t find bugs by chance , we create them by choice
  • Ashes to ashes, dust to dust, and more bugs to squash!
  • Our job is tell you your baby is ugly!
  • Your code is buggy and your mom dresses you funny.
  • Does your mother know what kind of code you write?
  • Just test it
  • To test, or not to test — there is no question
  • Be verwy verwy quiet, I am hunting defects
  • Passion-driven testing: Making every line of code feel dirty.
  • Software Testing is a second-childhood: You broke it, and I’m telling.
  • Code-Coverage Testing: Making every line of code feel dirty and used.
  • All code is guilty, until proven innocent.
  • Siamese Twins- Developers and Testers
  • If it ain’t broke, you’re not trying hard enough.
  • Only certainties in life: Death, taxes and bugs in code!
  • Bug-Checking Is Brutally Cool! – Doonesbury
  • Testing Delayed is Testing Denied
  • Bugs are that which, when you stop believing in them, don’t go away.
  • Those are the bugs, if you don’t like them…I have others
  • Development is what you’re capable of doing. PM determines what you do. Testing determines how well you do it.
  • Development and testing are indispensable to each other.
  • Only certainties in life: Death, taxes and bugs in code!
  • Faith is fine in private life, but poison in software testing.
  • Testing is organised skepticism.
  • Testers do it over and over.
  • Software Entomologist: Get bugs or die trying!
  • Project Managers want it to work. Developers try to make it work. Customers hope it works. Testers know how it works.
  • Software Testers – We succeed where others fail!
  • I’m a Software Tester. Bug me all you want!
  • Credit the Developer, Debit the Tester.
  • If it works, its the developer, if not it’s QA
  • Hate the Tester,Love the programmer
  • Down QAs, Up Developers
  • Breakage is our business… and business is good.
  • It’s Automation, Not Automagic!
  • It compiled on your system, but it committed suicide on mine!
  • Test it now or test it later, either way it’s gonna be tested.
  • Semper Pertemptum: Always Testing
  • Keep on Testin’
  • You build it, we break it!
  • Software Testing, not just a checkbox on your project plan.
  • Software Testing, we save the best for last.
  • Software Testing, we crash so you don’t burn
  • Quality Assurance, we take the blame so you don’t have to.
  • We don’t create defects, we just find yours.
  • My defect was a showstopper on build .645!
  • I saved our customers from the showstopper in build .645!
  • Software Testers Always go to Heaven … they’ve already had their share of Hell!
  • Old testers never die, they just regress.
  • SQA: We eat bugs for breakfast.
  • Software testers: we don’t get headaches – we’re just carriers.
  • Got quality?
  • QA Princess — Breaking hearts, breaking code!
  • Hard on software but soft on programmer.
  • Honk if you believe in bug free code, or the Easter bunny.
  • Have bug?, will find!
  • Development Is Like A Box of Chocolates, Testers Never Know What They Are Going To Get!!
  • A tester is for life, not just Christmas.
  • I brake for blue screens of death.
  • In bugs we trust.
  • Software Testing: The Bug Stops Here.
  • In God we trust, and for everything else we test.
  • If you can read this sticker it passed the usability test
  • Exploratory Tester: Spec’s are for wimps
  • The great tragedy of Testing: the slaying of a beautiful hypothesis by an ugly fact.
  • A bug in the hand is better than one as yet undetected.
  • And on the seventh day, He shipped.
  • Any sufficiently advanced bug is indistinguishable from a feature.
  • Software Testing … because computers are only human.
  • Seeking out complexity is the essence of bug finding.
  • Bugs are not an option: they’re bundled with the software!
  • Agile Testers of the world UNIT!
  • If you can read this sticker it passed the usability test
  • Exploratory Tester: Specs are for wimps
  • The great tragedy of Testing: the slaying of a beautiful hypothesis by an ugly fact.
  • When the testing gets tough, switch to test generation.
  • Quando omni flunkus testerati (When all else fails, try testing.)
  • Software testing – because computers are only human.
  • Every morning is the dawn of a new error.

Źródło: www.stickyminds.com/se/S8299.asp

Pięć problemów występujących w SDLC

Problem:

  1. niewystarczająco zdefiniowane wymagania – jeśli wymagania są niejasne, niekompletne, zbyt ogólne lub nietestowalne, na pewno pojawią się problemy
  2. nierealistyczny time plan projektu – zbyt wiele pracy zaplanowanej w zbyt krótkich przedziałach czasu
  3. niewystarczająca ilość testów – nikt nie wie jakiej jakości jest system, dopóki klient nie zacznie zgłaszać problemów.
  4. zmiany po zatwierdzeniu specyfikacji – mała z punktu widzenia klienta zmiana, może oznaczać zmianę koncepcji działania całego systemu. To oznacza dodatkową pracę, koszty oraz konieczność przeplanowania zadań.
  5. brak komunikacji – jeśli programiści nie wiedzą czego oczekuje klient (np. z powodu braku wymagań), lub klient zmienia wymagania w trakcie trwania projektu, czas zaplanowany na kodowanie, testowanie jest przeznaczany na wyjaśnianie.

Rozwiązanie:

  1. zdefiniowane wymagania – jasne, kompletne, szczegółowe, spójne logicznie oraz testowalne wymagania, które zostaly zaakceptowane przez wszystkie strony. W projektach prowadzonych wg metodyk lekkich, niezbędna jest ciągła koordynacja  wymagań z udziałem klienta.
  2. realistyczne estymacje czasu – zapewnienie odpowiedniej ilości czasu na planowanie testów, tworzenie przypadków testowych, testowanie, poprawę i retesty błędów, zmiany (change requests), raporty i dokumentację -zarówno tworzenie jak i czytanie. Zespół powinien mieć szansę na ukończenie projektu bez efektu wypalenia się.
  3. testowanie w odpowiednim momencie – rozpoczęcie testów na wczesnym etapie SDLC, retesty po poprawie błędów, testy regresywne po zmianach w bieżącej wersji systemu.
  4. trzymanie się zdefiniowanych wymagań – kiedy ruszy kodowanie, pojawią się zmiany, które zazwyczaj oznaczają dodatkową pracę w ustalonym na początku zakresie godzin. Dobrą praktyką jest komunikowanie konsekwencji takich zmian i jeśli są one niezbędne -reestymacja czasu na testy.
  5. komunikacja – tam gdzie ma to sens, pomagają przeglądy i inspekcje. Narzędzia do pracy grupowej: email, repozytorium błędów i dokumentacji. Wersjonowanie. Aktualne wersje dokumentów projektowych. Oraz najważniejsze – bezpośredni kontakt członków zespołu.

Priorytety w testowaniu oprogramowania, analiza ryzyka

Ryzyko w testowaniu oprogramowania można określić procentowo, jako stopień niepewności czy projekt osiągnie założone cele. Ryzyko określa prawdopodobieństwo wystąpienia nieporządanej, zdefiniowanej wcześniej, sytuacji oraz stopień jej wpływu na powodzenie projektu.

Jakie ryzyka wiążą się z zastosowaniem podejścia typu Risk Based Testing?

  • niesprecyzowana defininicja ryzyka – umieszczanie ryzyk i błędów w jednej  grupie
  • subiektywna ocena wpływu ryzyka na projekt oparta na “pasujących” czynnikach
  • brak przeglądów listy ryzyk w kolejnych fazach SDLC

Testując oprogramowanie nie da się sprawdzić wszystkich scenariuszy (tak jak nie da się znaleść wszystkich błędów). Dlatego tak ważne jest podjęcie decyzji co testujemy, a czego nie. Na których obszarach aplikacji skupić uwagę, a które uznać za “niezagrożone”. Testowanie np. metodami czarnej skrzynki z użyciem klas równoważności czy wartości brzegowych zapewnia co prawda pokrycie funkcjonalności testami, ale przy okazji powoduje, że liczba przypadków testowych (test cases) rośnie. Co więcej nie wszystkie z nich są tak samo istotne z punktu widzenia jakości systemu, czasu, który mamy na testowanie oraz wymagań klienta.

Sposobem na zmniejszenie liczby przypadków testowych jest wybranie tych funkcjonalnych obszarów aplikacji, które są najbardziej podatne na błędy oraz tych, których uszkodzenie może spowodować największe koszty.

Gdzie i kiedy spodziewać się największej liczby błędów?

To tylko kilka czynników, które warto wziąć pod uwagę przy ustalaniu zakresu testów aplikacji. Moim zdaniem -ważnych, ale jak zwykle wszystko zależy od kontekstu i danego projektu.

Złożone funkcjonalności.
Złożoność jest jedną z najczęstszych przyczyn powstawania błędów: wiele zmiennych użytych w kodzie, rozłożony na wiele kroków przepływ danych, skomplikowana logika biznesowa, zgromadzenie w jednym module wielu funkcji, których interfejsy wychodzą na zewnątrz.

Obszary systemu, które zostały zmodyfikowane/przepisane.
Testy regresywne powinny załatwić sprawę. Jednak i one mają swoje priorytety, które mogą zmienić się po wprowadzeniu zmian w funkcjonalności. Innego rodzaju zagrożeniem przy wyborze scenariuszy testowych do testów regresywnych jest paradoks pestycydów.

Wiele zmian w pojedyńczym module systemu może być symptomem źle wykonanej analizy. To sygnał aby otworzyć plik z wymaganiami i przypadkami użycia (Use Cases) -jeśli mamy ich zaktualizowaną wersję :)
Liczba osób zaangażowanych w programowanie/testy.
Im więcej osób jest zaangażowanych w zadanie tym większy nakład środków i czasu na komunikację. Wydłużony przepływ informacji prowadzi do ich zniekształcenia, nadinterpretacji czy pomijania. Może działać to zarówno podczas kodowania jak i przy testach.

Jakość wykonania testów (nie mówię tu o jakości aplikacji, ale o jakości pracy) jest ważniejsza niż odpowiedź na pytanie “Zostało nam trzy tygodnie na testy. Ile dodatkowych osób możemy w nie zaangażować?”. Jedną z metryk (z pewnością nie najlepszą) wydajności testera jest liczba zgłoszonych przez niego błędów.

Trudno jest porównać trójosobowy, doświadczony zespół testowy i zgłoszone przez niego błędy ukryte w architekturze systemu z 10-cioosobową grupą nie-testerów, którzy testują w międzyczasie i chcąc wykonać przypadek testowy, a więc przejść z ekranu A na ekran B, zaglądają np. do kodu aplikacji.

Presja czasu, zarówno przy kodowaniu jak i testach.
Błędne estymacje czasu, problemy w komunikacji, sytuacje nieprzewidziane podczas fazy analizy ryzyka projektu. Wszystko to powoduje opóźnienia zarówno w fazie kodowania jak i testów. Brak czasu jest wrogiem jakości. Skłania do pomijania pierwotnie obranej ścieżki i stosowania skrótów.

Pytania jakie warto zadać przed podjęciem decyzji co testujemy:

  • które elementy aplikacji mogą zostać przetestowane we wczesnej fazie SDLC?
  • które części kodu/moduły są najbardziej skomplikowane i dlatego najbardziej narażone na wystąpienie błędów?
  • która funkcjonalność jest najważniejsza z punktu widzenia zastosowania projektu?
  • która funkcjonanlość jest najbardziej widoczna dla klienta?
  • które z testów mają najlepszy współczynnik pokrycia obszarów o wysokim ryzyku do czasu potrzebnego na testowanie?
  • które z wymagań zostały zmienione lub ogólnie zdefiniowane?
  • która funkcjonalność ma największy wpływ na bezpieczeństwo aplikacji?
  • która funkcjonalność ma największy wpływ na finanse?
  • Które elementy testowanej aplikacji mają największe znaczenie dla klienta?
  • które aspekty podobnych, ukończonych poprzednio projektów powodowały problemy?
  • które elementy podobnych, ukończonych projektów powodowały największe problemy w fazie utrzymania (maintenance)?
  • co programiści uznają na najbardziej narażony na ryzyko element aplikacji?
  • która część systemu była tworzona pod presją czasu?
  • jaki rodzaj problemów może spowodować negatywną reakcję klienta?
  • jaki rodzaj testów może pokryć możliwie najwięcej funkcjonalności?
  • które z poprzednio wykonanych przypadków testowych powodowały wykrycie błędów? (test case value)