Testy manualne a automatyczne

Jakiego testera potrzebujesz? W zestawieniu testy manualne a automatyczne nie można wskazać jednoznacznego zwycięzcy! Przeanalizowaliśmy pięć kluczowych obszarów biznesowych, aby tego dowieść. Sprawdź wnioski!   

Czym właściwie różnią się testy manualne od automatycznych? Tester manualny „przeklikuje” aplikację ręcznie. Nie potrzebuje znajomości języków programowania czy dodatkowych narzędzi. Tester automatyzujący wręcz odwrotnie - musi znać język programistyczny oraz framework. Nie sprawdza on zatem każdorazowo aplikacji manualnie tylko pisze polecenia, które dodatkowe narzędzie realizują za niego.

Oto 5 kategorii naszego praktycznego porównania testów od naszej Quality Assurance Specialist Samanty Vogel! 

1. Czasochłonność i pracochłonność

Wiele mówi się o tym, że testy automatyczne oszczędzają czas i nie wymagają takiego nakładu pracy jak testy manualne. Nie do końca zgadzam się z tym stwierdzeniem. Faktycznie przeprowadzenie testów przy pomocy frameworka jest dużo szybsze. Należy jednak pamiętać, że po pierwsze, napisanie skryptu testu zajmuje sporo czasu, a po drugie testy trzeba "pielęgnować". 

Z doświadczenia wiem, że skrypt, który napisałam dzisiaj, wcale nie musi się sprawdzić jutro. Nie jest to wynikiem błędu w oprogramowaniu, a po prostu zmianą w samej testowanej funkcjonalności czasem na pozór niezauważalną i nieprzewidywalną. Należy wtedy przeprojektować test, a to wiąże się z przeszukiwaniem wielu linii kodu w celu ich zmiany. Oznacza to także dodatkowy wysiłek w pełnym skupieniu, a więc dodatkowy czas pracy. 

2. Wykrywalność błędów

Powszechnie przyjmuje się, że testy automatyczne są dokładniejsze niż manualne, ponieważ wykonywanie przez komputer powtarzalnego skryptu pozwala na uniknięcie ludzkiego błędu. Mówiąc prościej: raz napisany test będzie porównywał aplikację do jej stanu w momencie pisania/edytowania skyptu i zrobi to tak dokładnie, jak było zaplanowane. Tester manualny może zwyczajnie przeoczyć, że z kodu zniknął jakiś element. Patrząc jednak z drugiej strony, jeżeli skrypty nie były aktualizowane, mogą pomijać błędy, które byłyby oczywiste dla testera sprawdzającego aplikację ręcznie. W tym wypadku zatem nie ma zwycięzcy! 

3. UX i UI

W tym temacie zdecydowanie wygrywają testy manualne! Jedynie człowiek jest w stanie ocenić aplikację pod względem jakości interakcji użytkownika z systemem (UX - User Experience), a także czy wszystkie elementy wizualne są intuicyjne i przyjazne dla odbiorcy (UI - User Interface). Na chwilę obecną nie jestem w stanie wyobrazić sobie automatyzacji takich testów.

4. Koszty

Testowanie manualne na pewno wiąże się z mniejszymi kosztami niż automatyczne. Tester automatyzujący powinien posiadać wiedzę i umiejętności testera manualnego oraz dodatkowo znać tajniki samej automatyzacji. To wszystko sprawia, że jego cena na rynku pracy jest wyższa. Ponadto, automatyzacja wiąże się z inwestycją w odpowiednie narzędzia, których nie potrzebują testerzy manualni.

Z drugiej strony za wytworzenie testu automatycznego płaci się raz, a testowanie manualnie ciągle tych samych funkcjonalności (np. przed każdym wdrożeniem kodu aplikacji) wymaga wielokrotnego ponoszenia kosztu za to samo.

5. Wyniki testów

Raportowanie wygląda podobnie jak sam proces testowania. W przypadku testów manualnych raporty tworzymy w oparciu o programy wspierające proces testowy, jednak wiele informacji musimy wprowadzić ręcznie. W przypadku testów automatycznych, framework, którego używamy, sam tworzy raporty. Dodatkowo nagrywa on testy oraz tworzy screenshoty. W tej kategorii wygrywa automatyzacja!

Testy manualne a automatyczne - podsumowanie

Reasumując, testy manualne a automatyczne to dość skomplikowane zagadnienie. Oba posiadają wady i zalety. Aby dobrać odpowiednio ich rodzaj, musimy wziąć pod uwagę wiele aspektów aplikacji. Testy manualne doskonale sprawdzają się w przypadku sprawdzania eksploracyjnych lub użyteczności, natomiast testy automatyczne w przypadku weryfikacji funkcjonalnych czy wydajnościowych oraz jako testy regresyjne. Zaryzykujemy stwierdzeniem, że niemal każdy projekt potrzebuje i jednego, i drugiego.