Framework to jednak więcej niż szkielet. Jest od razu wypełniony pewną treścią. Można ją wykorzystać, ale nie da się jej potraktować jak gotowca. Wymaga ona przeanalizowania, zrozumienia i wybrania tego, co przyda się w projektach. Reszta nie będzie potrzebna.

Frameworki mogą być przeznaczone do różnych zadań. Przykładowo, od lat istnieją frameworki metodyk wytwarzania oprogramowania oraz frameworki programistyczne, ułatwiające budowanie aplikacji.

Stosunkowo niedawno pojawiły się frameworki do automatyzacji i im chciałbym się bliżej przyjrzeć. Powodem ich powstania było znaczące zwiększenie znaczenia testów automatycznych przy metodykach Agile, w których konieczność ciągłej weryfikacji jakości całości budowanego rozwiązania bez wykorzystania szeroko zakrojonej automatyzacji jest trudna.

Czym jest framework do automatyzacji?

Moim zdaniem framework do automatyzacji powinien mieć trzy składowe:

1. Narzędzie do tworzenia skryptów

które pozwoli na szybki, łatwy i jednorodny proces zbudowania automatów testowych tak, aby tester nie musiał siedzieć godzinami i żmudnie pisać kodu automatów testowych.

2. Narzędzie do uruchamiania testów

które będzie zbierać wszystkie stworzone skrypty automatyczne i będzie je uruchamiać w ustalonej kolejności, na ustalonej wersji aplikacji, z ustalonymi parametrami oraz danymi do wykonania testów i o ustalonej porze. Ma to pozwolić na wykonywanie testów bez konieczności siedzenia przed komputerem i patrzenia, co się dzieje, a w szczególności popychania automatów, które gdzieś się zatrzymały.

3. Narzędzie do analizy raportów z testów

które ma zebrać dane z wykonanych testów i zaprezentować je w formie różnorodnych raportów. Przede wszystkim to narzędzie musi mieć raporty dla twórcy skryptów, aby mógł wywnioskować, co jest powodem niedziałania skryptu – błąd skryptu czy błąd aplikacji. Z drugiej strony narzędzie musi pokazywać, co się wydarzyło w całościowym wykonaniu testu, np. w nocy, jakimi wynikami się zakończyły poszczególne testy i jak się to przekłada na całe scenariusze testowe. Idąc jeszcze dalej, dobre narzędzie raportujące powinno pokazać, jak się przedstawia wynik całości testów w podziale np. na obszary biznesowe czy podsystemy albo moduły testowanego systemu. Taki całościowy wynik powinien dawać jasną informację kierownikowi projektu, sponsorowi, członkom komitetu sterującego, jak wygląda jakość właśnie budowanego rozwiązania.

Od czego zależy jakość frameworka?

Abyśmy mogli uznać framework za narzędzie dobrej jakości, musi mieć kilka atrybutów, które pozwolą określić, czy faktycznie tak jest. Pogrupowałem te atrybuty w kilka obszarów, aby można było łatwiej się do nich odnosić w kontekście cech frameworka. W zakresie tworzenia skryptów testujących takimi atrybutami są przede wszystkim:

- Wsparcie technologii testowanych aplikacji, czyli jak dużo różnorodnych technologii budowania systemów mogę takim narzędziem obsłużyć. Mam na myśli takie kwestie, jak: technologie web, gruby klient, np. w C czy JAVA, aplikacje mobilne na tablety i smartfony, czy duże systemy CRM lub ERP, które same w sobie są technologią (SAP czy systemy ORACLE).

- Możliwości funkcjonalne edytora skryptów, czyli jak narzędzie ułatwia pracę testerów tworzących skrypty testujące. Warto zwrócić uwagę, jakimi językami programowania posługujemy się przy tworzeniu skryptów (króluje JAVA, ale można też spotkać VBScript, C, Python, C++ albo MS Visual Basic), aby nie budować w organizacji kolejnej grupy programistów konkurencyjnej do zatrudnionych. Są jeszcze dwa powody, dla których warto korzystać z tego samego języka programowania co programiści: nie zamyka to ścieżki kariery od programistów do ekspertów do automatyzacji i w drugą stronę oraz pozwala wykorzystywać wiele praktyk i doświadczeń (o środowiskach pracy już nie wspominając), jakie mają programiści do budowania i utrzymywania automatów testowych.

