Jak rozpocząć przygodę z Automatyzacją Testów w swoim projekcie?

27 Marzec 2018
1 Komentarze

Znaczenia jakości nie trzeba podkreślać — jako testerzy i czytelnicy tego bloga znamy jej wartość.

Poniższy artykuł powstał jako miniporadnik dla wszystkich tych, którzy planują zacząć przygodę z Testowaniem Automatycznym. Najlepiej zupełnie zdezorientowanych, zaraz po kursie Inżynier Automatyzacji Testów ISTQB, od których ktoś oczekuje, że w najbliższym czasie stworzony zostanie system automatyzacji testów od zera.

Po głowie chodzi mi taki obraz — wyobraźmy sobie statek — taki jak ten, którym Ferdynand Magellan płynął razem ze swoją załogą (nosił nazwę Viktoria). Statek płynie przez raz to spokojniejsze, raz to zupełnie gniewne wody, a na jego pokładzie uwijają się marynarze, kapitan, oraz sternicy. Statkiem targa wiatr, smaga go rzęsisty deszcz, uderzają o niego wzburzone fale, ale on cały czas płynie. Nawet jeśli czasem zwalnia albo staje w miejscu przez różne okoliczności, to ostatecznie płynie wciąż naprzód.

Wyruszymy zaraz w wyprawie z naszym szalonym podróżnikiem, który chce opłynąć świat. Jesteśmy częścią załogi i liczy się dla nas przygoda i wielka woda. Dotychczas nie braliśmy udziału w tak wielkiej wyprawie, ale — co tam! Czujemy ekscytację na samą myśl o przygodzie.

A teraz wyobraź sobie…

Jesteś członkiem załogi, która wyrusza w podróż na statku. Jako marynarz odpowiadasz za to, żeby cały statek płynął do przodu, nie miał usterek, a wszystkie występujące problemy były rozwiązywane od razu. Innymi słowy, jesteś odpowiedzialny za proces kontroli jakości twojego statku. Kapitan pokłada w tobie wielkie nadzieje na ciągłe przyspieszanie procesu sprawdzania jakości. Ty sam czujesz ogromną presję, ponieważ w całą wyprawę zainwestowano bardzo poważne kwoty. Z jednej strony czujesz się przytłoczony, a z drugiej podekscytowany.

Nie mając żadnego doświadczenia odnośnie roli, w której obecnie się znajdujesz — zaczynasz od szorowania pokładu. W miarę upływu czasu, twoich obowiązków przybywa, a ty jesteś już znudzony powtarzaniem tych samych czynności. Co gorsza, twój kapitan i sternicy zaczynają naciskać na przyspieszenie procesu, który nijak nie może być w obecnym stanie usprawniony.

W dzisiejszym świecie sytuacja wygląda tak, że jesteś jedynym testerem, przepraszam — inżynierem ds. jakości w organizacji. Wykonujesz niemal wyłącznie testy manualne. O tym, co robią programiści, nie masz za dużego pojęcia. Wiadomo, że piszą kod. Wiadomo, że piszą jakieś testy jednostkowe. Widzisz, że są uruchamiane po każdym commicie.

W pewnym momencie życia firmy zapada decyzja: musimy zapewnić jakość tego konkretnego projektu X!

Ktoś decyduje, że potrzebne będą testy automatyczne, żeby móc skalować jakość. Idziesz na szkolenia — jedno, drugie, trzecie. Wracasz do pracy z certyfikatami. Teoretycznie jesteś przeszkolony i wiesz, od czego powinieneś zacząć.

W praktyce jednak bywa ciężko. Zwłaszcza gdy odwołamy się do podstawowych rzeczy, które są mówione zaraz na początku szkolenia Inżynier Automatyzacji Testów.

Po pierwsze:

Szkolenie nie uczy programowania, tylko daje ogólną wiedzę o temacie Automatyzacja Testów.
Nie nauczysz się jak pisać testy, a będzie to bardzo potrzebna umiejętność, jak się później okaże.

Po drugie:

