Czym jest testowanie funkcjonalne oprogramowania
Testowanie funkcjonalne ma na celu sprawdzenie, czy aplikacja działa zgodnie z wymaganiami w określonych warunkach. Osoba testująca na różnych poziomach testów sprawdza, czy oprogramowanie działa zgodnie z wymaganiami biznesowymi, postawionymi przez interesariuszy, oraz czy spełnia oczekiwania użytkowników.
Testy funkcjonalne to jeden z 4 tradycyjnych typów testów. Składają się na nie testy funkcjonalne, testy niefunkcjonalne, strukturalne oraz związane ze zmianą. Testy te sprawdzają czynności, do wykonywania których program jest przeznaczony, a mówiąc prościej: sprawdzają, czy program robi to, co powinien.
Żeby to sprawdzić, musimy najpierw wiedzieć… co powinien robić program. Klasycznie odpowiedzi na to pytanie powinniśmy szukać w specyfikacji wymagań, dokumentacji, a w ostateczności musimy liczyć na nasze doświadczenie.
Testowanie funkcji na różnych poziomach – podstawowy podział testów funkcjonalnych
Ważne, aby na tym etapie pamiętać, że typy testów i poziomy testów to pojęcia niezależne od siebie.
Typy testów wyznaczają nam ich cel. W tym wypadku jest to sprawdzenie zachowania aplikacji i zweryfikowanie, czy jest zgodne ze specyfikacją oraz wymaganiami użytkowników.
Poziomy testów odnoszą się do faz wytwarzania oprogramowania i ich podstawowy podział to: testy jednostkowe, integracyjne, systemowe i akceptacyjne. W tym artykule nie będziemy skupiać się na szerszym rozwijaniu tego podziału, ale musimy pamiętać, że testy funkcjonalne powinny być wykonywane na każdym dostępnym poziomie testowania.
Testy jednostkowe
Testy funkcjonalne na poziomie testów jednostkowych to zazwyczaj domena programistów, ponieważ to oni zazwyczaj odpowiadają za tworzenie i utrzymanie unit testów. Na tym poziomie sprawdzają, czy pojedyncza metoda / funkcja robi to, co powinna, np. czy wywoływana jest odpowiednia akcja lub czy obliczenia są poprawne. Jest to najniższy z poziomów testów, same testy powinny być proste i wykonywać się bardzo szybko. Dlatego właśnie ten poziom testów powinien być podstawą automatycznej weryfikacji poprawnego działania oprogramowania.
Testy integracji
Testy integracyjne natomiast mogą być domeną zarówno testerów, jak i developerów. Podstawowym wyznacznikiem będzie tutaj to, na jakim poziomie sprawdzamy integrację. Jeżeli sprawdzamy integrację pojedynczych metod i funkcji (po sprawdzeniu testami jednostkowymi, czy one same działają), to raczej będzie to domena programistów. Jeżeli jednak będziemy testować integrację na wyższym poziomie, np. integracje między dwoma modułami aplikacji, to pracę tę może, a często powinien, wykonywać tester. Wynika to z faktu, że programista testujący swój własny kod testuje swoją interpretację wymagań, ale niekoniecznie tę prawidłową. Nie jest to przytyk w kierunku programistów, ale raczej wskazanie, dlaczego nie powinno testować się własnych rozwiązań.
Testy systemu
To jednak testy funkcjonalne na poziomie systemowym stanowią ten domyślny rodzaj testów w oczach większości osób. Testowanie systemowe jest to sprawdzanie funkcjonalności oprogramowania na zintegrowanym środowisku, gdzie funkcjonalności możemy testować od początku do końca (end-to-end). Jest to też poziom, który jest najbardziej intuicyjny dla początkujących testerów czy osób z testowaniem niezwiązanych. Ale to nie wszystko – skoro jest to testowanie funkcjonalności od początku do końca, to są to również bardzo istotne testy z punktu widzenia biznesu i interesariuszy, bo użytkownicy końcowi będą korzystać z oprogramowania w bardzo podobny sposób. Często dopiero teraz możemy zwrócić uwagę na poprawność interfejsu użytkownika (zarówno zgodność z makietami, jak i prostotę jego obsługi) oraz kwestię poprawności prezentowania danych użytkownikowi. Na tym poziomie możemy w końcu sprawdzić dostępność produktu dla osób z niepełnosprawnościami, co jest szczególnie istotne dla testerów pracujących w instytucjach publicznych.
Testy akceptacyjne
Testy akceptacyjne to ostatni etap testów, który jest wykonywany zazwyczaj na gotowym produkcie, przez użytkowników końcowych, przez klienta lub z jego udziałem. Testy funkcjonalne przeprowadza się na tym poziomie, aby ostatecznie zweryfikować i zatwierdzić, że powstały produkt spełnia stawiane mu wymagania. Jest to także ostatni etap na znalezienie defektów przed przekazaniem produktu użytkownikom końcowym i ostatni dzwonek by sprawdzić zgodność produktu z wymaganiami wynikającymi z legislacji.
Czytaj również: Czym jest piramida testów? Co, kiedy i w jaki sposób testować?
Jak wykonujemy testy funkcjonalne?
Omówiliśmy testy funkcjonalne na różnych poziomach, ale odpowiedzmy sobie na pytanie, jak je wykonać? Jak często w testowaniu bywa: „to zależy”. Testy na wszystkich poziomach, oprócz testów jednostkowych, można wykonać z mniejszym lub większym sukcesem manualnie.
W przypadku testów integracyjnych często potrzebować będziemy dodatkowego oprogramowania do pomocy, ale nie zmienia to faktu, że dobrze zaprojektowane testy możemy wykonać ręcznie.
Testami automatycznymi możemy pokryć wszystkie wymienione wcześniej poziomy testów. Pozwala to na skuteczne prowadzenie testów regresji, a także buduje zaufanie do powstającego produktu, ponieważ jest on regularnie sprawdzany pod kątem poprawności działania (testy automatyczne nie służą do znajdowania błędów, lecz do upewniania się, że funkcjonalności, które już działały, nadal to robią).
Najważniejsze biznesowo ścieżki podczas testów akceptacyjnych warto sprawdzić manualnie, aby ostatecznie upewnić się, że produkt jest gotowy do udostępnienia użytkownikom. Testami automatycznymi przy testach akceptacyjnych warto się wspierać, aby ograniczyć wykonywanie powtarzalnej pracy (np. przekierowania przy dużej liczbie wersji językowych, tłumaczenia itp.).
Testy białoskrzynkowe czy czarnoskrzynkowe?
Wiemy już, czym są testy funkcjonalne, jaki mają cel, na jakich poziomach powinniśmy je wykonywać oraz kto może takie testy wykonać. Czas odpowiedzieć na pytanie: w jaki sposób określić, jak przetestować nasze cechy funkcjonalne?
Testy oparte o dokumentację
Tak jak już wspominałem w tym artykule, testy funkcjonalne sprawdzają poprawność działania oprogramowania w odniesieniu do wymagań klienta, ale również pod względem zgodności z wymaganiami użytkowników.
Zgodność z wymaganiami klienta
Skupmy się na początku na zgodności z wymaganiami klienta. Wymagania te zazwyczaj są ujęte w specyfikacji, wymaganiach, makietach i każdej innej formie dokumentacji. Projektowanie testów na podstawie dokumentacji to wykorzystywanie technik czarnoskrzynkowych w praktyce. Początkujący testerzy często nawet nie wiedzą, że projektując testy, korzystają z opisanych i popularnych technik czarnoskrzynkowych. Dzieje się tak, ponieważ podstawowe techniki są proste i intuicyjne.
Przeczytaj także: Co łączy testera z branżą filmową? Czyli scenariusze testowe bez tajemnic
Zgodność z oczekiwaniami użytkowników
Drugą częścią testów funkcjonalnych jest sprawdzenie zgodności z oczekiwaniami użytkowników. Wtedy to doświadczenie testera jest bardzo ważne. Mam tutaj na myśli zarówno doświadczenie testerskie, jak i branżowe. W tych testach opieramy się na technikach bazujących na doświadczeniu jak np. zgadywanie błędów, testy eksploracyjne czy korzystanie z list kontrolnych.
Podsumowując, testerzy dysponują wachlarzem różnych technik, jedne wymagają intuicji, inne doświadczenia. Ich wspólnym mianownikiem jest rezultat: dobrze zaprojektowane testy, których wykonanie pozwala znaleźć defekty lub zwiększyć nasze zaufanie do jakości wytwarzanego oprogramowania.
Podsumowanie: czy warto zainteresować się testami funkcjonalnymi?
W ramach testów funkcjonalnych aplikacji testerzy są odpowiedzialni za testowanie funkcji na różnych poziomach. Używane do poszukiwania błędów techniki dają bardzo duże możliwości rozwoju i wyspecjalizowania się. Zapraszam was do obejrzenia spotkania z cyklu BiteIT, w którym znajdziecie więcej informacji o niezbędnych kompetencjach testera i rekrutacji w testach:
Od 5 lat tester oprogramowania w Inetum. Zaczynał od stażu, a teraz sam realizuje się w roli wykładowcy i mentora. Współorganizator Akademii JTestera oraz wykładowca w Software Development Academy. Uważa, że testowanie to sztuka zadawania odpowiednich pytań, a zapobieganie błędom jest ważniejsze niż ich szukanie. Ceni sobie pracę zespołową i prawdziwy Scrum. Prywatnie miłośnik kina i piwnej rewolucji.