- Nagrywanie skryptów, czyli ułatwienie przy tworzeniu skryptów testowych, aby nie było potrzeby pisania wszystkiego, począwszy od czystej kartki papieru. Oczywiście, nagrane skrypty nie są i nigdy nie będą idealnymi automatami testowymi i zazwyczaj wymagają poważnej przebudowy, ale zawsze to już jest materiał do dalszych prac.

- Debugowanie skryptów. Automat testowy to program, który ma sprawdzać inny program. Tym samym środowisko do tworzenia tych programów musi mieć przynajmniej takie możliwości jak programiści, którzy tworzą system. Inaczej znalezienie błędów w skryptach testujących jest bardzo trudne.

- Organizacja obiektów testowych. To jeden z najważniejszych atrybutów stanowiących o jakości dobrego frameworka. Aplikacje, jakie testujemy automatycznie, mają dziesiątki ekranów czy stron internetowych, na których jest po kilkadziesiąt różnego rodzaju kontrolek. Sumarycznie daje to tysiące obiektów graficznych na interfejsie użytkownika. Są one wykorzystywane w testach automatycznych, którymi trzeba zarządzać i które bardzo często się zmieniają.

- Organizacja danych testowych. To kolejny ważny atrybut dobrego frameworka. Narzędzie musi mieć możliwości zarządzania dużymi zestawami danych, zwłaszcza dla bardzo dużych testów automatycznych weryfikujących całościowe procesy biznesowe. Ten atrybut nabiera szczególnego znaczenia, gdy chcemy robić częste testy całości testowanego rozwiązania przechodzącego przez kilka systemów i jeszcze dodatkowo, gdy testy mają być wykonywane równolegle w celu przyśpieszenia ich zakończenia.

- Mechanizmy wspierające utrzymywanie skryptów, czyli funkcjonalności frameworka, które pozwolą twórcom automatów testowych budować i panować nad kilkoma wersjami tych samych automatów. Dlaczego to ważne? Bo nigdy nie ma tak, że testujemy tylko jedną wersję systemu. Na przykład: na produkcji mamy wersję X, na testach UAT wersję X+1, a na testach systemowych zazwyczaj X+2. Koledzy programiści budują właśnie wersję X+3. Każda wersja różni się od siebie nowymi funkcjonalnościami albo zmienionymi częściami istniejących już wcześniej funkcjonalności. Oznacza to, że tak jak programiści muszą szybko wrócić z wersji X+3 do wersji X, bo właśnie należy poprawić jakiś defekt wykryty na produkcji, tak samo szybko testerzy muszą wrócić z automatami z wersji X+1 do wersji X, aby zweryfikować, czy poprawka naprawdę usuwa usterkę i czy czegoś nie psuje.

Uruchamiając testy, należy zwrócić uwagę na:

- Możliwość budowania zestawów testów, czyli ułatwienie w tworzeniu testów automatycznych składających się z małych części wielokrotnie wykorzystywanych. Narzędzie powinno umożliwiać zestawianie testów obrazujących np. pełen proces biznesowy realizowany na aplikacji od zalogowania się jednego użytkownika, wykonania przez niego operacji w jednym module przelogowania się na innego i wykonania kolejnych operacji na systemie po końcowego użytkownika, który ma skorzystać z poprzednio wykonanych operacji. Przykładowo, sprzedaż usługi, która ma w swoim charakterze sprzęt (np. usługa telekomunikacyjna lub bankowa) wymaga najpierw wykonania operacji logistycznych typu „zatowarowanie” i „przypisanie do sprzedawcy”, a następnie wykonanie operacji sprzedaży i aktywacji usługi, której skutkiem jest to, że klient może się samodzielnie zalogować do systemu samoobsługi i sprawdzić stan swojej usługi. Automaty powinny testować cały proces, który może być zbudowany z kilkunastu skryptów automatycznych ustawionych w odpowiedniej sekwencji i z odpowiednimi parametrami wykonania w zależności od tego, jak zakończył się przebieg poprzednich testów.