Automatyzacja na samym początku konsumuje znaczną część zasobów.
To znaczy, że na początku tempo twojej pracy bardzo zwolni, zanim utworzone testy automatyczne zaczną zwracać poniesione koszty.

Po trzecie:

Na samym początku trzeba wybrać zakres testów, jakie będą automatyzowane.
Automatyzacja wszystkich testów jest niemożliwa i nieopłacalna.

Po powrocie do pracy zaczynasz research w celu rozplanowania jak dany system automatyzacji zbudować (w tym wypadku mówimy o TAS Test Automation Solution, który składa się ze środowiska oraz ze zbiorów testów zawierających również dane testowania).

Twój statek zaczyna tonąć, a ty nie wiesz jak zapobiec katastrofie.
Ferdynad (kapitan twojego statku) obdarzył cię kredytem zaufania, ale nie jesteś w stanie go spłacić.

Co robić? Jak się w tym odnaleźć? Jak ruszyć do przodu?

A wokół wzburzone morze

Autor tego artykułu, wyszczególnia 4 etapy stawania się profesjonalnym programistą:

  1. Miesiąc miodowy
  2. Zamieszanie
  3. Desperacja
  4. Doskonalenie

Ten model można z powodzeniem przyłożyć do przedstawionej powyżej sytuacji.

Miesiąc miodowy przeżywamy zaraz po powrocie ze szkolenia, zwłaszcza jak zdamy egzamin.

Ten okres charakteryzuje się głową pełną pomysłów oraz wzmożoną energią do pracy nad nowym zagadnieniem. W omawianym okresie jesteśmy z siebie dumni, czujemy, że zgłębiliśmy wiedzę na dany temat i jesteśmy cały czas motywowani postępami, jakie robimy.

Naszą pracę nad systemem zaczynamy od zrobienia researchu: co chcemy zautomatyzować — konkretnie jakie czynności, na jakim poziomie „wejścia” do systemu, jakiego typu to będą testy, i tak dalej. Praca posuwa się szybko do przodu, codziennie osiągamy cel, jaki sobie założyliśmy i plan powstaje w niedługim czasie.

Zamieszanie zaczyna się już w trakcie realizacji planu.

Okazuje się, że sam wybór drogi — piszemy od zera, czy wybieramy narzędzie komercyjne — przysparza wiele frustracji. Nasz stworzony wcześniej plan nie realizuje się szybko. Napotykamy pierwsze trudności, na które nie jesteśmy w stanie znaleźć konkretnej odpowiedzi w wyszukiwarce Google. Ponieważ jesteśmy sami w organizacji — nikt nie jest w stanie nam pomóc. Zaczyna się robić niespokojnie: zrywa się wiatr i trochę buja naszym statkiem.

Jesteśmy sfrustrowani z powodu ilości różnych rozwiązań, a także różnych dróg, jakie można wybrać.

Na ocean zwany desperacją trafiamy już po miesiącu (lub dłuższym czasie) naszej pracy nad systemem. Wiemy już, że:

  • nie kupimy komercyjnego rozwiązania,
  • nie zaczniemy pisania systemu od zera, bo „nie wiadomo czy to się opłaca”,
  • potrzebujemy w niedługim czasie testów automatycznych do jednej krytycznej funkcjonalności,
  • nie zatrudniamy nikogo do pomocy, a nasza współpraca z ekspertami spełza na niczym i ostatecznie zostajemy sami.

Nasze dotychczasowe wysiłki nad stworzeniem systemu spełzły na niczym. Jesteśmy w martwym punkcie i nie wiemy jak się z niego wydostać i iść dalej. W internecie nie ma rozwiązań spełniających nasze potrzeby. Po raz setny wpisujemy w Google frazę „generic automation system — first steps” i wszystkie wyniki u nas są zaznaczone jako odwiedzone.

Co robić dalej?

Jak znaleźć kierunek w stronę najbliższego lądu?

Jak ruszyć z tego miejsca?

Morze się uspokaja

Tak jak w większości podobnych projektów, czyli w sytuacji, gdy nasz statek wypływa na nieznane wody, bardzo zbawienne okazuje się podejście zwinne. Mamy wiedzę teoretyczną, ale na razie trudno nam ją przełożyć na konkretny projekt, w którym pracujemy.

