7 Zasad Testowania Oprogramowania - Skuteczne Wykrywanie Bugów Według Sylabusa ISTQB

Do zadań programisty należy wytwarzanie oprogramowania; z kolei do zadań testerów należy odnalezienie, zgłoszenie i naprawa awarii kodu. Brzmi to trywialnie, jednak wraz ze zwiększeniem stopnia skomplikowania struktury aplikacji jej naprawa staje się wyzwaniem. Z tego też względu proces testowy podlega pewnym podstawowym zasadom, które stanowią dobre praktyki w dziedzinie Quality Assurance. Przyjrzyjmy się podstawowym metodykom i zobaczmy jak się upewnić, że system działa zgodnie z wytycznymi.

Z tego artykułu dowiesz się:

1. Dlaczego zasady testowania są podstawą pracy eksperta QA,
2. Czy testowanie dowodzi braku usterek,
3. Czy możemy przeprowadzić testowanie gruntowne,
4. Czy warto testować na wczesnych etapach wytwarzania oprogramowania,
5. Co oznacza kumulacja defektów,
6. Czym jest "paradoks pestycydów",
7. Czy kontekst jest w stanie wpłynąć na formę testu,
8. Czy brak błędów w kodzie gwarantuje użyteczność aplikacji,
9. Czy warto wprowadzić w tok pracy 7 zasad testowania oprogramowania?

Siedem zasad testowania oprogramowania podstawą pracy jako tester

Wiele zawodów podlega pewnym regulacjom lub zasadom, które pozwalają na stworzenie standardów pracy. Nie inaczej wygląda sytuacja testera oprogramowania. Na początku swojej drogi jako junior dowiadujemy się o ogólnych zasadach nałożonych przez sylabus rady certyfikacji do testingu oprogramowania ISTQB (International Software Testing Qualifications Board). 

Jest to uznana instytucja międzynarodowa, która do kwietnia 2023 roku wydała około 845 tys. certyfikatów w ponad 130 krajach. Przystąpienie do egzaminu ISTQB domaga się dogłębnego przygotowania się w zakresie wiedzy o procesie testingu w metodologii Agile. 

Dlaczego testing jest ważny?

Proces testowania pozwala na zapewnienie najwyższej jakości oprogramowania. To z kolei przekłada się na poprawne działanie założonych funkcjonalności. Najlepiej zoptymalizowane aplikacje tworzy się poprzez znalezienie błędów i ich eliminację na różnych etapach procesu rozwoju. Wielką pomocą w tym zakresie jest metodologia Test Driven Testing, o której możecie przeczytać na naszym blogu.

Jaki jest cel testów aplikacji? Po pierwsze, regularne testowanie zmniejsza koszt naprawy błędów na finalnym etapie wytwarzania produktu. Zapewnia ono również pełną kontrolę nad procesem developmentu poprzez ocenę ogólnej jakości projektu. Dzięki temu mamy pewność, że aplikacja funkcjonuje zgodnie z wymogami klientów - a przez to przysłuża się rozwojowi ich biznesów. Dlatego też ważnym jest, by testy wykonywane były zgodnie z wymogami branżowymi nałożonymi przez certyfikowane instytucje.

Zgodnie z sylabusem ISTQB wyróżnia się siedem ogólnych zasad testowania, które służą za standard w naszej branży. Zapoznajmy się z nimi i dowiedz się, w jaki sposób upewniamy się o wysokiej klasie wydawanych przez nas systemów.

Testowanie ujawnia usterki nie dowodząc ich braku

Poprzez testing zespół jest w stanie zmniejszyć i ograniczyć ilość defektów ale nigdy nie będzie mógł przetestować wszystkiego i dowieść, że oprogramowanie jest wolne od defektów w 100%. Dobrą praktyką będzie natomiast przetestowanie aplikacji przez więcej niż jedną osobę. Każdy ma inne podejście i metody pracy. To sprawia, że działając wspólnie zwiększamy szansę na znalezienie więc istnieje prawdopodobieństwo wykrycia większej ilości defektów.

Testowanie gruntowne jest niemożliwe

Zespołom testerskim przyświeca cel odnalezienia jak największej ilości defektów aby aplikacja, strona, bądź moduł działały jak najsprawniej. Zwykle jednak nie da się przetestować wszystkich kombinacji. Czasami ścieżka do odkrycia bugów jest bardzo skomplikowana. Ryzyko to rośnie wykładniczo wraz ze stopniem skomplikowania aplikacji. W takich przypadkach defekty występują tylko w bardzo specyficznych warunkach. To sprawia, że nie jesteśmy w stanie przewidzieć kombinacji danych wejściowych i warunków wstępnych w budowanym przez nasz zespół systemie. 

Dlatego też skupiamy się na najważniejszych funkcjach i starannie opracowujemy fazy testów. Dobry management to komponent pozwalający nam na zoptymalizowanie czasu i zasobów na to, by do zakończenia testów dojść do jak najlepszych rezultatów. Nawet najlepszy tester nie jest w stanie przewidzieć wszystkich wejść i warunków. Dlatego nie stawiajmy sobie nierealnych wymagań i oczekiwań. 