- Możliwość filtrowania uruchamianych testów, czyli ułatwienie w szybkim wyszukiwaniu testów gotowych do uruchomienia dla jednego podsystemu czy modułu bez konieczności ręcznego przeklikiwania się przez listę tysięcy automatów.

- Funkcjonalność uruchamiania wybranych testów z zestawu, czyli coś, co pozwoli np. na wykonanie testów tylko dla systemu sprzedaży, gdy system logistyczny i system samoobsługi jeszcze nie są gotowe do testów albo gdy wiadomo, że tamte systemy działają bezproblemowo i nie trzeba ich kolejny raz badać, a tym samym psuć sobie dane testowe przygotowane w tych systemach.

- Planowanie uruchamiania testów w zadany sposób, czyli uruchamianie testów w zadanej kolejności czasowej, gdy wynik jednej operacji będzie dostępny dopiero po ustalonym czasie od zakończenia poprzedniej lub kilku poprzednich operacji. Przykładem są operacje bilingowe w systemach bankowych czy telekomunikacyjnych i przetwarzania nocne. Inną możliwością jest uruchomienie całego zestawu we wcześniej ustalonym czasie, na wszystkich komputerach pracowników, którzy właśnie poszli do domu.

- Uruchamianie testów równolegle na kilkunastu komputerach, aby znacząco skrócić czas oczekiwania na wyniki. Inna możliwość to uruchomienie testów dla określonej konfiguracji sprzętowo-programowej, gdzie na różnych środowiskach mamy dany serwer z silnikiem bazy danych z połączonym klientem z odpowiednią wersją systemu operacyjnego i przeglądarki. Jeszcze większego znaczenia nabiera ten parametr dla projektów wykorzystujących podejścia Agile z ciągłym buildowaniem systemu (continous integration), w którym dobry framework może być połączony z mechanizmami programistów i po zakończeniu buildowania aplikacji wykonać pełne testy systemu. Oznacza to, że w skrajnym przypadku możemy mieć kilka, a nawet kilkanaście środowisk, na których wykonują się te same testy na różnych wersjach budowanego systemu.

Podczas raportowania wyników testów istotne są:

- Filtrowanie informacji w raporcie z testu, aby móc szybko wyszukać niezbędne informacje. Na przykład chcę zobaczyć tylko testy, które dotyczą modułu A i zakończyły się wynikiem negatywnym, a także informacje, kiedy nastąpiło niepowodzenie.

- Możliwość załączania obrazków do raportu z testu. To przydaje się przy analizie dużych testów automatycznych, aby szybko sprawdzić, co było przyczyną niepowodzenia testu: czy to problem aplikacji, bo w tym miejscu pojawił się komunikat o błędzie, czy jest to problem skryptu, a ekran aplikacji wygląda tak, jak powinien.

- Możliwość tworzenia raportu dla testów wieloetapowych, czyli raportu, który potrafi pokazać tylko wybrany przebieg testu albo tylko wybrany etap danego przebiegu lub wszystkie przebiegi, ale tylko wybranego etapu z całości wykonanych testów.

- Tworzenie raportów z wielu testów w specjalnym formacie firmy. Wiele firm ma ustalone standardy raportowania i nie chcą innych, bo od momentu pojawienia się nowego narzędzia menedżment musi się nauczyć czytać i rozumieć nowe raporty.

- Możliwość eksportu raportów do popularnych plików, np. xls, pdf, html, doc, aby móc przekazać je dalej w formie elektronicznej dostawcy systemu lub odbiorcy w sposób, jak zostało to określone w kontrakcie. Innym powodem może być fakt, że nasz raport będzie tylko częścią składową całości raportu z weryfikacji jakości dostarczanego rozwiązania i kierownik projektu potrzebuje go zaciągnąć do własnych narzędzi raportujących, aby mieć całościowy obraz sytuacji.

Podział frameworków

