Pułapki automatyzacji testów

Automatyzacja w cienkich plasterkach

Nie da się zaprzeczyć, że automatyzacja testów zrewolucjonizowała testowanie oprogramowania. I to w samą porę! W dzisiejszym świecie ultras rozproszonych, skonteneryzowanych i stale aktualizowanych usług przeprowadzanie wartościowych testów oprogramowania byłoby bez niej niemożliwe.  

Mamy szczęście dysponować tak wieloma zaawansowanymi narzędziami do automatyzacji testów. Do tego dochodzą, co warto podkreślić, doskonale wyszkoleni inżynierowie QA, którzy wykorzystują je z korzyścią dla wszystkich zaangażowanych w proces tworzenia oprogramowania.

Jednak z jakiegoś powodu naturą naszej branży jest zwyczajowe sprowadzanie tak znaczących postępów w możliwościach do rangi mód, a następnie przekształcanie tych mód w pozbawione znaczenia zbitki słów i slogany, mechanicznie powtarzane przez menedżerów wyższego szczebla, komentatorów i konsultantów, którzy po prostu chcą znaleźć wymówkę, by przestać myśleć o problemie. Albo szybko zarobić.  

Tak właśnie stało się z przełomowymi osiągnięciami w dziedzinie automatyzacji testów, które szybko zostały włączone do uproszczonej narracji: „musimy po prostu zautomatyzować wszystkie nasze testy! Natychmiast! I wszystkie nasze problemy z testowaniem zostaną rozwiązane!”.

To nie tylko fatalny pomysł, nawet gdyby wysuwali go ludzie, którzy próbują potraktować problem poważnie, a nie tylko go unikać. Jest on również szkodliwy, ponieważ taka narracja, zamykając możliwość głębokiego zastanowienia się nad sposobem włączenia automatyzacji do działań testowych, gwarantuje jej porażkę.  Jest to niesprawiedliwe wobec wszystkich osób, w tym klientów, które polegają na jej powodzeniu.

Pod tym względem automatyzacja testów dziedziczy szczególny przypadek ogólnego podejścia do SQA stosowanego przez tych, którzy go nie rozumieją i nie chcą zrozumieć. Traktuje się ją jak produkt masowy, a nie złożoną dziedzinę wiedzy. Dlatego osoby zajmujące się QA wciąż słyszą od kierownictwa wyższego szczebla: „potrzebujemy po prostu więcej QA!”, jak gdyby gdzieś istniał delikatesowy sklep z oprogramowaniem, w którym można zamówić QA na funty, pokrojone w cienkie plasterki.

Dlatego obecnie mantrą jest: „potrzebujemy po prostu więcej automatyzacji!”, bez zastanowienia, co miałoby to naprawdę oznaczać w kontekście działań związanych z tworzeniem oprogramowania. W ten sposób taka narracja napędza dysfunkcje w organizacji. Nie rozwiązuje ich.  

Próba bezpośredniego przeciwstawienia się tym modnym tendencjom przypomina próbę powstrzymania wschodu słońca. Albo, w tym przypadku, jego zachodu. Najlepszą formą oporu jest po prostu przytaknąć i uśmiechnąć się do wiceprezesów i konsultantów, wrócić do swoich boksów i opracować właściwy sposób automatyzacji, a następnie przedstawić te pomysły jako genialne produkty wyobraźni swoich menedżerów. Prawdopodobnie nauczyliście się już tej lekcji przy innych okazjach.

Zróbmy więc właśnie to. Oto moja lista pułapek związanych z wdrażaniem automatyzacji testów oraz sposobów ich ograniczania, aby automatyzacja mogła spełnić pokładane w niej ogromne nadzieje w ramach własnych działań testowych.

Zakres automatyzacji

Najważniejszym pytaniem, na które należy odpowiedzieć na początku, jest to, gdzie zautomatyzowane testowanie zapewni najlepszy stosunek korzyści do kosztów w ramach prowadzonych działań testowych. Poświęcenie czasu na tę analizę oszczędzi wam w przyszłości wielu, wielu problemów.