Robienie dokładnego planu powstania systemu, którego nie ma, jest o tyle błędne, że niemal na pewno nie uda nam się go zrealizować.

Jeśli jesteśmy w okresie zamieszania i desperacji ogromnie ważną rzeczą jest codziennie robić krok do przodu — choćby malutki: trafienie na jakiś artykuł, bloga, który rzuca nam nowy pomysł. Trafienie na podobną odpowiedź, spróbowanie czegoś innego i wpadnięcie na inny zupełnie pomysł.

Nawet rozmowa z kimś, kto nie zna tematu, może być zbawienna.

Jak to zrobić?

Po pierwsze musimy dokładnie zdefiniować, jaka jest krytyczna potrzeba.

Najczęściej będzie to sam fakt posiadania i uruchamiania testów automatycznych. Trzeba też zdefiniować dla jakiej funkcjonalności.Następnie samo napisanie scenariuszy da nam już obraz, ile takich testów będzie musiało powstać.

Ostatecznie musimy wybrać element albo kawałek systemu, który możemy stworzyć stosunkowo najłatwiej i najszybciej.

W tym celu warto sobie przypomnieć, jak wygląda struktura gTAA (generic Test Automation Architecture):

 

Na rysunku przedstawiono strukturę gTAA przedstawiana na szkoleniu Test Automation EngineerISTQB Advanced Level.

Cała struktura nie powstanie od razu! Na samym początku skupiamy się wyłącznie na Test Execution, skoro wiemy, że potrzebujemy testów automatycznych dla naszej funkcjonalności.

Reszta systemu na razie nie będzie nas interesować.

Skąd takie podejście?

Po pierwsze: z samego szkolenia.

Musimy zbudować proof of concept naszego systemu.

Co zacznie najszybciej spłacać zainwestowany czas?

Automatyczne testy, które się uruchamiają (nawet lokalnie na komputerze inżyniera jakości).

Po drugie: zwinne podejście.

MVP (Minimum Viable Product, to wystarczająco określony produkt z minimalnym zestawem funkcjonalności, aby służyć jako usługa, a tym samym potwierdzić swoją wartość u potencjalnego klienta). Tworzymy nasz minimalny „produkt”, którym udowodnimy, że dalsza inwestycja w tworzenie systemu automatyzacji testów ma sens.

Trzeba będzie porzucić dotychczas wybrane narzędzie?

Ok. Wybór jakiegokolwiek narzędzia nie jest wiążący na zawsze. Tak jak kierunek, który obieramy z naszym statkiem: kierunek jest jeden, ale w trakcie naszej podróży podejmujemy tysiące decyzji, w którą stronę płynąć. Nasz proces, który usprawnia podejmowanie takich decyzji, jest naszą busolą.

To ona dostarcza nam danych do podjęcia decyzji.

Przygoda z Katalon Studio

Różne podejścia do automatyzacji przypadków testowych

Aby mówić o module systemu, służącym do egzekucji testów, nie sposób nie wspomnieć o różnych podejściach do automatyzacji testów. Wyróżniamy:

  • Capture/Playback (Capture/Replay) Approach
  • Linear Scripting Approach
  • Structured Scripting Approach
  • Data Driven Approach
  • Keyword Driven Approach
  • Process- driven Scripting Approach
  • Model Based Testing Approach

W narzędziu, które chciałabym poniżej omówić, dostrzeżemy trzy podejścia: Structured Scripting, Data Driven i Keyword Driven.

Charakterystyczne cechy tej sumy podejść, na jakie chciałabym zwrócić uwagę to:

  • Wydzielona sekwencja kroków w obrębie jednego przypadku testowego
  • Oskryptowane kroki przypadków testowych
  • Wydzielona struktura przypadków testowych: pojedyncze (Test Cases), grupy (Test Suites)
  • Wbudowana opcja do zarządzania biblioteką (w tym sensie: zbiorem skryptów)
  • Plik sterujący wykonywaniem testów (zawiera dane na wejście do skryptów)
  • Przypadki Testowe z wydzielonymi zmiennymi sterującymi
  • Testy mogą być automatyzowane przy użyciu odpowiednio przygotowanych i oskryptowanych słów kluczowych (słowa kluczowe — to warstwa abstrakcyjna opakowująca interfejsy systemu testowanego)
  • Przypadki testowe mogą być powiązane z odpowiednimi słowami kluczowymi

