• Home
  • Blog
  • Tester automatyzujący vs. tester manualny

TECHNOLOGIE, ORGANIZACJA

21.09.2021 - Przeczytasz w 5 min.

Tester automatyzujący vs. tester manualny

21.09.2021 - Przeczytasz w 5 min.

Testy automatyczne wydają się bardziej atrakcyjne od testów manualnych, może nie zawsze słusznie, jednak opanowanie tej umiejętności jest dla wielu testerów spełnieniem zawodowych ambicji. Jak zapobiegać błędom, tym najbardziej typowym i dlaczego warto docenić testera manualnego oraz jaki jest wkład takiej osoby do projektu?

RST sofware - testy automatyczne vs. testy manualne

Zacznijmy od przykładu prostego, typowego zadania. Mamy napisać test automatyczny nowej funkcjonalności. Wybieramy narzędzia, języki, piszemy kod testów – kilka godzin, czasem kilka dni, tygodni. Testy ,,przechodzą”, jesteśmy zadowoleni, idziemy krok dalej, wpinamy Jenkinsa, przecież chcemy mieć continuous integration.

Nasze testy chodzą cyklicznie, jak należy i pewnego dnia następuje pewnego rodzaju szok. Nasze testy, działające ,,jak złoto”, nagle zaczynają rzucać błędami we wszystkie strony.

RST sofware - testy automatyczne vs. testy manualne

Okazuje się, że nie było nowego wdrożenia, wszystkie środowiska działają jak należy, a test powtórzony ręcznie nie zgłasza problemów. Tracimy kolejne godziny na odkrycie przyczyny problemu, przyglądamy się  szczegółom i jak widać jesteśmy w pułapce.

Testy, które działają  (zazwyczaj…) tzw. testy „kruche”

Mogą one świetnie działać w naszym lokalnym środowisku, jednak w zupełnie innej konfiguracji kończy się to wielogodzinnym dochodzeniem, debugowaniem, stresem, blokowaniem wdrożeń itd.

Jaka może być przyczyna takiej sytuacji?

Otóż, im bardziej złożony system, tym więcej w nim zależności, usług, mikrousług, baz danych, modułów. Szansa na to, że wszystkie elementy systemu w danym momencie, w danym środowisku (szczególnie w środowisku testowym) zachowają się przewidywalnie jest, delikatnie mówiąc, zerowa. To częste zjawisko, zwłaszcza w przypadku testów interfejsów graficznych. Na pierwszy rzut oka z systemu da się korzystać, a testy automatyczne nie dają nam żyć.

 

Może być jeszcze gorzej, gdy w wynikach  naszych testów zastanie nas taka sytuacja:

        
linia13:25627 Unicestwiony
        
    

Nie bez powodu opieram się na przykładzie aplikacji webowej, zintegrowanej. W wielu firmach pierwszym, podstawowym sposobem na testowanie aplikacji jest użycie Selenium i mozolne testowanie GUI. Owszem, dzięki temu wprowadzamy testy do projektu, ale czy to nam gwarantuje rzetelny pomiar jakości? Zapominamy o mnogości warstw i etapów tworzenia systemu, których przetestowanie może dać o wiele lepsze efekty.

RST sofware - testy automatyczne vs. testy manualne

Mam na myśli testy komponentowe, integracyjne, kontraktowe, które możemy wykonać o wiele szybciej, nie mając pełnego środowiska, i które dadzą nam pełny obraz tego, co się dzieje z naszym systemem.

 

Wiele firm skłania się do testowania jedynie interfejsu użytkownika, bądź największy wysiłek kładzie na testy GUI, co osobiście odradzam. Błędy znalezione na samym końcu procesu, często prowadzą do niepowodzenia całego projektu. System posiada już tak wiele zależności, że nie możemy znaleźć przyczyny porażki. Programiści zapomnieli, co napisali. Wymagania biznesowe zostały spełnione, ale nagle okazuje się, że pominięto jeden ważny szczegół. Chciałoby się to szybko odkręcić, niestety później okazuje się, że zmiana nie zajmie kilku dni, a … kilka miesięcy!

False positive

Innym skutkiem przeprowadzania testów w sposób powierzchowny i niedbały może być nagromadzenie wyników false positive. Pokazują one, że aplikacja nie działa, ale nie dają nam żadnego rozwiązania i nie pokazują przyczyny tej sytuacji. Zwykle okazuje się, że taki wynik nie świadczy o błędzie w systemie, co nie zmienia faktu, że często stawia na nogi połowę firmy. Po jakimś czasie zaczynamy go ignorować lub – w najlepszym wypadku – wyłączamy taki test. W skrócie, false positive znieczula nas na błędy i usypia naszą czujność.

Wszystko się zmienia w sytuacji, gdy aplikacja naprawdę przestanie działać, gdy jakaś usługa zależna zmieni kontrakt lub sposób komunikacji z nami. W takiej sytuacji nawet nie będziemy świadomi powstałego problemu.

„Ten test zawsze nie przechodzi” – pomyślimy.

Jednak może się okazać, że tym razem powód jest zupełnie inny i stanowi to realne zagrożenie dla aplikacji. Podsumowując, takie testy lepiej usunąć niż utrzymywać,  przynoszą więcej szkód, niż pożytku.

Jakość kodu ma znaczenie

Przyjęło się, że tester nie musi umieć programować, ale tak naprawdę zależy to od nas samych, czy i jak chcemy się rozwijać. Pisanie nawet najprostszych skryptów testowych nie zwalnia nas z obowiązku pisania kodu, który wygląda przyzwoicie, jest łatwy w utrzymaniu i można go łatwo wykorzystać w innych częściach naszych testów.

