Zastanawiacie się może, po co w ogóle dokonywać podziału testów, utrudniać sobie życie regułkami i formułami? Podzielić testy na rodzaje można na wiele sposobów i wiele tych charakterystyk funkcjonuje w świecie informatycznym. Jedne bardziej, drugie mniej popularne.

Pewnego rodzaju otuchą, dla osób które z przerażaniem czytają ten wstęp, może być fakt, iż dokonanie kategoryzacji czegokolwiek w sposób rzetelny, merytoryczny, na zasadzie wyłączności, jest niezwykle trudnym zadaniem. Nie inaczej jest w przypadku testowania oprogramowania, które  nie dość, że coraz bardziej złożone, to jeszcze w samej swej specyfice dynamiczne. Codziennie pojawiają się nowe informacje, czy odkrycia, dlatego katalogizacja jedyna i ostateczna właściwie nie istnieje.

Nie zmienia to jednak faktu, że pewne próby uporządkowania rozbudowanego świata testerskiego zostały podjęte. I tu powrócić można do pytania z początku: po co testerzy mają znać te podziały. Podążając za myślą autora książki „Zawód tester” Radosława Smilgina, szanujący się testerzy powinni znać podziały testowe, ponieważ:

  • podziały te są stosowane w środowisku, a każdy szanujący siebie i swoją pracę tester powinien znać kontekst, w jakim porusza się zawodowo
  • mogą stanowić punk wyjścia do projektowania nowych testów
  • w niektórych przypadkach mogą ułatwić życie i oszczędzić pracy, np. przy klasyfikowaniu defektów
  • testowanie ściśle funkcjonalne jest tylko pierwszym stopniem w karierze, a dalszy rozwój kompetencji ukierunkowany jest albo na role menedżerskie, albo funkcje specjalisty w obrębie danego zagadnienia testerskiego

smartfon laptop stół notatnik długopis

Gdy już wiemy, po co nam ta wiedza, przyjrzyjmy się jednej z najbardziej popularnych typologizacji testów, zaproponowanej przez Sylabus ISTQB Poziomu Podstawowego (wersja 2011.1.2.).

Sylabus dzieli testy na typy ze względu na cel, jaki mają osiągnąć lub bazując na konkretnym powodzie przeprowadzania testów.

Sylabus wyróżnia następujące cele testów:

  • Zbadanie jakiejś funkcji wykonywanej przez oprogramowanie
  • Przetestowanie niefunkcjonalnego atrybutu jakościowego
  • Zanalizowanie struktury lub architektury systemu
  • Zbadanie występowania zmian

Podążając tą specyfikacją, wyróżnia cztery typy testów:

Testowanie funkcjonalne (czarnej skrzynki, czarnoskrzynkowe)

Czyli takie, które sprawdzają co system, podsystem lub moduł robi, w jaki sposób działa. Funkcje to czynności wykonywane przez system. Opisuje się je zwykle w produktach takich jak specyfikacja wymagań, przypadki użycia lub specyfikacja funkcjonalna, ale może się zdarzyć, iż funkcje nie są udokumentowane.

Testy te obejmują funkcje lub inne cechy (opisane w dokumentach lub podejrzewane przez testerów) oraz ich współpracę z innymi systemami. Zajmują się zewnętrznym zachowaniem oprogramowania, traktując je jako czarną skrzynkę.

Można je wykonywać na wszystkich poziomach.

Do testów funkcjonalnych zaliczamy na przykład:

  • Testowanie zabezpieczeń (służy do zbadania funkcji pozwalających na wykrycie zagrożeń np. wirusów)
  • Testowanie współdziałania (pozwala ocenić w jakim stopniu dane oprogramowanie/aplikacja/program jest zdolne do współpracy z jednym lub większą liczbą konkretnych modułów czy podsystemów)
Testowanie niefunkcjonalne (atrybutów niefunkcjonalnych)

Do testów niefunkcjonalnych zalicza się między innymi:

  • Testowanie wydajnościowe
  • Testowanie obciążeniowe
  • Testowanie przeciążeniowe
  • Testowanie użyteczności
  • Testowanie pielęgnowalności
  • Testowanie niezawodności
  • Testowanie przenaszalności

Ten rodzaj testowania można wykonywać na wszystkich poziomach testów. Testy niefunkcjonalne określają, w jaki sposób system działa. Testowanie atrybutów niefunkcjonalnych to nic innego, jak testowanie niezbędne do zmierzenia charakterystyk systemów i oprogramowania, które mogą zostać ocenione na skali (np. czasy odpowiedzi w przypadku testów wydajnościowych).

