7 zasad testowania

Czyli kilka podstawowych zasad, których warto się trzymać, tropiąc bugi.

Tester poza własną intuicją i doświadczeniem ma do dyspozycji szereg pomocnych książek, w których może znaleźć cenne wskazówki z zakresu testów. Jednakże dla wielu pozycją numer jeden jest niemalże kultowy w środowisku testerskim Sylabus ISTQB, nieoceniony w przygotowaniach do egzaminu ISTQB (International Software Testing Qualifications Board). 

 

Poniżej 7 zasad testowania zawartych w Sylabusie ISTQB  – które, jak głosi, dostarczają ogólnych wskazówek mających zastosowanie do wszystkich rodzajów testowania. Ich skuteczne wdrożenie w cykl życia projektu, usprawnia prace całego zespołu developerskiego. 

 

  1. Testowanie ujawnia usterki, ale nie może dowieść ich braku

 

Fakt, że nie znajdziemy żadnego błędu w aplikacji, niekoniecznie jest powodem do radości, ponieważ istnieje duże prawdopodobieństwo, że jednak jakieś błędy nie zostały wykryte. Testowanie znacząco podnosi szanse na znalezienie niechcianych błędów, jednak nawet jeśli tester zgłosi ich 100, zawsze trzeba brać pod uwagę, że gdzieś może być ten 101.

 

  1. Testowanie gruntowne jest niemożliwe

 

Poza bardzo małymi i prostymi systemami nie możemy uznać, że aplikacja została przetestowana gruntownie. Dobrym przykładem jest test kalkulatora, wykonanie wszystkich kombinacji zajęłoby bardzo dużo czasu, a tym samym prawdopodobnie byłoby zbyt kosztowne w stosunku do korzyści, jakie mogłoby przynieść. Ta zasada obrazuje, jak ważna jest analiza ryzyka, priorytetyzacja i trafny dobór techniki testowania. 

 

  1. Wczesne testowanie oszczędza czas i pieniądze

 

Im bardziej prace nad aplikacją są zaawansowane, tym drożej kosztuje naprawa błędów. Zdecydowanie mniej kosztowne jest naniesienie poprawek już na etapie testowania dokumentacji. Angażowanie zespołu testerskiego na wczesnym etapie projektu wytwórczego oszczędza czas i pieniądze. 

 

  1. Kumulowanie się defektów

 

Jak podpowiada sylabus, zwykle większość defektów wykrytych podczas testowania ma swoje źródło w niewielkiej liczbie modułów. W rezultacie przewidywane skupiska błędów są ważnym elementem analizy ryzyka, którą przeprowadza się w celu odpowiedniego ukierunkowania wysiłków związanych z testowaniem.

 

  1. Paradoks pestycydów

 

To bardzo ciekawa zasada, która porównuje stosowanie ciągle tych samych pestycydów (szkodniki uodparniają się na konkretny pestycyd) do testowania ciągle i ciągle tego samego w taki sam sposób. Dobrze jest modyfikować testy i dane testowe, aby dawały większe szanse na wykrycie defektów. Warto jednak wspomnieć, za sylabusem, że w niektórych przypadkach — takich jak automatyczne testowanie regresji — paradoks pestycydów może być korzystny, ponieważ pozwala potwierdzić, że liczba defektów związanych z regresją jest niewielka. 

 

  1. Testowanie zależy od kontekstu

Tak jak w życiu tak i w testach kontekst ma znaczenie. 😉 Inaczej podejdziemy do testowania systemu do zamawiania jedzenia, inaczej zaś do testów oprogramowania zastosowanego w rakietach kosmicznych. Poziom skomplikowania i krytyczność danej aplikacji ma wpływ na to, jakie podejście do testów zastosujemy. Jak podpowiada sylabus, innym przykładem może być odmienny sposób przeprowadzania testów w projektach zwinnych i w tych prowadzonych zgodnie z modelem sekwencyjnym cyklu życia wytwarzania oprogramowania.

 

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

 

Zasada ta potwierdza zasady pierwszą i drugą oraz doprecyzowuje, że nawet jeśli jesteśmy przekonani, że aplikacja działa zgodnie z dokumentacją i znaleźliśmy już i naprawiliśmy ogrom błędów, nie oznacza to, że jest ona ich pozbawiona, ponieważ nadal może nie spełnić oczekiwań użytkownika końcowego i być trudna w obsłudze. 

 

Testowanie ma wiele twarzy, dzięki temu jest bardzo ciekawe. Świetnie sprawdzają się w nim konkretne zasady, schematy, dobre praktyki, a jednocześnie w świecie testerskim jest spora  przestrzeń na inwencję własną i duże pole na słuchanie testerskiej intuicji. 


Opublikowano:

Mentax na Facebook'u