Co to jest framework? To takie trudne angielskie słowo, które w polskim IT pojawiło się gdzieś na przełomie lat osiemdziesiątych i dziewięćdziesiątych ubiegłego stulecia i do dzisiaj nie znalazło dobrego polskiego tłumaczenia.
Framework to jest szkielet, na którym można zbudować własne rozwiązanie bardzo mocno dedykowane do swoich potrzeb, uwarunkowań projektowych i środowiskowych, spełniające potrzeby i oczekiwania różnych interesariuszy.
Z drugiej strony framework jest wypełniony treścią, a więc nie jest to szkielet, bo ma zawartość gotową do użycia w organizacji. Jednakże ta zawartość nie jest finalnym gotowcem, którego bezmyślnie można użyć w organizacji. Wymaga ona przeanalizowania, zrozumienia i wybrania z niej tego, co dla mojej organizacji, moich projektów i moich interesariuszy jest dobre. Wszystkie pozostałe elementy fremeworka nie są nam do niczego potrzebne.
Frameworki mogą dotyczyć różnych obszarów. Przykładowo: od dziesiątek lat istnieją frameworki metodyk wytwarzania oprogramowania. Od wielu lat istnieją różnego rodzaju frameworki programistyczne ułatwiające i przyśpieszające budowanie systemów. Od kilku lat istnieją frameworki, i jest ich coraz więcej, służące testerom do budowania zaawansowanych testów automatycznych. I pewnie, gdybyśmy się rozejrzeli dookoła, to znaleźlibyśmy jeszcze wiele takich miejsc, gdzie mamy frameworki.
Jedne z najmłodszych to te do automatyzacji i tym chciałbym się bliżej przyjrzeć. Powodem ich powstania było znaczące zwiększenie znaczenia testów automatycznych przy metodykach agile, gdzie konieczność ciągłej weryfikacji jakości całości budowanego rozwiązania bez wykorzystania szeroko zakrojonej automatyzacji jest bardzo trudna.
Czym jest framework do automatyzacji?
Jak dla mnie to framework do automatyzacji powinien mieć trzy składowe:
- Narzędzie do tworzenia skryptów – które pozwoli na szybki, łatwy i jednorodny proces tworzenia automatów testowych tak, aby tester nie musiał siedzieć godzinami i żmudnie pisać kodu aplikacji.
- 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 i 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.
- 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.
Co stanowi o jakości frameworka?
Abyśmy mogli uznać framework za narzędzie dobrej jakości musi on posiadać kilka atrybutów, które pozwolą określić czy faktycznie tak jest. Ja te atrybuty pogrupowałem 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 tutaj na myśli takie rzeczy, 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ą (np. 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 tutaj zwrócić uwagę na to, jakimi językami programowania posługujemy się przy tworzeniu skryptów (króluje tutaj 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 programistów jakich już mamy. Są jeszcze dwa powody dlaczego 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ą u siebie programiści do budowania i utrzymywania automatów testowych.
- Nagrywanie skryptów czyli ułatwienie, przy tworzeniu skryptów testowych tak, aby nie było potrzeby pisania wszystkiego 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, które 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, które są wykorzystywane w testach automatycznych, którymi trzeba zarządzać, a które bardzo często się zmieniają.
- Organizacja danych testowych. To kolejny bardzo ważny atrybut dobrego frameworka. Narzędzie musi posiadać 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 takie funkcjonalności frameworka, które pozwolą twórcom automatów testowych budować i panować nad kilkoma wersjami tych samych automató Czemu to jest ważne? Bo nigdy nie ma tak, że testujemy tylko jedną wersję systemu. Dla przykładu: 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 z tych wersji różni się od siebie albo nowymi funkcjonalnościami albo zmienionymi częściami istniejących już wcześniej funkcjonalności. Oznacza to, że tak samo jak programiści muszą szybko wrócić z wersji X+3 do wersji X, bo aktualnie muszą 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 przy okazji nie psuje nic innego.
W zakresie uruchamiania testów ważnymi atrybutami są:
- 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 pozwalać na to, aby dało się zestawić testy obrazujące 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 taki 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, jak przebieg poprzednich testów się zakończył.
- 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 mi pozwoli np. wykonanie testów tylko dla systemu sprzedaży, gdy systemu logistycznego i systemu samoobsługi jeszcze nie mam gotowego do testów albo gdy wiem, że tamte systemy działają bezproblemowo i nie ma sensu 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 z jednej operacji będzie dostępny dopiero po jakimś ustalonym czasie od zakończenia poprzedniej lub kilku poprzednich operacji. Przykładem mogą być operacje bilingowe w systemach bankowych czy telekomunikacyjnych i przetwarzania nocne. Inną możliwością jest uruchomienie całego zestawu o z góry ustalonym czasie np. w nocy 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ądarką. Jeszcze większego znaczenia nabiera ten parametr dla projektów wykorzystujących podejścia agile z ciągłym buildowaniem systemu (continous integration), gdzie 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 właśnie systemu.
W zakresie raportowania wyników testów ważnymi atrybutami są:
- Filtrowanie informacji w raporcie z testu tak, aby móc w szybki sposób zobaczyć interesujące nas informacje. Np. chcę szybko zobaczyć tylko te testy, które dotyczą modułu A i zakończyły się wynikiem negatywnym, a dodatkowo chcę mieć tylko informacje, w jakich krokach nastąpiło niepowodzenie.
- Możliwość załączania obrazków do raportu z testu. To bardzo przydaje się przy analizie dużych testów automatycznych, aby na pierwszy rzut oka zobaczyć, co było powodem niepowodzenia testu – czy to jest problem aplikacji, bo właśnie 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 takiego raportu, który potrafi pokazać tylko wybrany przebieg testu albo tylko wybrany etap danego przebiegu lub jeszcze inaczej – wszystkie przebiegi, ale tylko wybranego etapu (np. systemu logistycznego) z całości wykonanych testów.
- Tworzenie raportów z wielu testów w dedykowanym formacie firmy, czyli coś co pozwoli zbudować raporty tak, jak to było prezentowane do tej pory zanim się framework pojawił w organizacji. Wiele firm posiada już jakieś standardy raportowania i nie jest mile widziane, zwłaszcza na szczeblach kierowniczych, że od momentu pojawienia się nowego narzędzia kierownictwo musi się nauczyć czytać i rozumieć nowe raporty. „Przecież stare raporty były od kilku lat i były dobre, czytelne i zrozumiałe. Czemu muszę się teraz uczyć czegoś nowego?”
- Możliwość eksportu raportów do popularnych plików np. xls, pdf, html, doc – tak aby móc przekazać je dalej w formie elektronicznej dostawcy systemu lub odbiorcy w taki sposób, jak zostało to określone w kontrakcie. Innym powodem może być to, ż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.
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.
W wielu organizacjach pojawiają się i są wykorzystywane na dużą skalę rozwiązania open source. Tego typu narzędzia to obecnie największy obszar rozwoju darmowych narzędzi i największa ich liczba dostępnych w sieci. 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.
Liczba dostępnych w sieci rozwiązań open source jest tak duża, że zaczynają się pojawiać swego rodzaju hybrydy (takie jak ForEVO) – rozwiązania łączące kilka narzędzi open source w jedno środowisko open source. 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?
Jeżeli kogoś interesuje świat automatyzacji testów, jest nim zafascynowany lub z powodów projektowych musi się do niego zbliżyć warto śledzić artykuły, konferencje, seminaria i organizacje testerskie, gdyż na każdym z nich pojawia się przynajmniej kilka frameworków, z jakich można skorzystać w swojej organizacji.
Jedyne co mnie osobiście zadziwia to brak świadomości, że ktoś może już taki framework gdzieś stworzył. Przynajmniej od 5 lat obserwuję na wielu konferencjach prezentacje pokazujące coraz to nowe rozwiązania, które powstają w zaciszu biur firm, a które różnią się w zasadzie kosmetycznymi elementami w stosunku do tego, co jest już dostępne. Może warto czasem zajrzeć do internetu albo na konferencję lub przeczytać jakieś artykuły, aby nie wynajdować koła na nowo?