Automatyzacja testów musi być przemyślana

Automatyzacja testów wynika z konieczności stosowania metodyk Agile w wytwarzaniu oprogramowania. Wiele firm nie wie, jak wdrażać automatyzację oraz kiedy i kto powinien to zrobić.

Gdzie szukać pieniędzy na automatyzację testów

Z narzędziami do automatyzacji testów jest podobnie jak z programami antywirusowymi. Zakup oprogramowania nie przynosi bezpośrednich korzyści, ale zabezpiecza przed poważnymi stratami. Bez automatyzacji testów przepuszczamy błędy w oprogramowaniu do klienta lub na produkcję. Szukając zwrotów z inwestycji (ROI) dla automatyzacji, trzeba wziąć pod uwagę koszty awarii i problemów. A są to:

- Koszty naprawy błędów przez zespół programistów, czyli ile nas kosztuje poprawienie błędu wykrytego w testach lub w środowisku produkcyjnym. Są to koszty: stworzenia poprawki, wgrania poprawki na środowisko testowe, wykonanie testów potwierdzających oraz wgranie poprawki na produkcję.

- Koszty przestojów, czyli ile tracimy, gdy system na produkcji przestaje działać. Koszty te można podzielić na kilka grup: koszty związane z wynagrodzeniem pracowników w okresie niedziałania systemu, koszty nadgodzin, kiedy pracownicy uzupełniają system o zapisy z czasu przestoju systemu, koszty kar w przypadku niedotrzymania warunków umów serwisowych (SLA) z klientami lub instytucjami nadzorującymi oraz koszty reklamacji składanych przez klientów.

- Koszty utraty klientów, rezygnacje i przejścia do konkurencji wynikające z błędów w systemach informatycznych udostępnianych klientom. A także upusty, prezenty i dodatki dla klientów, których chcemy utrzymać.

- Koszty ludzi, którzy wykonują obecnie ręcznie testy dedykowane do automatyzacji. Nie oznacza to, że te wszystkie osoby należy zwolnić. Mogą one robić wyrafinowane testy manualne, których do tej pory nie robiły ze względu na prace przy testach regresywnych.

Pierwszym i najważniejszym zadaniem jest odpowiedzenie sobie na pytanie: po co chcę automatyzować testy? Powodów może być wiele, na przykład chęć automatycznego wykonywania tzw. testów dymnych (Smoke Test). Automat sprawdzi, czy dostarczony system jest stabilny, kompletny, czy wszystkie funkcjonalności uruchamiają się, a raporty drukują.

Można automatyzować wprowadzanie do systemu danych koniecznych do przeprowadzania szkoleń albo testów akceptacyjnych. Często wymagane jest zastosowanie kilkuset zestawów danych, których przygotowywanie ręczne trwałoby kilka, a czasem nawet kilkanaście dni.

Celem automatyzacji jest regresywne sprawdzanie funkcjonalności aplikacji po wprowadzanych zmianach. Automatyzacja testów funkcjonalnych jest najbardziej kosztowna i pracochłonna.

Można automatyzować sprawdzanie stabilności systemu, np. przez monitorowanie działania aplikacji narzędziami do automatyzacji testów funkcjonalnych. To najbardziej wyrafinowane i skomplikowane wykorzystanie automatyzacji, wymagające dogłębnego przemyślenia działania automatu. Musi on przecież działać w trybie 24x7 i radzić sobie ze wszystkimi sytuacjami wyjątkowymi.

Co warto automatyzować

Idealnym kandydatem do automatyzacji testowania jest system, który się nie zmienia i jest stabilny z punktu widzenia interfejsu użytkownika. Ale ideałów nie ma. Trzeba szukać w aplikacjach miejsc, dla których interfejs użytkownika zmienia się rzadko, a testy regresji muszą być wykonane bardzo szybko.

Powinno się automatyzować sprawdzanie kluczowych funkcjonalności systemu. Automatyzować warto testy, przy których potrzebne są bardzo szybko wyniki, kiedy ludzie wykonujący testy ręcznie często się mylą we wprowadzaniu danych lub wykonywaniu operacji na systemie albo gdzie trzeba wykonać dokładnie takie same testy w różnych środowiskach. Automat zawsze będzie robił test z taką samą precyzją.

