Ciemna strona testowania automatycznego & dlaczego testowanie ręczne nadal ma znaczenie

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Testy automatyczne stały się tak integralną częścią niektórych procedur, że niektórzy testerzy zastanawiają się, czy całkowicie zastąpią testy manualne.  Nie w najbliższym czasie.  Gdy zespół Tesli projektował Model 3, jednym ze sposobów na zwiększenie tempa produkcji miała być w pełni zautomatyzowana linia montażowa. AI miała składać samochód niemal bez nadzoru człowieka.  Plan zakończył się katastrofalną […]

Testy automatyczne stały się tak integralną częścią niektórych procedur, że niektórzy testerzy zastanawiają się, czy całkowicie zastąpią testy manualne. 

Nie w najbliższym czasie. 

Gdy zespół Tesli projektował Model 3, jednym ze sposobów na zwiększenie tempa produkcji miała być w pełni zautomatyzowana linia montażowa. AI miała składać samochód niemal bez nadzoru człowieka. 

Plan zakończył się katastrofalną porażką.

Samochody zderzały się ze sobą, drzwi były wiercone w szybach, a opony nie chciały prawidłowo osadzać się na felgach. 

Co się stało? Okazało się, że roboty nie potrafią zbyt dobrze widzieć. AI odpowiedzialna za składanie Modelu 3 nie była w stanie dostosować się do nieoczekiwanych komplikacji ani niewielkich przesunięć. Jeśli wszystko nie było ustawione dokładnie we właściwy sposób, popełniała katastrofalne błędy. 

To samo dotyczy testów automatycznych w QA. Niektóre formy testowania mają zbyt wiele zmiennych i wymagają od testera manualnego umiejętności korygowania przebiegu oraz rozwiązywania problemów na bieżąco. 

Czym są testy automatyczne?

Testy automatyczne oznaczają, że tester QA używa narzędzia do wykonania przypadku testowego. W cyklu tworzenia oprogramowania ten sam przypadek testowy będzie testowany wielokrotnie.

Niektóre przypadki testowe, których ręczne przeprowadzenie zajęłoby zespołowi testerów QA wiele godzin, narzędzie do testów automatycznych może wykonać w kilka minut. Kilka narzędzi do testów automatycznych stało się standardem branżowym. 

Ciemna strona testów automatycznych

Inne branże, rzemiosła i zawody musiały zmierzyć się z wprowadzeniem automatyzacji w swojej dziedzinie. Za każdym razem, gdy do tego dochodziło — czy to w lotnictwie w przypadku autopilota, tkactwa dywanów czy testowania — pracownicy danej dziedziny tracili zrozumienie „dlaczego” kryjącego się za ich pracą.

To zjawisko zauważył u testerów specjalista QA, Jan Jaap Cannegieter. Obawia się przede wszystkim, że łatwość przeprowadzania testów automatycznych i rosnąca presja na automatyzację znacznej części procesu testowania doprowadzą do powstania pokolenia testerów, którzy wiedzą, jakie działania wykonywać, ale nie rozumieją, dlaczego. 

Wielu testerów wie wszystko o określonych narzędziach lub językach programowania, ale nie potrafi mi powiedzieć, co testuje i dlaczego to testuje. A to niedobrze.

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Przykłady złych testów automatycznych

Wielu testerów QA dostrzega ten sam potencjał w testach automatycznych. Zazwyczaj oznacza to, że można zaobserwować pewne trendy i typowe błędy, które może popełnić tester QA. Oto kilka typowych przykładów złych testów automatycznych. 

Zagnieżdżanie testów automatycznych

Zagnieżdżanie testów automatycznych ma miejsce wtedy, gdy kilka testów automatycznych działa jeden na drugim.  Gdy tak się dzieje, trudno ustalić, co poszło nie tak, kiedy pojawi się błąd. 

W krótkiej perspektywie większość przypadków testów automatycznych przynosi pozytywne rezultaty. Tester QA używa właściwego narzędzia i uruchamia je prawidłowo. 

Wiele przykładów złych testów automatycznych staje się problematycznych dopiero sześć miesięcy później, gdy testy automatyczne zostają zagnieżdżone w innych testach automatycznych, które z kolei są zagnieżdżone w jeszcze innych testach automatycznych. 

Testy automatyczne interfejsu użytkownika bez nadzoru