Wszystkie powyższe cechy znajdują swoje odzwierciedlenie w narzędziu Katalon Studio, który jest pewną formą kompleksowego IDE (Integrated Development Environment) dla systemu Automatyzacji Testów.

Katalon Studio — opis systemu

Katalon Studio jest to darmowe narzędzie służące do automatyzacji testowania.

Jest na tyle kompleksowy i prosty w instalacji, że wystarczy jedna aplikacja, w której dostępna jest cała konfiguracja potrzebna do uruchamiania testów Webowych: Selenium, webdriver’y, wtyczki do Continous Integration (Ciągła Integracja — to proces ciągłego sprawdzania i testowania kodu w sposób automatyczny), integracja ALM, oraz również narzędzie do raportowania.

Katalon Studio to po prostu System Automatyzacji Testów gotowy do użycia. W praktyce wymaga to zabawy narzędziem przez pewien czas, aby w pełni zrozumieć, jak można go zaimplementować w swoim projekcie.
Interfejs narzędzia wygląda jak popularne niegdyś IDE Eclipse dla języka Java. Komponenty projektu są odpowiednio pogrupowane w rozwijanym (drop down) menu.

Jak wygląda system automatyzacji testów w Katalon?

Na poniższym rysunku zaznaczyłam jakie komponenty ze wzorcowego modelu zawiera na pewno Katalon Studio:

Na rysunku przedstawiono strukturę gTAA zestawioną z komponentami widocznymi w narzędziu Katalon Studio.

Całkiem sporo gotowych komponentów, które możemy dopasować do swojego projektu, ponieważ są zaprojektowane tak, aby dać, jak najwięcej możliwości konfiguracji. Cały system jest na tyle dobrze zbudowany i niezawodny, że można go śmiało zaadoptować jako proof of concept.

Narzędzie świetnie się sprawdza również, aby poznać, co warto automatyzować (jakie testy), a czego nie. Ja osobiście polecam je, żeby nauczyć się w praktyce, jak powinien wyglądać system automatyzacji testów, oraz co automatyzować.

Katalon Studio — przykładowy projekt krok po kroku

Przejdziemy teraz do opisu przykładowego projektu.

1. Projekt

Jest naszą mini instancją systemu automatyzacji dla konkretnego projektu.
Na zrzucie ekranu widać przykładową strukturę projektu w widoku głównym Katalon Studio.

Każdy projekt zawiera wszystkie powyżej omówione komponenty.

Na powyższym rysunku widać wszystkie dostępne moduły.

W ramach konkretnego projektu możemy zarządzać konfiguracją:

  • gdzie wysyłać raporty o błędach,
  • która przeglądarka będzie domyślnie uruchamiana,
  • informacje odnośnie proxy itd.

2. Warstwa generacji Testów

Kompleksowy tutorial, jak wygenerować i uruchomić przykładowy Test Case dostępny jest tutaj. Jest tak dobry i prosty (a przede wszystkim: działa), że może być zastosowany jako pierwszy tutorial przy zetknięciu z narzędziem.

Katalon Studio umożliwia nagranie akcji użytkownika, a następnie ponowne ich odtworzenie z Testu, który został wygenerowany podczas nagrania. Nagrywając akcje, zapisujemy również ścieżki do obiektów (Test Objects) i zapisujemy w Object Repository. To nic innego jak ścieżki xpath do wszelkich elementów UI, z których korzystają testy (np. przyciski, które klikają, albo pola formularzy, które są wypełniane).

3. Skrypt testu

Z wygenerowanego przypadku testowego tworzy się automatycznie skrypt (skrypt jest utworzony w języku Groovy), który można dostosować na niższym poziomie niż samą sekwencję nagranych kroków — jednak potrzeba do tego pewnych podstawowych umiejętności pisania skryptów i testów.

