Cała prawda o testowaniu funkcjonalnym

Nie tak dawno wywołałem niemałe poruszenie na LinkedIn. Zapytacie — jak? A no tak, że podzieliłem się smutną prawdą o testowaniu funkcjonalnym. Dość często publikuję moje przemyślenia na temat testowania i branży DevOps na LinkedIn. Na platformie tej istnieje wspaniała społeczność liderów branży, w której często prowadzimy wnikliwe dyskusje na temat najnowszych technologii i trendów dnia.

Jednakże jedna z ostatnich dyskusji na LinkedIn na temat testowania funkcjonalnego stała się o wiele bardziej gorąca, niż się spodziewałem.

Testowanie funkcjonalne: Zakwestionowana definicja

12 czerwca napisałem następującą odpowiedź w odpowiedzi na artykuł o testowaniu funkcjonalnym od Guru99, popularnej strony w świecie testowania oprogramowania:

„W mojej skromnej opinii, testy regresji lub Sanity i Smoke testy nie są jedynymi rodzajami testowania funkcjonalnego. Zespoły powinny i włączają do swoich regresji testy wydajności, testy jednostkowe i testy API, które są przykładami testów niefunkcjonalnych.

Myślę, że definicja testowania funkcjonalnego... nie jest dokładna, ponieważ stwierdza, że regresja jest testowaniem funkcjonalnym, podczas gdy wydajność jest niefunkcjonalna, wówczas gdy... większość recesji powinno zawierać oba typy”.

Testowanie funkcjonalne nie powinno być ograniczone tylko do regresji, sanity i smoke testingu. Jest to bardzo mylące i odciąga od tego, co naprawdę powinno być dla testerów znaczące.

Zamiast tego definicja testowania funkcjonalnego powinna skupiać się na procesie sprawdzania poprawności działania aplikacji. Nie powinno być ograniczeń dla różnych testowanych funkcji.

Zaprezentowałem to innym testerom z branży, aby wyrazili swoje opinie, i naprawdę mnie zaskoczyli! Oto kilka moich ulubionych spostrzeżeń z całej tej dyskusji, które prowadzą do “ukazania prawdy”, a tym samym zrozumienia, na czym polega testowanie funkcjonalne.

Typ testu a zakres testu

Jedną z ważnych kwestii poruszonych podczas dyskusji było to, że artykuł na Guru99 całkowicie zatarł różnicę pomiędzy “zakresem” testu, a “typem” testu. Podczas gdy typy testów mogą obejmować zarówno testy dostępności jak i testy obciążeniowe, to zakres odnosi się do tego, czy są to testy jednostkowe, integracyjne czy systemowe.

Jak zauważył Eliezer Shindler z F5:
„Jest to całkowicie wykonalne, aby wykonać test jednostkowy, który jest testem wydajności”

Wyraził również swoją frustrację, że istnieje tak wiele różnych koncepcji, które w rzeczywistości odciągają nas od najważniejszego celu testowania: zapewnienia jakości produktu.

Zakres i typ nie są pojęciami równoznacznymi. Chociaż nie jest to częste, istnieją sytuacje, w których możesz wymagać testów wydajności (typ) na poziomie jednostki (zakres). Kiedy żonglujesz tak ważną terminologią, bardzo trudno jest zbudować solidną i efektywną strategię dla testowania funkcjonalnego.

Testowanie funkcjonalne vs. niefunkcjonalne: Czy to konieczne?

Inne osoby pytały, czy jest w ogóle potrzebne rozróżnienie pomiędzy testowaniem funkcjonalnym a niefunkcjonalnym.

Paul Bruce zasugerował (i ja się z tym zgadzam), że idea testowania funkcjonalnego vs. niefunkcjonalnego nie ma już sensu. Zamiast mylić terminologię, testerzy powinni zdać sobie sprawę, że każdy typ testowania ma inną taktykę i cele.

Ponadto, istnieją sposoby na konstruktywne połączenie tych typów testów, czy to testów regresji, czy testów wydajności API.

Czy testowanie niefunkcjonalne w ogóle istnieje?

Niektórzy komentowali fakt, że termin “testowanie niefunkcjonalne” jest kompletnym nieporozumieniem. Michael Bolton żartobliwie porównał testowanie niefunkcjonalne do innych terminów, takich jak “niefizyczna nauka” lub “niejadalne jedzenie”.

Stwierdził, że sensowniejszym jest odnoszenie się do testowania w sposób twierdzący. W swoim komentarzu zasugerował:

„Myśl o testowaniu X jako o ‘testowaniu skoncentrowanym na ryzyku związanym z X’. Testowanie funkcjonalne skupia się na ryzyku, że funkcje w produkcie będą miały błędy; testy wydajności skupiają się na ryzyku związanym z wydajnością; testy regresji to testy skupiające się na ryzyku, że jakość ulegnie regresji (pogorszeniu) po wprowadzeniu zmiany. Każdy test koncentrujący się na jakimś ryzyku zapewnia również pewne zewnętrzne, przypadkowe lub incydentalne pokrycie innych rodzajów ryzyka, jeśli tylko zwrócimy na to uwagę”.

Mój kolega, Jim Hazen, również miał ważne spostrzeżenia na temat “testowania niefunkcjonalnego” (był słusznie zły, że nie oznaczyłem go w oryginalnym poście na LinkedIn, więc staram się najlepiej, jak potrafię nadrobić to niedopatrzenie w tym miejscu). Zgadza się on z tym, że nie ma sensu używać terminu “niefunkcjonalny”, aby opisać pracę niezbędną do sprawdzenia gotowości oprogramowania i systemu.

Zamiast tego Hazen przypomniał wszystkim uczestnikom dyskusji, że wszystko, co robi się w testach, jest albo udowadnianiem, albo obalaniem, albo potwierdzaniem hipotezy. Na przykład, zauważył, że jego testy wydajności sprawdzają, czy system zachowuje się zgodnie z jakimś oczekiwanym rezultatem, dlatego też są one typem testowania “funkcjonalnego”.

To wszystko doprowadziło nas do ostatniego (ale nie najmniej ważnego) spostrzeżenia:

Wynik: Wymagania dotyczące testów są ważne, etykiety testowe nie

Alan Page dobrze podsumował tę rozmowę, zauważając, że nie powinniśmy zbytnio zaprzątać sobie głowy etykietami. Zamiast tego, sugeruje on, aby testerzy skierowali swoją energię w stronę identyfikacji i analizy ryzyka i awarii w zależności od konkretnego kontekstu.

Z całego serca zgadzam się z tą koncepcją i zachęcam testerów do budowania strategii testowania opartej na tym, co jest potrzebne w konkretnej sytuacji, a nie na etykietach, które pozwalają na sprawdzenie przysłowiowego „pudełka czekoladek”.

Ale… jak pokazała dyskusja, musimy się bardziej postarać w naszych publikacjach branżowych, aby wskazówki, jakie dajemy testerom były odpowiedniej wartości.