Automatyzować warto testy, które sprawdzają prosty system z punktu widzenia użytkownika, ale mający skomplikowane reguły biznesowe. Przykładem są systemy kwotacyjne czy systemy billingowe, które zazwyczaj działają na kilku ekranach lub interfejsach, ale wymagają wykonania kilkudziesięciu tysięcy testów, aby potwierdzić ich poprawne działanie. Wynik działania systemu obliczającego składkę polisy może ulec zmianie w zależności od jednego parametru.

Jakie są korzyści z automatyzacji

Wdrażając automatyzację w zespole testowym, nie doprowadzimy do zmniejszenia zatrudnienia testerów. Automatyzacja znacząco zwiększy bowiem liczbę wykonywanych sprawdzeń systemu. Za pomocą testów wykonywanych automatycznie uzyskujemy za każdym razem taką samą jakość testowania. Inaczej mówiąc, jeżeli w teście będzie 50 sprawdzeń różnych parametrów systemu, to człowiek, który będzie miał wykonać ten test po raz 20 w ciągu miesiąca, wykona go niedokładnie. Automat za każdym razem będzie robił wszystkie 50 sprawdzeń, a tym samym wykonywał test za każdym razem tak samo precyzyjnie.

Mając automatycznie wykonywane testy, możemy w tym samym czasie wykonać ich znacznie więcej przy takiej samej liczbie testerów, a ich wyniki będą znacznie szybciej dostarczone. Nieraz szybkość dostarczania wyników jest tak duża, że program testujący może samodzielnie dokonywać automatycznego zgłaszania błędów, gdy wykryje niezgodność między wartością oczekiwaną i wartością zwracaną z systemu. Tego rodzaju automatyzacja wymaga precyzyjnych sprawdzeń i dużej wiarygodności automatów testowych.

Wiele narzędzi pozwala uzyskiwać zwiększenie zakresu testów do stopnia, którego nigdy nie uda się osiągnąć ręcznie, nawet przy bezbłędnie działającym systemie i zwiększonym zespole testerów. Automaty mogą wykonywać dokładnie te same testy na różnych wersjach systemów operacyjnych i rodzajach przeglądarek, czego ludzie nie byli w stanie zrobić zawsze z taką samą dokładnością i w podobnym czasie.

Co robią ludzie od testów

Największym błędem, jaki można popełnić przy automatyzacji testów, jest zaangażowanie wszystkich osób z zespołu testerów do automatyzacji. Podejście skutkuje tym, że nie ma automatyzacji ani testów manualnych. Myśląc o zespole testowym i automatyzacji, należy wyznaczyć osoby zajmujące się tylko automatyzacją, które przejmą od pozostałych osób nudne, często powtarzalne testy i je zautomatyzują. Skłoni to testerów do bardziej kreatywnego podejścia, pozwoli przygotować lepsze, bardziej wyrafinowane testy bazujące na ich doświadczeniu. Osoby takie będą mogły przygotować i wykonać więcej testów w obszarach, gdzie jest wiele zmian, gdzie do tej pory nie miały czasu na przygotowanie testów negatywnych i wszędzie tam, gdzie pojawia się wiele modyfikacji oraz poprawek wynikających z wykrytych błędów. Wszędzie tam nie sprawdzają się automaty

Koszty wdrożenia automatyzacji

Automatyzacja kosztuje. Wymaga poświęcenia czasu na wybór narzędzia do automatyzacji, zakup licencji i wdrożenie wybranego rozwiązania. Czasem nie ma gotowego rozwiązania i trzeba uruchomić osobny projekt na napisanie narzędzia, które pozwoli zautomatyzować testy w organizacji.

Po wybraniu narzędzia warto przeprowadzić projekt pilotażowy sprawdzający, czy wprowadzenie w organizacji takiej zmiany jak automatyzacja sprawdzi się w realizowanych projektach, na ile trzeba będzie przebudować modele pracy naszych zespołów i czy rzeczywiście korzyści, jakie otrzymujemy, przewyższają koszty, jakie ponosimy.