Groovy upraszcza trochę sprawę — jako język wywodzący się z Javy jest w pełni funkcjonalnym i dynamicznym narzędziem do tworzenia skryptów przypadków testowych. Ponieważ jego składnia jest znacznie łatwiejsza do zrozumienia niż Javy, przysparza mniej trudności w nauczeniu się jej początkowym programistom.

Każdy przypadek testowy ma trzy tryby: lista kroków, skrypt i zmienne sterujące, które definiowane są osobno.

Więcej o generowaniu skryptów testowych tutaj.

4. Dane testowe

Do testu możemy z łatwością podpiąć dane i sterować wykonywanie testów właśnie plikiem typu excel albo csv, a także bazą danych.

Z mojego doświadczenia wynika, że z podpięciem bazy jest problem, dlatego polecam plik csv z wygenerowanymi danymi testowymi, którymi będziemy testować naszą funkcjonalność. Bardzo dobre zarządzanie danymi testowania, które można podpiąć do zmiennych sterujących w pojedynczym przypadku testowym, jak i całej grupie testów, sprawia, że Katalon z powodzeniem wpisuje się w podejście Data Driven (patrz sekcja Różne podejścia).

Tutorial jak podpiąć dane do przykładowej grupy testów można zobaczyć tutaj.

5. Egzekucja testów

Jest to najprzyjemniejszy moduł z całej Architektury Testowania.

Wystarczy kliknąć Run i wybrać przeglądarkę, a narzędzie uruchamia nasz skrypt, albo całą grupę skryptów z danymi, które zdefiniowaliśmy w testach.

Uruchamiać możemy jeden Test Case, jak i całe Test Suites — do 4 uruchomień Testów równolegle. Podczas egzekucji testów uruchamiany jest również aplet (jako „produkt” powstały po zbudowaniu naszego projektu). Egzekucja umożliwia wykonanie skryptów testowych na 4 przeglądarkach, w trybie Headless (Chrome) – czyli bez graficznego interfejsu użytkownika, Remote — gdzie możemy się podłączyć z zewnętrznym serwerem i wykonać testy np. na Browser Stacku, bez zmiany choćby jednej linii kodu, oraz na urządzeniach mobilnych.

Ważne! Warunkiem jego wykonania w tym przypadku jest instalacja dodatkowych elementów i dodatkowa konfiguracja.

6. Raportowanie i zbieranie wyników testów

Raportowanie w Katalon Studio jest dostępne tylko dla Test Suite’ów. Dla pojedynczych testów nie ma tej funkcjonalności.

W Test Suite można ustawić, aby wykonywał się tylko jeden test i wtedy raport będzie tworzony wyłącznie dla niego.

Raporty są dostępne w sekcji „Live View”, w module Reports, oraz mogą być wysyłane na maila po wcześniejszej konfiguracji w ustawieniach projektu.

Wygląd szablonu takiego raportu można znaleźć tutaj:


Na zrzucie pokazano widok konfiguracji i struktury raportu, który może być wysłany jako wiadomość email do wszystkich interesariuszy.

W raportach są wyszczególnione informacje: Nazwa Test Suite’a, ilość testów, która przeszła, oraz ilość testów zakończona błędem.

Więcej o raportach tutaj oraz możliwość konfiguracji wysyłania raportów na maila tutaj.

7. Słowa kluczowe

Katalon Studio umożliwia również utworzenie słów kluczowych i powiązania ich z odpowiednimi przypadkami testowymi (Test Case’ami). Dodana w ten sposób warstwa abstrakcji, pozwala na zarządzanie wykonywaniem testów i ponowne użycie stworzonych wcześniej modułów. Koszt naszej wcześniejszej pracy jest więc spłacany.

To podejście jest nazwane Keyword Driven (patrz sekcja Różne podejścia do automatyzacji testowania).

Więcej o słowach kluczowych i ich konfiguracji można znaleźć tutaj.

Katalon Studio — dalsze możliwości

Ciekawostką związaną z Katalon Studio są jego dużo większe możliwości. Nad narzędziem zaczęto pracować pod koniec 2016 roku, a już teraz stanowi naprawdę niezłą konkurencję dla Open Source’owych projektów.