Wczesne testowanie oszczędza czas i pieniądze

Praktyka testingu na wczesnych etapach jest standardem w metodyce Agile. O praktyce shift-left testingu czy o korzyściach płynących z aplikacji hybrydowych można przeczytać nieco więcej tutaj. Jednak w tym momencie zaznaczę, że warto ją wdrożyć aby obniżyć koszty wytworzenia oprogramowania oraz nie narażać się na ryzyko jego całkowitej przebudowy, a tym samym wydłużenia czasu wprowadzenia go na produkcyjne środowisko. Warto również wspomnieć, że na skuteczne wykrycie błędów pozwala testowanie statyczne i dynamiczne - tak wcześnie, jak to tylko możliwe. 

Kumulowanie się defektów

Zasada kumulowania się defektów mówi o tym, że zazwyczaj największą ich ilość znajdziemy w poszczególnych obszarach czy modułach oprogramowania. W takim przypadku zespól testerski będzie się koncentrował najbardziej na takich zaobserwowanych skupiskach błędów. Niektórzy eksperci wskazują na występowanie zasady Pareto. W tym przypadku należy ją interpretować tak, że 20 % modułów  odpowiada za 80 % pojawiających się bugów.

Mając tego świadomośc można na etapie planowania testów oszacować ryzyko wystąpienia bogatych w defekty obszarów i położyć nacisk na ich testy. Będzie to miało zastosowanie w przy dużych lub skomplikowanych systemach, gdzie dany moduł posiada na przykład wiele zależności i powiązań z innymi elemantami systemu.

Paradoks pestycydów

Ta dość barwna nazwa kryje ważną zasadę, którą należy stosować na każdym etapie testowania. Dlaczego paradoks “pestycydów”? Substancje te z czasem przestają być skuteczne w eliminacji szkodników. Analogicznie w przypadku testowania oprogramowania, powtarzanie tych samych testów prowadzi do osłabienia ich zdolności do wykrywania błędów. 

Jest to zasada informująca o tym, że ciągłe wykonywanie tych samych testów może stracić na efektywności; w pewnym momencie testy nie wykryją defektów. Dlatego też w procesie testowania oprogramowania bierzemy pod uwagę wszelkie różnice. Warto aktualizować proces przeprowadzania testów i przypadki testowe, jak również cyklicznie zmieniać zmieniać dane testowe.

W testach manualnych można to zauważyć w momencie, gdy z powodu rutyny i znudzenia tester wykonujący ten sam test raz za razem może przegapić błąd w kodzie. Z kolei nowa osoba w projekcie znajdzie je bez problemu dzięki świeżemu podejściu do tematu.

Testowanie zależy od kontekstu

Sposoby i metody przeprowadzania testów są zależne od sprawdzanego systemu oprogramowania. Ten aspekt determinuje nasze podejście - w zależności od tego co jest podmiotem testu możemy kłaść na przykład nacisk na testy wydajności, bezpieczeństwa czy dostępności. Przykładowo, systemy e-commerce testuje się inaczej, niż na przykład oprogramowanie infrastruktury krytycznej.

Typ aplikacji, która spełni Twoje oczekiwania biznesowe omawiamy podczas sesji Warsztatów Discovery. Dowiedz się, jak możemy Ci pomóc w wytworzeniu produktu, który wymiernie wesprze Twój biznes.

Wykwalifikowany tester wie, że testowanie wykonuje się w różny sposób w zależności od sytuacji. Musimy być elastyczni, by skutecznie wykryć i wyeliminować większość awarii. Paradoks ten w większej ilości przypadków odnosi się do testów wysokopoziomowych, które są przeprowadzanie w fazie testów systemowych i akceptacyjnych.

Przekonanie o braku błędów jest mylne 

Ostatnia z omawianych przez nas zasad jest ściśle powiązana z wcześniejszymi:

• Testy ujawniają usterki, ale nie może dowieść ich braku,
• Gruntowny testing jest niemożliwy.

Podkreśla ona wagę użyteczności tworzonego oprogramowania. Oczywiście testowania zmniejsza prawdopodobieństwo wydania niestabilnego systemu. Jednak nawet niewielka ilość defektów nie daje gwarancji sukcesu wydanego produktu. Jeśli nie będzie on pokrywał potrzeb użytkownika końcowego czy będzie nieintuicyjny w obsłudze, system nie nadaje się do dalszego wdrożenia. Dlatego też znalezienie wszystkich błędów musi stać ręka w rękę z zapewnieniem, że proponowana przez zespół aplikacja funkcjonuje zgodnie z wymogami userów. 

7 zasad - przestrzegać czy nie?

Z naszej strony odpowiedź na to pytanie brzmi: jak najbardziej! Powyższe zasady stanowią wyznacznik jakości, dzięki któremy mamy pewność, że proponowana przez nas aplikacja działa zgodnie z wymaganiami zarówno klientów, jak i użytkowników końcowych. Przestrzeganie ich sprawia, że trzymamy pieczę nad całością procesu developmentu, a my możemy naprawić zawczasu błędy w miejscach, które mają kluczowe znaczenie dla projektu.