Redakcja
Testowanie statyczne, nazywane inaczej przeglądami, oraz testowanie dynamiczne, które jest dla nas najważniejszą czynnością kojarzoną z prowadzeniem testów, to najczęstsze działania w ramach kontroli jakości. Są jeszcze dwie, które wymagają zazwyczaj wiedzy technicznej i specjalnie spreparowanych narzędzi pracy oraz środowisk. Próbując spojrzeć na definicje słownikowe wszystkich elementów, to co je wyróżnia, to przede wszystkim: URUCHOMIENIE.
Testowanie statyczne to takie testowanie, które nie wymaga wykonania uruchomienia testowanego obiektu. Testowanie dynamiczne takiego uruchomienia wymaga.
Analiza statyczna to analiza bez jego wykonywania, oparta na jego strukturze, zawartości lub dokumentacji. Analiza dynamiczna to ocena oparta na zachowaniu obiektu podczas wykonania.
Spróbujmy pokazać poszczególne działania na przykładach:
- testowanie statyczne to jest czytanie dokumentacji (w tym kodu źródłowego) ze zrozumieniem, a ta operacyjna czynność (nie procesowa) nie wymaga narzędzia (choć może być narzędziowo wspierana). Przykładem testowania jest przegląd specyfikacji wymagań
- analiza statyczna jest narzędziowym sprawdzaniem dokumentacji (zazwyczaj kodu lub modelu) pod kątem predefiniowanych reguł. Reguły te zazwyczaj są ustandaryzowane. Przykładem analizy statycznej jest uruchomienie narzędzia, które sprawdzi kod źródłowy pod kątem poprawności reguł kodowania
- testowanie dynamiczne jest sprawdzeniem oprogramowania w trakcie jego uruchomienia i wymaga zdefiniowania testu oraz oczekiwanego rezultatu. Przykładem testowania dynamicznego będzie uruchomienie przypadku testowego na stronie internetowej
- analiza dynamiczna jest określeniem zachowania i użycia zasobów przez oprogramowanie w trakcie jego uruchomienia. Przykładem analizy dynamicznej jest określenie poziomu użycia procesora przez oprogramowanie podczas jego użycia.
Aspektem, który umożliwia nam grupowanie czynności pod innym kątem jest użycie narzędzia. Wszystkie czynności, z wyjątkiem testowania statycznego, mogą zostać zautomatyzowane.
Co jednak jest ważne, narzędzie użyte do analizy jest uniwersalnym rozwiązaniem, które zazwyczaj może być stosowane w różnych projektach i organizacjach. W analizie statycznej są to zazwyczaj narzędzia dedykowane konkretnym językom kodowania, a w analizie dynamicznej są to narzędzia, których działanie sprowadza się do analizowania użycia hardware’u. Narzędzia testowania dynamicznego mają swoje frameworki, których nie da się uruchomić bez dostosowania ich pod konkretny projekt. Dla każdego produktu testowanie dynamiczne wymaga niejako zbudowania nowego narzędzia w oparciu o dostępne biblioteki. Takie rozwiązanie promują formalne szkoły testowania, np. ISTQB®.
Niestety powyższe staje się jeszcze bardziej chaotyczne, jeśli spróbujemy w całość wpleść automatyzację. W kategoryzacji na cztery czynności kontroli jakości i w oparciu o obecne definicje brakuje jeszcze jednego ważnego elementu, który powinien zakładać, że istnieje zbiór reguł poprawności działania oprogramowania. Można je zweryfikować w sposób analityczny, bez ręcznie predefiniowanych oczekiwanych rezultatów i nie jest powiązany bezpośrednio z hardware’em. Jest to np. zweryfikowanie na uruchomionej stronie internetowej poprawności działania linków (tzw. link checker). Mamy tutaj cechy dynamicznie uruchomionego oprogramowania, a także analizy, która opiera się nie na predefiniowanym, oczekiwanym rezultacie, ale na powszechnej regule, że strona internetowa - jeśli istnieje - zwraca kod 200, a jeśli adres jest nieosiągalny, to zwraca kod 404 (w uproszczeniu). Nie spełnia to wcześniej określonych parametrów analizy statycznej, analizy dynamicznej ani testowania dynamicznego. Jest to więc coś, co możemy podpiąć pod zupełnie nową kategorię, którą można by nazwać analizą automatyczną.
Bardzo ważnym elementem kontroli jakości jest automatyzacja. Automatyzacja jest nierozerwalnie związana z testowaniem dynamicznym. Dla większości testerów automatyzacja jest to test z oczekiwanym rezultatem, który wymaga uruchomienia oprogramowania. Przykładowo, na poziomie kodowym mówimy o teście jednostkowym z asercją, a na poziomie systemowym o teście po GUI z weryfikacją. Gdyby więc założyć, że testowania dynamiczne mogłoby być uruchamiane jedynie ręcznie, to powstałaby nam nowa czynność – testowanie automatyczne.
Czego nie warto nawet próbować umieszczać w tej strukturze, gdyż spowoduje to już całkowite zamieszanie, to testowanie przy użyciu AI. Aktualnie sztuczna inteligencja może być wsparciem dla każdej z poniższych kategorii, ale w przyszłości może wykonywać każdą z tych czynności.
Kategorie stają się więc coraz bardziej skomplikowane, a relacje stojące za nimi tak bardzo powiązane, że ciężko jednoznacznie określić, kiedy kończy się jedna kategoria, a zaczyna następna. Rozwiązaniem może więc stać się uproszczenie. Taki pogląd, choć w innym podejściu i formie, promuje James Bach związany z nieformalnymi szkołami testowania.
Zaproponował on, by odseparować testowanie od automatyzacji (użycia narzędzi) i temu pierwszemu zostawić nazwę testowanie, a drugie określać jako sprawdzenie (ang. check). Postuluje więc on przypisanie testowania jedynie człowiekowi, co oznacza, że pojęcie „testowanie automatyczne” nie ma sensu. Aby powyższa propozycja kategoryzacji miała sens i uzasadnienie, testowanie dynamiczne powinniśmy zostawić rzeczywiście jedynie testerom. Można by więc uprościć naszą kategoryzację do trzech czynności, co jednak spowoduje również konieczność redefiniowania pojęć.
W tym przypadku:
- analiza byłaby sprawdzeniem kodu lub dokumentacji oprogramowania, niewymagającym jego uruchomienia przy wsparciu narzędzi lub też nie. Przegląd dokumentacji również byłby analizą
- testowanie byłoby dynamicznym uruchomieniem i weryfikacją oprogramowania, czynnością wykonywaną od początku do końca przez człowieka
- sprawdzenie byłoby użyciem narzędzia do tego, by sprawdzić poprawność działania oprogramowania lub parametrów sprzętowych w sposób automatyczny.
Zaproponowane uproszczenie jest zaproszeniem do dyskusji, w której musimy sobie odpowiedzieć na kilka dodatkowych pytań jak takie, czy jest to ważne dla testerów, czy też jest to poziom dywagacji akademickich? Czy ma to sens w mnogości kontekstów projektowych? Czy nowa kategoryzacja jest rzeczywistym uproszczeniem, a może pozornie redukuje definicje, wprowadzając jednocześnie wiele nowych problemów?
Bardzo chętnie wysłuchamy Waszych opinii i Waszych propozycji kategoryzacji.