Na rynku mamy do wyboru wiele różnych frameworków. Główny podział, jaki możemy zastosować, to rozwiązania płatne i open source. Główne plusy rozwiązań komercyjnych to przede wszystkim wsparcie techniczne przy problemach czy defektach frameworka. Ważna jest też ich uniwersalność. Płatne rozwiązania mają duże pokrycie wspieranych technologii, czyli jednym narzędziem możemy zautomatyzować wszystko, co wymaga testowania w organizacji. Kolejny dobry punkt to gotowa integracja z popularnymi narzędziami do zbiorczego raportowania wyników czy do środowisk pracy programistów. Komercyjne rozwiązania mają bardzo dobrze dopracowane mechanizmy tworzenia skryptów, dzięki czemu przygotowanie automatów testowych jest znacznie mniej pracochłonne. Twórcy tych narzędzi zaimplementowali (i niestety opatentowali) zaawansowane metody rozpoznawania i zarządzania obiektami interfejsu użytkownika, przez co ich automaty są bardziej odporne na zmiany w aplikacjach.

Minusem komercyjnych rozwiązań jest cena licencji, często zbyt wysoka w stosunku do możliwości narzędzia. Kolejny koszt stanowi coroczne wsparcie techniczne, które należy wykupić, aby korzystać z najnowszych wersji narzędzia. Kolejny minus to mała elastyczność narzędzia, jeżeli trafiamy w systemie na coś, co nie jest standardowo wykonane przez programistów. Zwykle trzeba czekać na nową wersję lub kupić dodatek wyprodukowany przez firmę trzecią, aby móc dalej korzystać z narzędzia.

Rozwiązania open source

W wielu organizacjach pojawiają się i są wykorzystywane na dużą skalę rozwiązania open source. Jedna z najlepszych stron dotyczących narzędzi open source do testowania opensourcetesting.org w momencie pisania tego artykułu w sekcji Functional Test Tools ma 135 narzędzi, z czego większość to frameworki.

Główne plusy rozwiązań open source to ich darmowość i elastyczność. Są to rozwiązania, które powstały na potrzeby danego projektu lub grupy projektów, zostały opracowane przez pasjonatów i w 100% rozwiązują ich problemy. Jeżeli czegoś nam w tych rozwiązaniach brakuje, to przecież mamy kod źródłowy i możemy sobie doprogramować, co tylko chcemy. Warto sprawdzić najpierw warunki licencyjne, aby wiedzieć, jak to dobrze zrobić, aby nie być posądzonym o kradzież. Kolejnym plusem jest ich integracja ze standardowymi środowiskami programistycznymi. Często narzędzia te nie wyszły poza środowisko programistyczne i są zestawem bibliotek, jakimi programiści automatów mogą się posługiwać, tworząc kolejne testy.

Rozwiązania te mają jednak dużo wad. Zazwyczaj są przeznaczone do jednej technologii. Poza tym narzędzia te są odseparowane, to znaczy, że jak chcemy je połączyć z czymś innym, musimy coś do tego narzędzia dopisać. Twórca tego nie potrzebował do rozwiązania swojego problemu, więc tego nie ma. Chcąc korzystać z tych rozwiązań, musimy zatrudnić testerów-programistów, którzy chętnie będą tworzyć automaty w środowisku programistycznym i często dopisywać potrzebne funkcjonalności, aby narzędzie działało na testowanym systemie lub w danym środowisku. Zwiększa to pracochłonność budowania automatów testowych zwłaszcza w początkowej fazie automatyzacji, gdy poznanie narzędzia open source i integracja są dużo trudniejsze niż w przypadku rozwiązań komercyjnych.

Liczba dostępnych w sieci rozwiązań open source jest tak duża, że zaczynają się pojawiać swego rodzaju hybrydy – rozwiązania łączące kilka narzędzi open source w jedno środowisko. Takie rozwiązania pojawiają się coraz częściej, gdyż świat wymaga coraz bardziej rozbudowanych automatów testowych, gdzie jedna technologia to już stanowczo za mało. Obecnie testowane systemy to składowe wielu podsystemów zbudowanych z aplikacji grubego klienta, aplikacji web czy końcówek mobilnych. Za chwilę pojawią się do tego narzędzia dla testowania internetu rzeczy. A może już są, tylko nie zostały jeszcze publicznie pokazane?