Odpowiedź na to pytanie sprowadza się do kwestii, jaka część testów powinna zostać zautomatyzowana, a jaka powinna pozostać manualna. Dla tych z was, którzy są nieustannie bombardowani ewangelią „zautomatyzujmy wszystkie testy!”, może to zabrzmieć zaskakująco. Nie zwracajcie jednak uwagi na te bzdury — ci ludzie nie mają pojęcia, o czym mówią.

Zautomatyzowanie wszystkich testów — przy założeniu, że jest to w ogóle możliwe — byłoby fatalną decyzją, która mogłaby doprowadzić do katastrofy w prowadzonych działaniach testowych.  

Automatyzacja potrafi robić wspaniałe rzeczy, których testowanie manualne nie potrafi, a przynajmniej nie potrafi wykonywać ich równie szybko i powtarzalnie. Jednak odwrotna sytuacja również jest prawdziwa. Istnieją rzeczy, które tylko testowanie manualne potrafi wykonywać dobrze, a automatyzacja nie. Co to za rzeczy w obu przypadkach?

Tym, w czym testowanie manualne przewyższa testowanie automatyczne, jest po prostu czynnik ludzki. Korzyści wynikających z obecności prawdziwego człowieka, który cierpliwie prowadzi pogłębione testy eksploracyjne, nie da się odtworzyć za pomocą automatyzacji. I nie mówię tu tylko o wykrywaniu błędów.  

Każdy może znaleźć błędy. Klienci robią to cały czas i za darmo. Wartość, jaką wnosi profesjonalista QA, polega na intuicyjnym wyczuciu, jak zepsuć fragment oprogramowania, szczególnie w kontekście ustalenia, w jaki sposób klienci mogą korzystać z oprogramowania w sposób, do którego nigdy nie zostało ono zaprojektowane, a mimo to — często z katastrofalnymi skutkami — jest to możliwe. 

Kolejną zaletą testowania manualnego jest to, że po znalezieniu błędu tester manualny może od razu przystąpić do ustalenia jego zakresu i dotkliwości. Innymi słowy, może zawęzić konteksty testowe (systemy operacyjne, przepływy pracy, interakcje między usługami i zależności), w których błąd się ujawnia, oraz te, w których nie występuje. 

Automatyczne skrypty testowe w ogóle nie radzą sobie z tym zbyt dobrze, a z punktu widzenia inżyniera oprogramowania są to właśnie kluczowe informacje potrzebne do zdiagnozowania i naprawienia błędu. Zgłoszenie błędu, które po prostu stwierdza: „zrobiłem to i wydarzyła się ta zła rzecz”, jest dla niego bezużyteczne.

Testowanie manualne jest w rzeczywistości znacznie bardziej efektywne czasowo, jeśli chodzi o dostarczanie tych informacji, a dzięki temu, że z natury jest interaktywne i odbywa się w czasie rzeczywistym we współpracy z zespołem inżynieryjnym, zapewnia znacznie bogatsze informacje zwrotne i analizę przyczyn źródłowych.  

Tak, Virginiо, testowanie manualne nie zawsze jest najmniej efektywnym i najbardziej czasochłonnym sposobem znajdowania, diagnozowania i naprawiania błędów oraz sprawdzania, czy ich poprawki działają (lub nie). 

Jednak tam, gdzie automatyzacja ma oczywistą przewagę, jest nią ciągłe testowanie dostępności i stabilności — szczególnie w przypadku systemów rozproszonych. Jest to obecnie znacznie bardziej istotne ze względu na nasz obecny kontekst programistyczny, obejmujący ciągłą integrację i wdrażanie w czasie rzeczywistym do rozproszonych środowisk.

Automatyzacja jest również bardziej wydajna w tym, co można nazwać „testowaniem masowym”, gdy trzeba objąć testami ogromną macierz tysięcy warunków systemowych i ich zmiennych, aby sprawdzić, czy którykolwiek z nich jest całkowicie niesprawny lub spowoduje awarię systemu.

Praktyczna zasada, którą należy kierować się przy projektowaniu i ustalaniu priorytetów testów manualnych lub automatycznych, jest następująca: 

Testowanie manualne jest zazwyczaj preferowane podczas początkowego testowania nowych funkcji i możliwości. Testowanie automatyczne jest zdecydowanie najlepsze w przypadku ciągłych, ogólnych testów regresji oraz testów obciążenia i wydajności.