Testowanie interfejsu użytkownika ma zapewnić, że użytkownik nie może wykonać w interfejsie żadnej czynności, która spowodowałaby awarię programu lub jego nieprawidłowe działanie. Ręczne testowanie tego elementu może wymagać udziału wielu testerów i dużych nakładów pracy. Szczerze mówiąc, taki sposób testowania jest nieefektywny, zwłaszcza gdy program się rozrasta i trzeba testować coraz więcej funkcji. 

Dzięki testom automatycznym proces przebiega szybciej, ale nadal może wymagać pełnej mocy obliczeniowej komputera testera QA przez cały dzień. Aby sobie z tym poradzić, testerzy QA uruchamiają test pod koniec dnia, pozwalają mu działać przez noc, a następnego ranka wracają do pracy i znajdują gotowe wyniki. Brzmi sensownie, prawda? 

Na pierwszy rzut oka wydaje się to rozsądnym rozwiązaniem. Tester QA używa w ciągu dnia swojego komputera do testowania innych programów, a następnie w nocy uruchamia testy automatyczne interfejsu użytkownika.

To właśnie dlatego, że ma to intuicyjny sens, jest to częsty błąd. Podczas testów automatycznych przeprowadzanych bez nadzoru wiele rzeczy może pójść nie tak.

Jeśli coś pójdzie nie tak na wczesnym etapie, reszta wyników będzie błędna. Cały dzień testów nie przyniósł żadnych użytecznych informacji, ponieważ wystąpił błąd, który można było łatwo wykryć i skorygować, gdyby ktoś sprawdził, czy test automatyzacji działa prawidłowo.

Chociaż testowanie automatyczne może czasami prowadzić do fałszywie pozytywnych wyników, wybór odpowiednich narzędzi do automatyzacji QA może znacznie ograniczyć takie przypadki. 

Automatyzowanie niewłaściwych rzeczy

Konfiguracja testowania automatycznego zajmuje czas. Zespół QA musi upewnić się, że narzędzia do automatyzacji są odpowiednie dla projektu oraz że testerzy QA wiedzą, jak prawidłowo z nich korzystać. 

Wszystko to wymaga dużej ilości czasu i organizacji, a jeśli efektem końcowym jest zautomatyzowanie testu, który zwykle uruchamia się raz w miesiącu, wysiłek ten nie jest wart zachodu. Zanim rozpoczniesz testowanie automatyczne, upewnij się, że to, co zamierzasz zautomatyzować, zaoszczędzi testerom QA wymierną ilość czasu.

Nie tylko można zautomatyzować zadania, które występują zbyt rzadko, by było to warte wysiłku — niektórych zadań po prostu nie da się łatwo zautomatyzować.

Zastępowanie testowania manualnego

Testowanie automatyczne może wykryć tylko to, czego zostało nauczone szukać. Jeśli czcionki na stronie internetowej wyglądają dziwnie, ale test sprawdzał wyłącznie, czy wszystkie odnośniki w witrynie działają, rozwiąże jeden problem (odnośniki), ale nie wykryje, że z drugim coś jest nie tak (czcionki). 

Testowanie manualne może wykryć rzeczy wykraczające poza początkowy zakres testu. Metoda testowania eksploracyjnego została opracowana z myślą o zapewnieniu testerowi QA przestrzeni do znajdowania nieoczekiwanych błędów w miarę ich pojawiania się, nawet jeśli początkowo nie szukał właśnie ich. Skupione na pojedynczym zadaniu testowanie automatyczne może być dokładne. Nie może jednak być kompleksowe. 

Przykłady dobrego testowania automatycznego

Automatyzację testów przeprowadza się w celu zminimalizowania ryzyka. Gdy tester QA może ograniczyć ryzyko i zmaksymalizować efektywność, zdecydowanie należy przeprowadzić testowanie automatyczne.  Nie ma powodu, aby tester QA spędzał godziny na ręcznym sprawdzaniu odnośników na stronie internetowej, skoro crawler internetowy może wykonać tę samą czynność w krótszym czasie i z mniejszym prawdopodobieństwem popełnienia błędu.

Dobrą zasadą przy podejmowaniu decyzji, kiedy zamiast testowania manualnego należy zastosować testowanie automatyczne, jest zadanie sobie pytania, czy test będzie szybki lub ciągły. Jeśli test ma być uruchamiany stale, właściwym rozwiązaniem jest testowanie automatyczne. 

