Siedem zasad testowania ISTQB

Siedem zasad testowania stanowi jeden z rozdziałów Sylabusa, podręcznika przygotowującego do egzaminu ISTQB. Znajdziesz w nim definicje, które postaram się wyjaśnić, w mam nadzieję nieco prostszy do zrozumienia sposób.

Moim sposobem na zmniejszenie ilości defektów jest (o ile nie spełniliśmy warunków zakończenia testów w naszym projekcie) poproszenie innego testera o przetestowanie tego, co sami testowaliśmy. Będzie on miał inne spojrzenie na funkcjonalności i sposoby ich testów. Robiłem to dzieląc się swoim budżetem na testy z innym testerem.

Testowanie gruntowne jest niemożliwe.

Znaczy to, że nie można przetestować wszystkiego w aplikacji, wyjątkiem są aplikacje bardzo małe.

Przypomina mi się taka sytuacja z czasów jeszcze technikum. Moją przygodę z testowaniem rozpocząłem od praktyk wakacyjnych. Pamiętam, jak we wrześniu wróciłem do technikum i na zajęciach kolega pokazał mi i drugiemu koledze, z którym odbywałem praktyki swoją aplikację stworzoną w ramach praktyk. Pełni zapału zgłosiliśmy się do testowania, pewni, że przecież w każdej aplikacji błąd być musi. ALEEEE no właśnie ta aplikacja to był pseudo Mario na dosłownie 10 sekund grania z założeniem, że ma działać tylko na najnowszym Windowsie. Testowaliśmy ją wtedy ponad godzinę – mam nadzieję, że odczuliście to, co ja wtedy, czyli wkurzenie, że nie daję rady znaleźć błędów, a one muszą tam być!!!

Myślę, że w nierealnym świecie, gdybyśmy mieli odpowiednio dużo czasu na testowanie, moglibyśmy w efekcie przetestować każdą aplikację gruntownie (o ile nie byłyby w niej robione zmiany przez programistów). Tak jak mówiłem nierealny świat, w którym budżet na aplikację jest nieograniczony wręcz.

Wczesne testowanie oszczędza czas i pieniądze.

Uważam ją za jedną z najważniejszych, a zarazem bardzo często pomijanych zasad. Wczesne testowanie daje ogromne korzyści i bardzo duży komfort pracy. Po pierwsze błędy znalezione na wczesnym etapie dużo łatwiej i taniej poprawić.

Spójrzcie na to tak. Przypuśćmy, że znaleźliście błąd w specyfikacji, zanim dany komponent został zaprogramowany. Poprawa znalezionego błędu ograniczy się do czasu, jaki analityk poświęci na poprawę odpowiednich fragmentów dokumentacji.

Gdyby dana funkcjonalność była zaprogramowana, poprawa jej to czas programisty spędzony na poprawę kodu, czas programisty konsultującego błąd z analitykiem i wreszcie Twój czas spędzony na testach i retestach.

Wczesne testowanie daje duży komfort psychiczny i mniej stresu. W moim odczuciu aplikacje testowane na wcześniejszym etapie mają fajniejszą jakość. Łatwiej jest również zapanować nad zmianami w projekcie oraz ryzykami wcześniej zdefiniowanymi.

Warto tutaj dodać, że często mówimy o wczesnym testowaniu i na mówieniu kończy się ich wykonanie. Zazwyczaj startujemy późno a wręcz czasami ZBYT późno z naszymi testami – może to wynikać z wielu czynników, natomiast warto mimo wszystko optować za opcją jak najwcześniejszego startu.

Kumulowanie się defektów.

Zasada kumulowania błędów mówi o tym, że jeśli jesteśmy świadomi tego, gdzie jest dużo błędów w aplikacji, to mamy możliwość przewidzenia tego, gdzie będą większe ryzyka testowe i jakie moduły będą wymagały większych nakładów na testy.