W całym cyklu życia produktu lub usługi testowanie tej samej możliwości powinno ewoluować od manualnego do automatycznego. Jest to kontinuum cyklu życia możliwości. Nie jest to chiński mur, którego nigdy nie należy przekraczać i po którego żadna ze stron nie musi wiedzieć, co dzieje się po drugiej stronie. Domyślne założenie powinno być takie, że to, co jest dziś testowane manualnie, z czasem powinno przejść na testowanie automatyczne.

Kwalifikacje inżyniera automatyzacji

Być może nieuniknione jest to, że podczas zatrudniania inżynierów ds. testowania automatycznego najważniejszymi oczekiwanymi kwalifikacjami będą poziomy biegłości kandydatów w zakresie (a) narzędzi automatyzacji, z których będą musieli korzystać, oraz (b) języków skryptowych używanych przez te narzędzia.  

Jeśli jednak są to jedyne kwalifikacje, na których się koncentrujesz, popełniasz poważny błąd. Są one niezbędne, ale zdecydowanie niewystarczające na stanowisku inżyniera automatyzacji.

Dlaczego? Z prostego powodu: znajomość obsługi narzędzia automatyzacji oraz tworzenia skryptów w jego języku skryptowym mówi dokładnie nic o rozumieniu samego zapewniania jakości przez tę osobę.

Niestety niemal nigdy nie spotykam inżynierów automatyzacji, którzy mieliby takie przeszkolenie lub doświadczenie. Są zatrudniani po prostu dlatego, że są mistrzami skryptów, a nie dlatego, że potrafią zaprojektować skuteczny, diagnostyczny test.

Te kwalifikacje są w rzeczywistości ważniejsze niż doświadczenie z narzędziami automatyzacji i językami, których będą używać. W razie potrzeby mogą się ich łatwo nauczyć. Jednak wyszkolenie kogoś w zakresie projektowania testów i interpretowania ich wyników wymaga bardzo dużo czasu i wysiłku.  

W rzeczywistości lepiej byłoby po prostu wybrać doświadczonego analityka, którego już masz w zespole, i przeszkolić go w zakresie niezbędnych narzędzi automatyzacji. Umiejętności związane z automatyzacją są przecież obecnie towarem powszechnie dostępnym. Intuicja i wnikliwość doświadczonego testera — nie.

Automatyzacja niewiedzy daje tylko niewiedzę szybciej i w sposób bardziej powtarzalny, a także podważa wydajność, której oczekiwano od testowania automatycznego. 

Standardy projektowania automatyzacji

To oczywiste, że jeśli rozpoczynasz szeroko zakrojone działania w zakresie automatyzacji testów, najpierw musisz określić ogólne standardy, z którymi każda automatyzacja musi być zgodna, aby zostać dopuszczona do użycia podczas testowania. Jednak, podobnie jak w przypadku wielu oczywistości, wygląda na to, że osób myślących jest mniej, niż można by się spodziewać.

Oto, co powinny obejmować te standardy.

Zrozumiałość

Jedną z frustrujących zagadek tworzenia oprogramowania jest to, jak bardzo okazuje się ono rzemieślnicze. Niestety wcale nierzadko zdarza się, że inżynier oprogramowania mówi, iż nie może naprawić błędu, ponieważ nie napisał kodu, w którym ten błąd występuje. To tak, jakby kod napisany przez innego inżyniera był w obcym języku, którego nie rozumie.

To samo, niestety, jest równie powszechne w inżynierii automatyzacji testów. Nie potrafię powiedzieć, ile razy inżynier QA mówił mi, że nie wie, jak zaktualizować fragment automatyzacji testów na potrzeby dużej aktualizacji produktu, ponieważ go nie napisał, a zatem go nie rozumie i nie potrafi zrozumieć. A do tego inżynier, który go stworzył, odszedł z firmy dwa miesiące temu.

W przypadku skryptów testów automatycznych jest to jeszcze mniej akceptowalne niż w przypadku nowego kodu oprogramowania, który implementuje logikę projektową, a nie tylko powoduje wykonanie określonych kroków. Mimo to jest to zadziwiająco powszechne.

Oznacza to, że zanim zatrudnisz tuzin inżynierów QA i każesz im z zapałem tworzyć setki skryptów testów automatycznych, upewnij się, że najpierw zdefiniowałeś ogólne standardy zrozumiałości i przeszkoliłeś z nich zespół.  