Ludzie wypadają gorzej niż maszyny, jeśli chodzi o konsekwentne wykonywanie powtarzalnych zadań na wysokim poziomie. Pragniemy nowych bodźców i przestajemy angażować się umysłowo, gdy przez zbyt długi czas robimy to samo. W rezultacie błędy mogą pozostać niezauważone. 

W ten sposób tester QA zda sobie sprawę, że: a) poświęcił więcej czasu, niż zajęłoby mu przeprowadzenie testowania automatycznego, oraz b) wykonał gorszą pracę i spowodował więcej problemów w późniejszym czasie. 

Jason Huggins, twórca popularnego narzędzia do testowania automatycznego Selenium, opracował ten program, ponieważ zauważył, że tak wiele dni pracy testera spędzał na wykonywaniu tych samych zadań — zadań, które jego zdaniem były na tyle proste i oczywiste, że mógłby je wykonać nawet robot. Dlatego stworzył skrypt, który automatycznie testował za niego funkcjonalność przeglądarki. Odniósł on natychmiastowy sukces i szybko stał się standardem branżowym. 

Nawet specjaliści QA sceptyczni wobec testowania automatycznego wiedzą, że w wielu przypadkach spełnia ono swoje zadanie. 

Dlaczego testowanie manualne nigdy nie zniknie

Omówiliśmy dobre, złe i bardzo złe aspekty AT. Wiemy, w jakich sytuacjach działa ono dobrze, a w jakich sprawia, że linie montażowe zaczynają rozrzucać opony samochodowe po całej fabryce. Przyjrzyjmy się przez chwilę testowaniu manualnemu i temu, dlaczego nadal jest ono tak ważne dla testerów QA. 

Testowanie automatyczne wymaga nadzoru

Jak wspomniano powyżej, w związku z problemem Muska dotyczącym Modelu 3 oraz ryzykiem uruchamiania testowania automatycznego przez noc, wiele rzeczy może pójść bardzo źle, gdy pozostawi się narzędzia do automatyzacji bez nadzoru. 

GIF dotyczący konieczności nadzorowania testowania automatycznego

Największe korzyści z testowania automatycznego pojawiają się wtedy, gdy jest ono przeprowadzane wraz z testowaniem manualnym lub pod nadzorem testera QA. Już z tego powodu testerzy QA mogą spokojnie założyć, że AT nie przejmie ich ról w dającej się przewidzieć przyszłości. 

More Articles

Testy manualne wykorzystują testy eksploracyjne

Podczas przeprowadzania testu eksploracyjnego tester bada oprogramowanie bez wcześniej ustalonego planu. Jest to jedna z najpopularniejszych form testowania w QA.

Testy eksploracyjne można przeprowadzać wyłącznie poprzez testy manualne. 

Zaletą testów eksploracyjnych jest to, że tester może na bieżąco dostosowywać się do swoich ustaleń, bez konieczności pisania kolejnego przypadku testowego. 

Testy eksploracyjne umożliwiają również współpracę, tworzenie teorii i wspólne działania na bieżąco. 

Wraz z upowszechnieniem się zwinnej teorii tworzenia oprogramowania coraz większą popularność zyskują również testy eksploracyjne. 

Testy automatyczne nie zapewniają elastyczności i kreatywności potrzebnych, aby testy eksploracyjne mogły być wystarczająco zwinne. Najlepiej sprawdzają się w sztywnym środowisku, w którym dokładnie wiadomo, czego należy szukać. Testy eksploracyjne są ich całkowitym przeciwieństwem — tester QA otrzymuje instrukcję, aby udać się tam, gdzie chce. 

Co o tym myślisz?

Niektórzy są zdecydowanymi zwolennikami testów automatycznych, podczas gdy inni nadal uważają, że najlepszym rozwiązaniem są testy manualne. Jak sądzisz, w jaki sposób zespoły QA mogą czerpać największe korzyści z testów automatycznych? Czy uważasz, że jesteśmy gotowi na sztuczną inteligencję w testowaniu?

Subskrybuj biuletyn The CTO Club , aby otrzymywać najnowsze artykuły i aktualizacje od ekspertów branżowych.

Jason Boog
Over his 15-year career, Jason Boog has worked as a QA tester, QA analyst, and Senior QA Analyst on video games, commercial sites, and interactive web applications. He spent more than a decade building out the QA team and process as Director of Quality & Client Support at a full-service digital agency.
Follow the author:

You may also like