Celem testowania aplikacji jest oczywiście sprawdzenie, czy kod i wszystkie wprowadzone funkcjonalności działają poprawnie. Nikt nie chce przecież oddać w ręce użytkowników narzędzia, w którym nie ma pewności, że poszczególne moduły działają jak należy.
To, jak istotne są testy, pokazują też kwestie finansowe: oczywiście nie ma tu reguły, ale bywa, że testy stanowią nawet 15-25 proc. budżetu projektu oraz dodatkowy czas realizacji.
Testy manualne a automatyczne
Tylko który sposób weryfikacji wybrać?
Testy manualne, jak sama nazwa wskazuje, polegają na ręcznym sprawdzeniu funkcjonalności. Tester oprogramowania przeklikuje się wówczas przez poszczególne opcje, dokładnie tak, jakby robił to użytkownik końcowy.
Próba manualna ma oczywiście swoje plusy i minusy. Z jednej strony nie wymaga ona od osoby testującej wysokich umiejętności programistycznych, z drugiej jednak trzeba zatrudnić testera doświadczonego w UX, liczyć się z tym, że może on popełnić błąd (to tylko człowiek), no i sam proces ręcznego testowania jest z reguły czasochłonny
Testy automatyczne aplikacji opierają się z kolei na programowaniu i zastosowaniu określonych skryptów. Maszynowe testowanie przebiega sprawniej i jest bardziej niezawodne w porównaniu z testowaniem ręcznym (szybsze wychwycenie większej ilości błędów), chociaż powodzenie próby zależy też oczywiście od jakości przygotowanych skryptów. Dużą zaletą automatu jest też powtarzalność testów.
Pewnym minusem może być z kolei ryzyko, że ocena UX nie będzie bardzo dokładna, bo przecież nie otrzymujemy feedbacku od żywego człowieka.
Która metoda jest lepsza? Trudno to jednoznacznie ocenić. Jedni stawiają na próby automatyczne, drudzy traktują je jako uzupełnienie manualnych (lub odwrotnie), jeszcze inni uważają, że pewne elementy aplikacji zawsze powinny być sprawdzane przez testera. Tak więc - to zależy.
Mateusz Portka, programista agencji interaktywnej Bloomnet:
- Wybór testu uzależniłbym od wielkości i skomplikowania projektu, tego, ile osób będzie przy nim pracowało oraz obszarów, które chcemy sprawdzić. Nie ma tutaj reguły: można sprawdzać aplikację od A do Z, pójść na kompromis i przetestować tylko kluczowe funkcjonalności lub stworzyć same testy integracyjne spinające większe funkcjonalności. Szkoły są tutaj różne, chociaż moim zdaniem w większym projekcie praktycznie niemożliwe jest przetestowanie manualne całego projektu przy każdej zmianie czy aktualizacji w systemie. Pamiętajmy bowiem, że testy sprawdzają przeważnie kilka scenariuszy oraz pokrywają miejsca, których użytkownik nie widzi lub nie jest ich świadomy.
Jak pisać testy automatyczne?
Oba rozwiązania mają swoich zwolenników, chociaż testy automatyczne są już popularniejsze.
Widać to zresztą po ofertach pracy - znacznie częściej dotyczą one specjalistów znających bardzo dobrze języki programowania i potrafiących przygotować określone skrypty. Dlatego przyjrzyjmy się bliżej właśnie testom automatycznym.
Dobór konkretnych narzędzi zależy tutaj oczywiście od technologii i tego, co dokładnie chcemy przetestować. Czytając artykuły o testach często możemy jednak spotkać się z takimi skrótami jak TDD i BDD. Czego one dotyczą? Są to skróty dwóch najpopularniejszych metod, w których tworzy się kod i testy aplikacji.
TDD (Test-Driven Development) - technika tworzenia kodu zaliczana do tzw. metod zwinnych (agile). Występuje tutaj schemat, który możemy opisać w trzech ogólnych krokach:
- tworzenie testu sprawdzającego dodawaną funkcjonalność, chociaż samej funkcjonalności jeszcze nie ma w aplikacji i test nie wykona się poprawnie,
- dodawanie funkcjonalności, teraz test powinien wykonać się już poprawnie,
- uporządkowanie kodu, aby spełniał on wymagane standardy.
BDD (Behavior-Driven Development) – oprogramowanie tworzone jest na podstawie zebranych wymagań w formie tzw. stories, czyli historyjek. Każda historyjka bazuje na schemacie: given, when, then. Given reprezentuje warunki początkowe (rola użytkownika, określenie kontekstu historyjki), when to konkretna akcja, a then oczekiwany rezultat. Spójrzmy na taki przykład:
- given: zalogowany użytkownik ma w koszyku produkty o wartości 150 zł,
- when: użytkownik dodaje do koszyka kolejny produkt o wartości 20 zł,
- then: suma produktów w koszyku powinna wynosić 170 zł.
Co dają nam takie wymagania w formie historyjek? Przede wszystkim jasno określają, jakie działanie biznesowe ma zostać wykonane, a także dostarczają informacji, czy będą one dla wszystkich wystarczająco zrozumiałe.
Rodzaje testów automatycznych
Wśród testów automatycznych oprogramowania można oczywiście wyszczególnić kilka podstawowych typów i poziomów. Ich zastosowanie zależy m.in. od tego, z jak rozbudowaną aplikacją mamy do czynienia oraz jakie jej obszary mają zostać poddane sprawdzianowi.
Ogólne typy testów:
- Funkcjonalne - sprawdzamy konkretną funkcjonalność;
- Niefunkcjonalne - jak sama nazwa wskazuje, nie testujemy tutaj określonych funkcjonalności, tylko działanie systemu m.in. w takich obszarach jak jego wydajność przy bardzo dużym obciążeniu czy niezawodność zabezpieczeń;
- Strukturalne - testy skupiające się na weryfikacji poprawności kodu źródłowego aplikacji;
- Związane ze zmianami - wykonujemy je po wprowadzeniu określonych zmian do kodu źródłowego, wyróżnia się retesty (testy po usunięciu błędu) oraz testy regresywne (próby sprawdzające, czy po wprowadzonych zmianach nie pojawiły się błędy w innych częściach aplikacji).
Można też wyszczególnić cztery główne poziomy testowania oprogramowania:
- Jednostkowy - sprawdzamy pojedynczą metodę, funkcję, moduł;
- Integracyjny - testujemy wiele modułów lub funkcji i sprawdzamy, czy dobrze ze sobą współpracują;
- Systemowy - sprawdzamy, czy wszystkie elementy systemu działają zgodnie z założeniami, test użytkownika końcowego;
- Akceptacyjny - ostatni poziom testów, którego zadaniem nie jest wyłapywanie błędów (tych teoretycznie nie powinno już być), a sprawdzenie, czy system spełnia stawiane przez klienta wymagania biznesowe.
Dlaczego testy są tak ważne?
Testy, chociaż są dość mozolnym działaniem wymagającym dodatkowego wysiłku i znajomości określonych narzędzi, przynoszą wymierne korzyści.
Należy je wykonywać, bo przecież trzeba upewnić się, czy użytkownik będzie mógł bez problemu skorzystać z poszczególnych funkcjonalności, czy po wykonaniu przez niego określonej czynności system zareaguje jak należy, co się stanie, kiedy wprowadzi błędne dane itd. To mnóstwo scenariuszy, które należy sprawdzić.
- Warto pisać testy, ponieważ dzięki nim mamy pewność, że nasz projekt działa poprawnie mimo zmian lub nowych funkcjonalności dodawanych często przez osoby mniej lub bardziej znające dany system. Testy to także swoista dokumentacja: każdy jest odpowiednio opisany, informuje co powinien wykonywać i jak później ma na to reagować aplikacja - podkreśla Mateusz Portka z agencji Bloomnet.
Lepiej więc podejść do tego rzetelnie i nie iść drogą na skróty. Nierzadko zdarza się, że klient z ograniczonym budżetem chce jak najszybciej wypuścić MVP na rynek, dlatego przekonuje, aby nie wykonywać testów lub robić tylko manualne w ograniczonym zakresie. Takie podejście może się jednak zemścić, jeśli rynek bardzo pozytywnie zareaguje na projekt i będzie trzeba go szybko rozwijać.
***
W kategorii "software" czytaj także:
- Czym jest repozytorium kodu strony?
- Aplikacje mobilne dla firm. Kiedy warto w nie inwestować?
- Jak przeprowadzić audyt informatyczny?
- 4 pytania o outsourcing IT dla firm
Źródła:własne