Wymogiem powinno być to, aby wszystkie skrypty testów były wzajemnie zrozumiałe dla każdego z Twoich inżynierów QA, tak abyś nie stał się zależny od pojedynczego, często tymczasowego zasobu w zakresie ich utrzymania.  

Zdefiniuj i egzekwuj proces przeglądu oraz akceptacji wszystkich kandydatów na skrypty automatyczne pod kątem tych standardów, zanim zostaną wdrożone do testowania. 

Łatwość utrzymania

Możliwość utrzymania jest ściśle związana z problemem zrozumiałości, jednak te dwie kwestie są logicznie i operacyjnie odrębne. Skrypt testowy może być łatwo zrozumiany przez inżynierów testów, którzy go nie napisali, a mimo to może być zbudowany w taki sposób, że jego aktualizowanie lub modyfikowanie będzie prawdziwą zmorą.

Oto przykład z życia. 

U jednego z moich pracodawców przygotowywaliśmy działania testowe związane ze średniej wielkości aktualizacją ich flagowego produktu. Zaplanowano czterotygodniowy cykl wydawniczy, co w tym przypadku było całkiem rozsądne.

Podczas planowania wymaganych działań testowych zdałem sobie sprawę, że będziemy musieli również zaktualizować główny zautomatyzowany skrypt do testów regresji. Kiedy zapytałem głównego inżyniera QA, ile czasu zajmie ta aktualizacja, odpowiedział: „osiem tygodni”. To dwa razy dłużej niż cały cykl wydawniczy! Nawet uwzględniając typowy dla inżynierów grzech zawyżania szacunków, było to skrajnie dużo.  

Poprosiłem kilku innych inżynierów testów o przejrzenie skryptu i oszacowania. Wszyscy zgodzili się, że skrypt został napisany w tak niezgrabny i nieefektywny sposób, iż jego aktualizacja na potrzeby kolejnego wydania wymagałaby wielu tygodni żmudnego przepisywania całego skryptu, mimo że same aktualizacje nie wiązały się z fundamentalnym przepisaniem produktu.

Ta sytuacja była klasycznym przykładem grzechu inżynierii oprogramowania przeniesionego do inżynierii testów. Czas położyć kres temu szaleństwu.

Moja rada w tej kwestii jest identyczna z tą, której udzieliłem wcześniej w sprawie zrozumiałości. W żadnych okolicznościach nie pozwalajcie inżynierom QA ukrywać się w jaskiniach inżynierii testów, a następnie pojawiać się tydzień lub dwa później z czymś, co być może działa jako test, ale czego aktualizacja w odpowiednim czasie będzie koszmarem pozbawionego sensu cierpienia.

Ustanówcie standardy dotyczące możliwości terminowego aktualizowania i stwórzcie proces przeglądu oraz akceptacji, aby zagwarantować ich przestrzeganie. Można to łatwo połączyć z tymi samymi działaniami mającymi zapewnić zrozumiałość, dzięki czemu wszystko może być częścią tego samego procesu przeglądu.

Inżynierowie QA nie są renesansowymi malarzami — nie prosicie ich o ponowne namalowanie Kaplicy Sykstyńskiej. Nie powinno to trwać całe życie.

Role w testowaniu i automatyzacja testów

Jednym ze wzorców nieefektywności, który utrudnia płynną i owocną integrację automatyzacji z całością działań testowych, jest błędne założenie, że każdy etap zautomatyzowanego procesu testowania musi odbywać się w obrębie samego zespołu automatyzacji.

To kolejny błąd. Choć w tym przypadku nie jest on całkowicie oczywisty.

Inżynierowie automatyzacji prawdopodobnie będą najlepiej opłacanymi zasobami w waszym zespole, więc ich czas jest cenny. Co więcej, liczba skryptów testowych, które ten zespół będzie musiał tworzyć i stale aktualizować, będzie z czasem rosnąć, a wasza grupa inżynierów testów nie będzie w stanie zwiększać się wystarczająco szybko, aby za tym nadążyć. Nawet jeśli pracujecie dla Google.