laptop biurko długopisy kod
Testowanie strukturalne (białej skrzynki, białoskrzynkowe)

To kolejny typ testów, które można przeprowadzić na każdym poziomie testowania. Sylabus ISQB sugeruje, by tej metody używać zaraz po zastosowaniu technik bazujących na specyfikacji, jako wsparcia pomiarów dokładności. Dzięki temu możliwe jest zmierzenie precyzji testowania przez oszacowanie stopnia pokrycia wybranego typu struktury.

Według Słownika Terminów Testowych ISTQB pokryciem określamy „stopień, wyrażony w procentach, w jakim zakresie zestaw testowy wykorzystał przedmiot pokrycia”. Czyli w jakiej skali struktura została przetestowana przez zestaw testów, wyrażona jako odsetek pokrytych elementów. Jeśli dojdzie do sytuacji, że pokrycie nie osiąga 100%, można opracować nowe testy, które zbadają elementy wcześniej pominięte, zwiększając tym samym poziom pokrycia.

By zmierzyć poziom pokrycia, można zastosować narzędzia, zwłaszcza gdy analiza odbywa się na poziomie testów modułowych i poziomie integracji komponentów. Testowanie białoskrzynkowe można oprzeć na architekturze systemu (np. hierarchii wywołań). Możliwe jest również wykorzystanie go na innych poziomach w tym dla systemu, jego integracji czy poziomu testów akceptacyjnych (np. modeli biznesowych czy struktury menu).

Jeśli chcecie dowiedzieć się więcej o testach białoskrzynkowych, zapraszamy do jednego z naszych wcześniejszych postów tutaj.

Testowanie związane ze zmianami (potwierdzające lub regresywne)

Po zakończeniu testów, wykryciu i naprawieniu usterek, należy wykonać ponowny test (retest), by potwierdzić usunięcie błędu. Tego typu testy nazywamy potwierdzającymi. Należy pamiętać, iż lokalizowanie i naprawianie błędów (debagowanie/debugowanie) jest działaniem programistycznym.

Testowanie regresywne, jak czytamy w Słowniku Terminów Testowych ISTQB, to: „ponowne przetestowanie uprzednio testowanego programu po dokonaniu w nim modyfikacji, w celu upewnienia się, że w wyniku zmian nie powstały nowe defekty lub nie ujawniły się defekty w niezmienionej części oprogramowania. Testy takie są przeprowadzane po zmianach oprogramowania lub jego środowiska pracy”.  Zakres tej analizy związany jest z zagrożeniem niewykrycia błędów w oprogramowaniu, które wcześniej działało prawidłowo. Można określić go jako szukanie niepożądanych skutków zmian.

Analizy, jakich dokonuje się w testowaniu potwierdzającym i regresywnym, muszą być powtarzalne. Zbiór testów regresywnych jest stosunkowo niezmienny, dlatego ten rodzaj analizy łatwo poddać automatyzacji.

Testy regresywne można przeprowadzać zarówno na wszystkich poziomach testów, jak i dla wszystkich ich typów (funkcjonalnych, niefunkcjonalnych, strukturalnych).

laptop biurko ołówki kubek kawa karteczki

Dla przykładu inną typologizację proponuje ww. autor, zaznaczając, iż kategoryzowanie testów jest czynnością sztuczną, a wyodrębnione zbiory zawierają się de facto same w sobie lub znacząco się pokrywają, nie tworząc tym samym jednoznacznych i odseparowanych od siebie zbiorów elementów.

Radosław Smilgin proponuje inny podział testów, zaznaczając jednocześnie, że również nie jest on wolny od „grzeszków”:

  • Testy białoskrzynkowe i czarnoskrzynkowe
  • Testy funkcjonalne i niefunkcjonalne
  • Testy potwierdzające
  • Testowanie statyczne i dynamiczne

Te typologie to tylko przykłady tego, w jaki sposób testy można podzielić. Nie zamartwiajcie się, że nie znacie wszystkich rodzajów i każdej specyfiki z definicji. Najważniejsze jest uważne podejście do tematu i logiczne myślenie. Nie trzeba rzucać rodzajami specyfikacji, jak z rękawa, by być dobrym testerem. Trzeba rozumieć to, co się robi i zwracać uwagę na kontekst pracy.

22
  •  
    7
    Shares
  • 7
  •  
  •  
  •