Kolejne koszty to czas na przygotowanie i poprawianie już utworzonych skryptów wynikające ze zmieniającego się systemu. Przy dużych automatach testowych, sprawdzających kilkaset funkcjonalności systemu, dochodzą koszty dodatkowego środowiska, na którym automaty mają działać, gdy osoby tworzące skrypty mają jednocześnie tworzyć nowe testy.

Jeżeli automatyzujemy testy, wykorzystując komercyjne rozwiązania i chcemy mieć prawa do ich najnowszych wersji, pojawia się koszt utrzymania. Dla firm wykorzystujących w swoich systemach najnowsze technologie z zakresu inżynierii oprogramowania jest to niezbędne.

Jeżeli automatyzujemy, wykorzystując rozwiązania open source, może pojawić się koszt dostosowania gotowych, działających skryptów do nowej wersji narzędzia.

Piotr Ślęzak jest partnerem w CORRSE - Software Engineering. Correctly.

Rodzaje automatów testowych

Ze względu na przeznaczenie:

- Testy dymne (Smoke test) - automat badający gotowość aplikacji do testów. Zazwyczaj jest to przejście przez podstawowe moduły aplikacji i weryfikacja najważniejszych funkcjonalności bez formalnego testowania merytoryki.

- Generatory danych - automaty generujące dane przy wykorzystaniu interfejsu użytkownika aplikacji. Stosowane w sytuacji, gdy wygenerowanie danych poza aplikacją jest trudne lub niemożliwe ze względu na integralność danych w kilku systemach.

- Testy regresywne - automaty wykorzystywane przy testach funkcjonalnych, sprawdzające, czy niezmienione fragmenty aplikacji działają tak samo jak przed wprowadzeniem poprawki lub zmiany do systemu.

- Testy procesów biznesowych - automaty weryfikujące możliwość wykonania pełnych procesów biznesowych end-to-end, często realizowanych przez kilka systemów.

- Testy pomiarowe - automaty, które dokonują pomiarów czasów wykonania poszczególnych akcji lub procesów, ale bez obciążania systemu wieloma sesjami jednocześnie. Stosowane bardzo często przy wykrywaniu problemów infrastruktury sieciowej w rozproszonych geograficznie lokalizacjach firmy.

- Monitory systemów - automaty weryfikujące działanie systemu. Zazwyczaj wykorzystuje się prosty scenariusz wykonywany w trybie 24x7 symulujący rzeczywiste działanie użytkownika. Wykorzystywane tam, gdzie najważniejsza jest perspektywa klienta końcowego.

Ze względu na budowę:

- Liniowe - najprostsza forma testu automatycznego. Taka postać testu powstaje zazwyczaj bezpośrednio po nagraniu skryptu. Test nie wykorzystuje pętli, funkcji, nie wywołuje innych testów. Prosty w przygotowaniu, ale trudny w utrzymaniu.

- Strukturalne - automaty logicznie podzielone na bloki i funkcje. Mogą wykorzystywać pętle, biblioteki funkcji i inne mechanizmy pozwalające uporządkować kod skryptu. Łatwiejsze w utrzymaniu i modyfikacji.

- Sterowane danymi (Data driven) - automaty zasilane danymi zewnętrznymi. Iteracja testu lub jego bloku uzależniona jest ściśle od danych zewnętrznych, jakimi automat jest zasilany. Bardzo często wykorzystywane w systemach kwotacyjnych i billingowych.

- Bazujące na słowach kluczowych (Keyword driven) - automaty, które w celu wykonania kroku scenariusza testowego wykorzystują słowa kluczowe. Słowo kluczowe może być opisem obiektu interfejsu użytkownika lub też opisem pewnego rodzaju akcji do wykonania na obiekcie. Najbardziej pracochłonna wersja automatów testowych w fazie przygotowania, ale najłatwiejsza w utrzymaniu. Przy zastosowaniu tego rodzaju automatyzacji kolejne testy automatyczne mogą tworzyć osoby nieznające się na automatyzacji, ale znające słowa kluczowe (metajęzyk automatów testowych).

- Hybrydowe - automaty strukturalne wykorzystujące słowa kluczowe. Mogą również mieć bloki sterowane danymi.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200