Ważna według mnie przy tej zasadzie jest pewność tego, że błędy skumulowane nie są duplikatami, dlatego ważne jest w projekcie by błędy zgłaszane były prawidłowo opisywane.
Zasada ta jest bardzo ważna. Pomaga nam przy planowaniu ryzyka w aplikacji oraz oszacowaniu czasu potrzebnego na testy.

Paradoks pestycydów.

Lubię tłumaczyć porównując go do robienia porządku w domu. Nazwijmy go po mojemu „paradoksem porządków”. Wydaje mi się, że nazewnictwo dotyczące sprzątania bardziej trafia do każdego.

Z czego się bierze ta zasada? Paradoks ten dotyczy sytuacji, gdy na aplikacji testujemy zawsze te same scenariusze. Prowadzi to do sytuacji, gdy w czasie testów przestajemy znajdować błędy. Możemy wówczas mylnie uznać, że aplikacja nie ma defektów.

Wracając do mojej nazwy i tłumacząc bardziej obrazowo, przyjmijmy, że na co dzień sprzątamy dom, odkurzamy, zamiatamy itp. itd. Uznajemy, że po wykonaniu tych czynności dom jest posprzątany. W okresie świątecznym sprzątamy dokładniej i wówczas okazuje się, że znajdujemy duże warstwy kurzu za kanapą, na szafach, lampach.

Moim zdaniem w celu uniknięcia tego problemu, możemy:

• Pisać przypadki wysokopoziomowe i je egzekwować podczas testów.
• Wplatać przy każdych testach oprócz standardowych testów na podstawie dokumentacji, testy eksploracyjne i może zgadywanie błędów. Ogólnie rzecz biorąc trzeba wprowadzić trochę szaleństwa/chaosu i nieprzewidywalności w nasze testy! 🙂

Testowanie zależne jest od kontekstu.

Kolejna bardzo istotna zasada, która ładnie łączy się, chociażby z zasadą 2. Każda aplikacja ma swoje własne warunki, które określają jak ma ona działać.

Przykładowo na tapetę wziąłbym jakąkolwiek grę, która powstała lub ma powstać. Planując testy bierzemy pod uwagę to co jest ważne dla użytkownika tej aplikacji. Testując rozważamy jak ma ona działać, czy gra nie zacina się na słabszym (zgodnym z wymogami sprzętowymi) sprzęcie. Dodatkowo testujemy tryb multi lub single player, lub nie testujemy muli playera, jeżeli np. tak jak seria Wiedźmin go nie posiadamy.

Przy okazji tej zasady możemy zauważyć, że decydującym czynnikiem podczas planowania testów jest wiedza o produkcie.

Przekonanie o braku błędów jest błędem.

Poprzednie zasady wspominały już o tym, że nie jest możliwe przetestowanie wszystkiego i znalezienie wszystkich błędów. Ta zasada utwierdza nas w tym przekonaniu. Trzeba przyjąć, że aplikacja ma błędy mimo testów. 

Rozumiem tą zasadę bardziej, jeśli nazwę ją po swojemu : 

„Przekonanie, że stworzyliśmy bardzo dobrą aplikację, ponieważ ma ona mało błędów jest błędem”. 

O tym, że nie jest możliwe zapewnienie bezbłędności aplikacji mówi zasada pierwsza. W tej dochodzi dodatkowo to, że należy pamiętać, że nawet jeśli będziemy pewni, że aplikacja działa zgodnie z wymaganiami opisanymi w dokumentacji, to nadal może ona nie spełnić wymagań użytkownika docelowego. Nie będzie wówczas używana.

Siedem zasad testowania – podsumowanie

Jak widzicie zasady to schematy, którymi jedni się posługują bardziej inni mniej. Ważne, aby zawsze patrzeć na zadania i schematy z pewnym dystansem i spróbować je zrozumieć oraz dostosować do swoich potrzeb. Mam nadzieję równocześnie, że przydało się wam moje spojrzenie na tak oklepany temat!