Kod pisanych przez nas testów świadczy o samej aplikacji, którą testujemy. Jeśli nasz software ma przygotowane solidne testy, to wprost świadczy o jakości wykonania samej aplikacji. Testy powinny być oceniane (poprzez np. code review, do którego bardzo wszystkich zachęcam). Pracując z programistami, warto pokazywać im fragmenty naszej pracy. Ten kod jest przygotowany również dla nich, a współpraca developerów z testerami ma wpływ na efektywność i powodzenie projektu.

Z tego względu dobrym pomysłem może być przechowywanie kodu testów w głównym repozytorium aplikacji czy też mikrousługi. Przede wszystkim nie chowamy się ze swoim kodem w piwnicy, a przez większą otwartość na konstruktywną krytykę przy code review zapewniamy wyższą jakość kodu oraz łatwiejszy dostęp, także dla programistów.

Szybkość  testów

Ilu programistów korzysta z testów, które trwają dłużej niż kilka minut? Moim zdaniem nikt. Tester powinien mieć na uwadze, że pisze kod, który powinien być wartościowy także dla programistów. Jeśli testy trwają 8 sekund, jest szansa, że developer sprawdzi daną funkcjonalność. Jeśli czas wzrasta do przykładowych 3 minut, bo np. nie chce nam się testować lokalnie, stawiać aplikacji, użyć Dockera, dochodzi do kuriozalnej sytuacji, w której zgłaszamy błędy, a często problem rośnie do ogromnej rangi.

W takiej sytuacji polecam zastosowanie podejść  *DD (TDD, BDD etc.), które dają nam krótszy czas wykonania testu (często są to testy niższego poziomu), a  samo odseparowanie testowanej aplikacji też bywa bardzo przydatne, zwłaszcza, kiedy jeszcze nie jest zintegrowana z wieloma modułami. Możliwość wpięcia jej do continous integration to tylko kolejna zaleta, którą możemy się później pochwalić.

 

Testy muszą być wydajne

To właśnie wydajność, złożoność obliczeniowa ma ogromne znaczenie (więcej na ten temat możesz posłuchać w nagraniu: 12min 00sek). Tak jak pokazał nasz przykład, test nie może być zbyt złożony obliczeniowo, finalnie zaburzył pracę maszyny, pracę developerów  i ,,wywalał się”. Przykład ten pokazał, że tester powinien szerzej patrzeć na każdy przypadek.

 

Może jednak testy manualne?

Nie zgodzę się z powszechną opinią, że bycie testerem manualnym jest mniej ambitne i że jest to domena początkujących testerów. Są sytuacje, w których tester manualny sprawdzi się lepiej od testera automatycznego. Założenie, że zautomatyzowanie wszystkiego pozwoli nam na zwolnienie testerów i cięcie kosztów w firmie, moim zdaniem jest błędne.

Te dwie role różni przede wszystkim punkt widzenia.

RST Software Blog Tester automatyczny vs. tester manualny

Warto pamiętać, że tester powinien pisać testy, które mają za zadanie coś zepsuć, o czym nie zawsze myślą zwłaszcza niedoświadczeni. Zdarzają się sytuacje, w których celowo piszemy testy, które mają „przechodzić”, czego absolutnie nie polecam. 

 

Bardzo często zdarza się, że projekty upadają przez brak sprecyzowanych oczekiwań, złą ocenę wymagań, niewłaściwe sformułowanie. Mimo, że wszyscy o tym wiemy, ten temat wraca w każdej organizacji jak bumerang (takiego przykładu możesz posłuchać 16min20sek). 

 

Obszary istotne dla testera manualnego, które wg mnie warto podkreślić to:

  • testy eksploracyjne (nie są aż tak nudne, nie mamy narzuconych sztywnych reguł, wymagają od nas myślenia, nie wpadamy w rutynę),
  • testy bezpieczeństwa (jeśli mamy na to czas, warto skorzystać, zerknąć w kod aplikacji, spróbować swoich sił jako włamywacz, pozwalają nam się rozwijać),
  • warunki brzegowe (szukajmy, psujmy, próbujmy, to dobra miara jakości).

 

Podsumowując

Język programowania nie ma znaczenia – wg mnie nie ma sensu dyskusja pomiędzy tym czy Pyhton czy Java, czy używamy narzędzia A, czy narzędzia B – szkoda na to czasu, w kilka dni możemy nauczyć się podstaw. Trudniej znaleźć nam metody pozwalające pisać testy szybkie, stabilne, bez false positive.

Test jest produktem – nasz kod jest częścią aplikacji, którą tworzymy, nie możemy się tego wstydzić, tester też może programować.

Weryfikacja potrzeb biznesowych – oszczędzamy czas i pieniądze, reagujmy tak szybko jak możemy.

Nie dzielimy testerów jeśli ktoś wykonuje jeden typ testów, to wg mnie jest to za mało, powinniśmy mieszać te typy, dążyć do różnorodności i stosowania różnych technik.

 

Artukuł powstał na podstawie wystąpienia Piotra podczas spotkania RST CodeMeeting, całość możesz obejrzeć tutaj.

Ocena artykułu

Udostępnij

Piotr Wilkosz RST

Piotr Wilkosz

Developer

Developer z kilkuletnim doświadczeniem testerskim. Pracuje przy tworzeniu stabilnych i wydajnych aplikacji backendowych będących podstawą złożonego systemu. Miłośnik przejrzystego kodu i prostych rozwiązań.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.