Operacyjnie ma więc sens wprowadzenie pewnego podziału pracy między zespołem automatyzacji a resztą zespołu. W szczególności chodzi o podział między osobami, które tworzą i utrzymują zautomatyzowane skrypty oraz narzędzia, a tymi, które faktycznie uruchamiają zautomatyzowane testy.

Oczywiście pierwsze z tych obowiązków może wykonywać wyłącznie sam zespół automatyzacji.  W końcu właśnie po to został zatrudniony. Nie dotyczy to jednak drugiej grupy obowiązków.  

Nie ma powodu, dla którego analitycy nie mieliby móc samodzielnie uruchamiać zautomatyzowanych testów i interpretować ich wyników.  

Niewiele osób myśli w ten sposób, ale taki podział pracy ma całkowity sens. Po pierwsze, uwalnia znaczną ilość czasu, pozwalając inżynierom automatyzacji skupić się na tworzeniu nowych rozwiązań automatyzujących.

Po drugie, wzmocni wymóg zrozumiałości określony powyżej. Jeśli automatyzacja ma kluczowe znaczenie dla waszych działań testowych, równie ważne jest, aby każdy członek zespołu testowego — niezależnie od tego, czy jest inżynierem automatyzacji — potrafił zrozumieć i korzystać z waszych zautomatyzowanych testów. Dotyczy to również testerów manualnych.

Taki system definiowania ról znacznie zwiększy elastyczność wykorzystania zasobów w całym zespole QA, a tym samym stworzy oszczędności czasowe i harmonogramowe, które w przeciwnym razie nie byłyby możliwe. 

Końcowe przemyślenia

Rozwinięcie solidnych możliwości zautomatyzowanego testowania, zgodnie z powyższą definicją, jest dziś po prostu koniecznością. Nie można mówić o profesjonalnym i skutecznym QA bez tego elementu.  

Jednak wiele wspaniałych przedsięwzięć rozpoczyna się z entuzjazmem i radością, by pod koniec podróży zakończyć się porażką. W QA wielokrotnie widzę to w odniesieniu do automatyzacji testów.

Problem polega na tym, że stosunkowo łatwo jest zagłębić się w zautomatyzowane testowanie. Jest kosztowne, ale łatwo przynajmniej udawać, że podejmuje się wysiłek. Zautomatyzowane testowanie może jednak również przypominać urwisko, z którego — niczym Wile E. Coyote w kreskówkach o Strusiu Pędziwiatrze — bezmyślnie spadacie, gdy tylko zadacie sobie trud spojrzenia w dół.

Trzeba od samego początku rozumieć, że automatyzacja testów ma cykl życia. Każdy skrypt testowy ma cykl życia trwający miesiące, a nawet lata.

Nie chodzi tylko o napisanie zestawu zautomatyzowanych skryptów testowych, które spełniają wszystkie wasze potrzeby dotyczące produktu w jego obecnym stanie rozwoju. Chodzi o to, jak będziecie w stanie płynnie rozwijać całą tę automatyzację wraz z ewolucją produktu w trakcie jego własnego cyklu życia.

Jeśli zignorujesz kwestie zakresu automatyzacji, kwalifikacji inżynierów QA, zrozumiałości, łatwości utrzymania i definiowania ról, przekonasz się, że z czasem cały ten wysiłek związany z automatyzacją stał się białym słoniem i studnią bez dna, której nie sposób zrozumieć ani utrzymać.

A wszystkie wydane na to pieniądze pójdą na marne. Twoi przełożeni nie omieszkają tego zauważyć.

Z drugiej strony, jeśli zastosujesz się do udzielonych przeze mnie powyżej wskazówek, dostosowując je oczywiście do specyfiki własnych wyzwań i sytuacji, w dużej mierze unikniesz tego kryzysu przestarzałości i przez wiele lat będziesz czerpać korzyści z produktywnej automatyzacji testów.

Jak zawsze — powodzenia.

Powiązane materiały:

• 10 NAJLEPSZYCH NARZĘDZI DO MONITOROWANIA SERWERÓW WWW
• NAJLEPSZE PRAKTYKI AUTOMATYZACJI W TRANSFORMACJI CYFROWEJ

Warto sprawdzić: CZYM JEST MABL? PRZEGLĄD I PREZENTACJA FUNKCJI