Narzędzie jest rozwijane, często uaktualniane i ulepszane. Dzięki temu ma szansę stać się naprawdę konkretnym graczem na rynku wśród nawet rozwiązań komercyjnych. Zaskakuje prostotą użycia, dobrze przygotowaną dokumentacją i przykładami użycia oraz konstrukcją architektury jak ze szkolenia Test Automation Engineer ISTQB Advanced Level. Pozwala zacząć przygodę, jak również stworzyć już bardziej skomplikowany system automatyzacji, sterowany przez pliki, bądź słowa kluczowe.

Całkiem obiecująco wygląda również Katalon Analytics — gdzie możemy znaleźć podsumowanie wykonania wszystkich uruchomień testów w danym projekcie.

Katalon oprócz samego systemu do automatyzacji testów ma coś znacznie więcej do zaoferowania:

  • narzędzia do identyfikowania obiektów webowych,
  • narzędzia do uruchamiania tych samych testów na symulatorach i urządzeniach mobilnych,
  • integrację z Jirą (narzędziem do zarządzania projektami i zadaniami) oraz Githubem,
  • narzędzie do debugowania testów oraz dedykowane sposoby projektowania testów w zależności od różnych elementów UI w systemie (jak iFrame, drop down menu, wait time, modyfikacja drzewa DOM oraz praca z zupełnie zewnętrzną biblioteką w projekcie).

Minusy narzędzia:

Katalon Studio może stać się konkurencją dla wielu rozwiązań z licencją Open Source, ale tylko wtedy, jeśli popracuje nad konfiguracją z serwerami CI.

Na razie wyeksportowanie testów i uruchamianie ich z serwera CI jest ultratrudne. Konfiguracja nie jest taka zła — Katalon powzala na zbudowanie i uruchomienie projektu z konsoli, ale nie pozwala sterować wykonywaniem testów i danymi właśnie z trybu terminala. To uniemożliwia uruchomienie testów inaczej, niż tylko z wewnątrz IDE, a tym samym czyni testera jedynym odpowiedzialnym za konfigurację, zarządzania i uruchamianie testów, co często dzieje się również na jego komputerze (a więc lokalnie).

Podsumowanie

Mam nadzieję, że artykuł wleje trochę nadziei wszystkim tym, którzy wciąż stoją w martwym punkcie na szalejącym morzu. Jestem pewna, że każdy może zacząć przygodę z Automatyzacją — nawet jeśli wcześniej nie miał wiele wspólnego z pisaniem kodu.

Katalon Studio jako narzędzie darmowe oraz stwarzające sporo możliwości zasługuje na bycie proof of concept całego procesu automatyzacji testów. Nawet pomimo dość dużego minusa, jaki na razie posiada, ale który go nie przekreśla.

Z własnego doświadczenia mogę powiedzieć, że nakład pracy, jaki został poniesiony dla Katalon Studio, spłaca się do dzisiaj. Jesteśmy w stanie wykonywać więcej testów danej funkcjonalności dziennie: po pierwsze testy wykonują się szybciej, a po drugie automatyzujemy pracę, która jest po prostu nudna dla testera.

Zaangażowanie w proof of concept to też dobra zabawa i nadzieja dla zmęczonych swoją manualną pracą testerów.

Artykuł można spokojnie potraktować jak przewodnik i dzięki niemu być może szybciej zacumować do najbliższego lądu na oceanie desperacji i szybciej pokazać Ferdynandowi Magellanowi, że warto było zainwestować w automatyzację i że to się po prostu opłaca.

Tego życzę wszystkim inżynierom jakości, którzy chcą zacząć automatyzować testowanie.

Maria Machlowska
Testerka Oprogramowania z 5 letnim stażem i Scrum Masterka. Lubi się określać słowem "psuj". Miłośniczka ćwiczeń śpiewu na tysiące sposobów, tak jak muzyki chóralnej i śpiewu operowego.

1
Dodaj komentarz

avatar
1 Comment threads
0 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
LukeRecent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Luke
Gość
Luke