Od zera do pro – nauka automatyzacji testów UI w 8 godzin. Czy to możliwe?
Postanowiłem przeprowadzić eksperyment. Nauczyć QA automatyzować testy Ul do takiego stopnia, żeby dawały one wartość do projektu. I to w 8 godzin.
Nie interesowało mnie „dziubanie” testów na boku do szuflady. Chciałem, aby każdy QA napisał automat, który zostanie zmerge’owany do brancha master z testami. Jak myślicie, czy się udało? Zapraszam do kolejnych akapitów.
Wstęp do całej historii
Często, kiedy QA zaczyna pracę, zazwyczaj jako tester manualny, pojawia się u niego słowo automatyzacja testów. Testuje manualnie, testuje manualnie, testuje manualnie, jednak zadania (szczególnie przy testach regresji) zaczynają się powtarzać. Tester z powodu nudnego zadania chce zacząć automatyzować testy aplikacji.
Uczy się jak wyszukiwać elementy na stronie (xpath czy css), uczy się Selenium, czekania na elementy i różnych sztuczek, aby testy były stabilne. Uczy się dalej, czas mija, jednak nie przynosi to dalej wartości do projektu. Pojawia się problem, jak od podstawowych testów przejść do testów, które dadzą wartość, będą stabilne i szybkie w implementacji.
Pisząc pierwsze testy, tester musi jeszcze pomyśleć jak wpiąć je w proces, pipeline, kiedy znaleźć na to czas testując manualnie. Testy te w końcu jako pojedyncze dalej trafiają do szafy.
Wartość z nauki i automatyzacji całej wynosi – zero!
Postanowiłem zrobić mały eksperyment. Czy możliwe jest wyrwanie się z tego stanu i nauczenie w 8 godzin testowania na poziomie UI dając wartość do projektu? Wartością było dla mnie napisanie testu, który zostanie zmergeowany do mastera i będzie wykonywany razem z napisanymi już testami.
Bohaterowie
Żebyście mieli odniesienie w tej historii, muszę przedstawić jeszcze poziom uczestniczących w moim eksperymentalnym warsztacie.
Junior QA — staż w testowaniu około miesiąca w projektach, junior, junior, wiedza o javie (widział pierwszy raz kod pisany w javie) : )
Mid QA — testy manualne, przerobione podstawy javy + selenium podstawy – pisanie podstawowych testów, które nie były używane w projekcie.
Mid QA — testy manualne, mocniejszy poziom javy + pojedyncze testy automatyczne też nie używane w projekcie.
Mid QA — testy manualne, wiedza o javie mocniejsza + QA, który po uszy siedzi w postmanie i backendzie.
Start godzina 9:00
Nasze szkolenie zaczęliśmy od wytłumaczenia, co jest naszym celem oraz przeszliśmy do omawiania testów.
W pierwszej kolejności wytłumaczyłem środowisko, na jakim będziemy działać. Jaką rolę w naszym kodzie pełni cucumber i gherkin, czym są stepy, runnery i klasy page oraz konteneryzacja testów.
Pierwsze dwie godziny tłumaczenia big picture były kluczowe, ponieważ to one pozwalały uświadomić testerom przepływ pomiędzy kolejnymi warstwami. Samo omawianie przykładów odbywało się na gotowej paczce testów, którą na swojej maszynie uruchomił każdy QA.
To pozwoliło również sprawdzić już na początku szkolenia czy nikt nie posiada żadnych konfiguracyjnych problemów. Złożyliśmy tak naprawę wiele elementów w jeden działający mechanizm. Po takim wstępie nie zostało nic innego jak przejść do implementacji testów.
Godzina 11:00 feature file – Given, When, And, Then i puste kroki
Postawie dość odważną tezę, ale twierdzę, że to właśnie jest najważniejszy krok automatyzacji testów z wykorzystaniem BDD. Dlaczego?
Pierwszym powodem jest to, że trzeba mieć doświadczenie jako tester, aby projektować testy, które przynoszą wartość. Możemy mieć wolumen nawet 30 000 testów, jeśli jednak nie są one wartościowe, z poziomu feedbacku odnośnie do naszej aplikacji stają się bezużyteczne. Warto poświęcić tutaj więcej czasu na staranne zaprojektowanie testów. Rozmawiałem również z uczestnikami, jakie testy w ich rozumieniu dadzą wartość oraz co jest dla nich wartością podczas przeprowadzania testów.
Drugą ekstremalnie ważną sprawę jest budowanie elementów historyjki tak, aby elementy te były re używalne. Trzeba tutaj zachować balans pomiędzy bardzo precyzyjnymi krokami a dużymi ogólnikami.
Projektując kroki i pamiętając o balansie, pozwolimy używać ich wielokrotnie, unikając tym sposobem duplikacji kodu.
Projektowanie re używalnych kroków ma jeszcze jedną korzyść. Mając duży wolumen kroków, testy automatyczne może projektować i budować nawet tester manualny znający jedynie BDD i Gherkina. W tym wypadku budowie testów automatycznych nie będzie niczym innym jak składaniem istniejących już kroków w nowe testy. Możliwe że będzie potrzeba dopisać tylko pojedyncze kroki ale jest jest to szybsze niż implementacja od zera i zawsze mogą pomóc koledzy i koleżanki z zespołu.
Nie możemy zapominać również o produktywności tworzenia kodu, w ten aspekt zaliczam pokazanie jak skrótami klawiszowymi generować szybko metody odpowiadające krokom w naszej zaprojektowanej historyjce i umieszczać je w odpowiednich klasach.
Etap ten został zwieńczony utworzeniem metod umieszczonych w odpowiednich klasach, które nic jeszcze nie wykonywały.
Godzina 12:30 Widoki — element konieczny
Aby zautomatyzować testy UI musimy działać na elementach. Większość zespołu miała pojęcie czym są, jak ich szukać (przerabiała czasem nawet po 10 lekcji o wyszukiwaniu elementów).
Przeszliśmy zatem do praktyki, czyli wyszukiwania elementów potrzebnych do automatyzacji naszych user stories. Na samym wstępie szkolenia powiedziałem, że chcę, aby było ono ekstremalnie praktyczne.
Zaczęliśmy więc na dużym telewizorze wspólnie wyszukiwać elementy i dyskutować jak je najlepiej wyciągnąć. Pokazałem mój prosty, klarowny, szybki sposób oparty o praktykę (świat nie jest idealny nie każdy element ma id) jak wyciągać elementy.
Metoda pokazana, czas na praktykę!
Przerobiliśmy wspólnie około 4-5 przykładów. Co znaczy wspólnie? Po pokazaniu testerom jaki mam sposób na elementy zacząłem dawać im zadanie wyciągnięcia elementów z realnego projektu.
Zaczęliśmy od najprostszego diva, a następnie zwiększaliśmy trudność. Dwa takie same elementy, element z cyklu nie do wyciągnięcia, wyciąganie po tekście.
Każdy przykład omawialiśmy z QA zaraz po tym, jak cały zespół pokazał, że faktycznie wyciągnął dany element.
Okazało się, że ekstremalne 5 przykładów z wcześniejszym omówieniem wystarczy do pokrycia 95% przypadków. Co z pozostałymi 5%? Bądźmy realistami, wykorzystamy wtedy Google’a i znajdziemy rozwiązanie.
Godzina 14:00 Co elementy mają robić?
Po zadeklarowaniu elementów przyszedł czas na dalsze dopisanie klas page. W związku z tym, że większość testerów miała pojęcie o Javie stworzenie metod z akcjami typu wpisywanie wartości w inputy, klikanie w elementy, tworzenie getterów potrzebnych do asercji – przebiegło sprawnie.
To, co nie było takie oczywiste to kolekcje elementów. Jednak w związku z tym, że używaliśmy wsparcia Selenide testerzy natychmiast zrozumieli jak je implementować i używać.
Kolekcje były o tyle kluczowe, że pozwalają sprawnie i efektywnie sprawdzać ilość elementów w kolekcji, robić na nich asercje i sprawnie operować na większym wolumenie.
Godzina 15:20 Uzupełnienie pustych kroków
Stworzone klasy page pozwoliły nam już zdefiniować konkretne kroki. Pokazałem testerom jak podpiąć swoje testy tak, aby uruchamiały się skonteneryzowane oraz wytłumaczyłem co się dzieje przed samym wykonaniem testu w @Before oraz @After. (Konteneryzacja w Selenoidzie)
Warto tutaj zaznaczyć, że Selenide bardzo nas wyręcza. Testy UI są najdroższymi testami, dlatego liczy sprawne pisanie na tej warstwie. Automatyczne robienie screenshootów po failującym teście czy zaimplementowane waity pozwalają zaoszczędzić ogromną ilość czasu w porównaniu do czystego Selenium.
Więcej o Selenide w kolejnych wpisach, bo to temat na całkowicie nową serię artykułów ;).
W samych krokach ponownie przydała się wiedza z javy. Wykorzystaliśmy tutaj tworzenie obiektów, metodę chainowania. Tak, aby kod był prosty i czytelny.
Godzina 16:00 Uruchamianie naszych testów i dobre praktyki
Nadeszła chwila finalnego uruchomienia naszych testów. Wszystko odbyło się bez większych komplikacji i testy zadziałały, tak jak powinny — nastała euforia.
Zadałem jeszcze jednak pytanie, czy zespół jest pewien, że to wszystko?
Co ze stabilnością testu? Uruchomiliśmy testy tylko raz, skąd mamy mieć pewność że są stabilne?
Co z asercjami, skąd mamy wiedzieć, że działają poprawnie? Popsuliśmy nasze assersje sprawdzając, czy dają realny feedback co do sprawdzanych warunków.
Całość pracy została na naszym szkoleniowym branchu.
Koniec szkolenia 17:01
Tak nastąpił koniec szkolenia. Zapytałem o wrażenia. Okazało się, że samo pisanie testów nie jest straszne.
Problemem jest często brak big picture QA. Co robi maven, co uruchamiają pliki xml. Jak zarządza testami testNG.
Mimo, że nie zdążyliśmy poruszyć na bardzo głębokim poziomie każdego z aspektów, cały zespół stworzył test i poznał big picture. To, co zauważyłem – pojawiła się w ich zachowaniu pewność.
Pierwotnie złożone zagadnienie zostało rozłożone na prostsze elementy, które łatwiej było zrozumieć.
Ciąg dalszy 10 dni po szkoleniu
Jesteście ciekawi co działo się 10 dni po szkoleniu? Duma z QA biorących udział w szkoleniu.
Junior QA nadrabia wiedzę o javie w szybkim tempie tak, aby móc zacząć pisać wartościowe testy w codziennej pracy. Przygotowujemy już pierwsze proste zadanie tak, aby oswoić się z całym flow, obsługa gita, merge request, code review.
Mid QA który pisał testy nie implementowane w projekt, wysłał mi pierwszy merge request. Potrzebne były kosmetyczne poprawki i pierwszy merge do mastera jest blisko. (Edit, już jest zmergeowany) W kolejce czeka kolejny fragment systemu do automatyzacji.
Mid QA od pojedynczych testów automatycznych, zabrał branch ze szkolenia i przygotował wszystkie możliwe case’y. Jego praca jest już na masterze.
Mid QA wrócił do testów backendu jednak wiedza, którą posiadł pozwoli mu na utrzymanie testów w razie urlopu któregoś z QA.
Spostrzeżenia
Pierwsze moje spostrzeżenie jako prowadzącego szkolenie to to, że ciężko utrzymać ekstremalne skupienie przez około 8 godzin.
Po jakimś czasie czuć, że to już za dużo. Prowadząc je ponownie, podzieliłbym je na 2 dni szkolenia. Później samodzielna praca QA, ponowne spotkanie po (5-10 dniach) omawiające ich problemy. Oraz czwarte spotkanie po (20-30 dniach) gdzie progres byłby już widoczny i moglibyśmy podsumować cały projekt transformacji w zespół testerów automatyzujących. Piszących sprawnie i efektywnie testy.
Dodatkowe spostrzeżenie to fakt, że aby taki projekt się udał, trzeba będzie wprowadzić w organizacji zmiany. Kto zajmuje się środowiskiem, w którym są uruchamiane testy, lokalnie czy na serwerze, w czym piszemy testy? Te wszystkie decyzje muszą zostać podjęte. Trzeba również przygotować pod to infrastrukturę. Inaczej znów skończy się na „dziubaniu”.
