Planowanie automatyzacji - część 1

Powrót do przeszłości

Artykuł ten jest drugą częścią serii o automatyzacji projektu https://github.com/mwinteringham/restful-booker-platform.
W poprzednim artykule poznaliśmy generyczną fazę, którą roboczo nazwaliśmy zwiadem, czyli poznaniem projektu. Faza ta w cyklu życia automatyzacji jest jedną z najważniejszych i definiujących całe podejście. Czas przejść do kolejnej fazy, jaką jest planowanie i przygotowanie automatyzacji.

Planowanie automatyzacji

Planowanie automatyzacji składa się z szeregu elementów, do których możemy zaliczyć:

• Wybranie języka programowania do testów automatycznych,
• Zidentyfikowanie narzędzi i frameworków, tak aby występowała między nimi synergia,
• Proof of concept wybranych narzędzi,
• Utworzenie lub skorzystanie z istniejącego frameworka do testów automatycznych,
• Zdefiniowanie zakresu testów, co testujemy, a czego nie,
• Elementy związane z wymaganiami biznesowymi, które wpływają na planowanie. Na przykład klient zażyczył sobie bardzo detalicznych raportów wykonania testów lub pokrycia 100% kodów statusowych dla każdego endpointu,
• Planowanie ze względu na wymagania domenowe. Na przykład dla branży medycznej wszystkie przypadki testowe muszą być powiązane z wymaganiami z ang. requirements traceability. Takie podejście zwiększa koszt tworzenia i utrzymania testów,
• Zdefiniowanie typu testów oraz pokrycia.

Oprócz rzeczy specyficznych dla automatyzacji, w grę wchodzą takie elementy jak przy zwykłym planowaniu projektu:

• Infrastruktura,
• Zasoby ludzkie,
• Odpowiedzialności w zespole/projekcie,
• Harmonogram prac,
• Ryzyka,
• Dane testowe,
• Wyniki i raportowanie,
• itd.

Elementów wchodzących w skład planowania automatyzacji jest bardzo dużo. W serii artykułów skupimy się na rzeczach technicznych. W takim razie, od czego zacząć?

Odwieczne pytanie -- język oprogramowania

Uwaga: W akapicie zostały użyte uproszczenia:

• deweloper/zespół deweloperski -- osoba/osoby odpowiedzialne za tworzenie aplikacji,
• tester/zespół testerski -- osoba/osoby odpowiedzialne za testowanie oraz tworzenie kodu testów

Ze względu na różnego rodzaju organizację, powyższe uproszczenie może wyglądać inaczej.

Jednym z pytań, które musimy zadać na początku jest:

W jakim języku programowania tworzyć automatyzację testów?

Pytanie to jest często zadawane przez początkujących automatyków.

Odpowiedź na to pytanie zależy, od szeregu czynników:

• Jaki język/języki znamy?
• Na jakim poziomie operujemy danym językiem?
• W jakim języku jest tworzona aplikacja/projekt?
• Czy zespół deweloperski będzie utrzymywał i rozwijał testy automatyczne?
• Jaka jest dostępność bibliotek i narzędzi wspierających testy?
• Innych elementów takich jak kultura organizacji, zespołu, wymagań klienta, czy domeny, w jakim jest prowadzony projekt.

Z przedstawionej listy najważniejszym kryterium rozpoczęcia automatyzacji jest poziom znajomości języka głównego twórcy/twórców oraz wsparcie i jego zakres przez zespół deweloperski.

Dla przykładu, jeśli nie znamy języka, w którym chcemy/będziemy pisać testy automatyczne, lub nie czujemy się w tym języku dobrze. Tworzenie automatyzacji nie ma sensu . Utworzone w ten sposób testy będą ciężkie w utrzymaniu. Dlatego naukę automatyzacji testów powinniśmy zacząć od języka programowania, a nie od biblioteki, czy też narzędzia. Znajomość Selenium i innych bibliotek do automatyzacji jest konieczna, ale nie jest najważniejsza.

Kolejnym punktem na tablicy jest ustalenie zakresu oraz formy wsparcia przez zespół deweloperski. Automatyzacja testów nie może działać w próżni. Testy automatyczne w dojrzałych organizacjach, są integralną częścią produktu tak jak kod aplikacji czy dokumentacja. Dobry zespól deweloperski rozumie i wspiera testerów w osiągnięciu tego celu.

Jak zespół deweloperski może wspierać automatyzację testów? Tutaj możemy wymienić takie punkty jak:

• Przygotowanie aplikacji/produktu pod automatyzację -- do tego punktu wrócimy w kolejnym artykule,
• Tworzenie testów automatycznych,
• Code review testów automatycznych,
• Utrzymanie testów,
• Inne elementy.

W takich razie czy testy automatyczne powinny być pisane w języku, w którym jest tworzona aplikacja?

Odpowiedź na pytanie nie jest jednoznaczna.

Bonus w postaci tego samego języka aplikacji

Na pewno jest to swego rodzaju bonus, gdy aplikacja i testy tworzone są w tym samym języku. Zespół deweloperski może wtedy wspierać twórców testów automatycznych we wszystkich czynnościach takich jak code review, utrzymanie testów itp. Infrastruktura CI/CD potrzebna do deploymentu aplikacji i uruchomienia testów na jednej maszynie (lokalnej/agencie CI) jest też znacznie prostsza. Oczywiście, jeśli po prostu nie orkiestrujemy testów i aplikacji za pomocą na przykład kontenerów dockerowych i jedyne czego potrzebujemy to docker.

Co więcej jeśli trzymamy testy w tym samym repozytorium co kod aplikacji, na przykład dla aplikacji w architekturze monolitu. To każdą zmianę wykonaną przez dewelopera możemy przepuścić przez prosty proces w ramach środowiska CI. Przykładowy proces poniżej. Zagwarantujemy sobie wtedy, że branch develop będzie bardziej zielony, niż zwykle.

Cały powyższy proces możemy też uzyskać trochę większym kosztem nawet w sytuacji, gdy tworzymy automatyzację w języku inny, niż języka aplikacji oraz różnych repozytoriach. Poziom skomplikowania nam wtedy niestety rośnie.

Nie jest też tak, że zawsze powinniśmy pisać testy w tym samym języku co aplikacja. Inny język staje się lepszym wyborem w sytuacji, kiedy zespół/osoby, które będą, tworzyły automatyzację specjalizują się w innym języku i są całkowicie niezależne od zespołu deweloperskiego. Ewentualny koszt przekwalifikowania zespołu na ten sam język, co język aplikacji będzie bardzo wysoki. Wszystko jak zawsze zależy od kontekstu.

Synergia albo jej brak

Kolejnym bardzo ważnym aspektem przy planowaniu automatyzacji jest synergia między narzędziami użytymi do automatyzacji. Synergia z definicji to współdziałanie różnych czynników. W automatyzacji znaczy ona tyle, że każda warstwa automatyzacji, którą tworzymy, powinna ze sobą współdziałać i współpracować.

Najprostszym przykładem będzie sytuacja, w której testy API (integracyjne) wykorzystując protokół HTTP, zadają i czyszczą dane testowe dla testów GUI. Poniżej przykład REST-assured i Selenium.

public class PetStoreTest extends TestBase {
	
	    private User user;
	    private LandingPage landingPage;
	    private HomePage homePage;
	
	    public String randomUsername = "john" + new RandomValues().getRandomAlphaNumericWithSize(2);
	
	    @Before
	    public void beforeTest() {
	        setupSelenium();
	
	        user = UserCreator.getUser(TEST_DATAFILE);
	        user.setUsername(randomUsername);
	
	        RestCreateUser preconditions = new RestCreateUser();
	        preconditions.createUser(user);
	
	        landingPage = new LandingPage();
	        homePage = landingPage
	                .clickOnEnterStoreLink()
	                .clickOnSignInLink()
	                .typeIntoUsername(user.getUsername())
	                .typeIntoPassword(user.getPassword())
	                .clickOnLogin();
	    }
	
	    @Test
	    public void asRegisteredUserLogIntoTheShop() {
	        homePage
	                .assertThatMyAccountLinkIsDisplayed();
	    }

	    @Test
	    public void asRegisteredUserPlaceAnOrder() {
	        homePage
	                .clickOnFishCategory()
	                .clickOnAngelFish()
	                .clickOnAddToCardForLargeAngelFish()
	                .clickOnProceedToCheckOut()
	                .clickOnContinueButton()
	                .clickOnOrder()
	                .assertThatThankYouOrderMessageWasDisplayed();
	    }
	}

Analizując powyższy przykład, widzimy, że wybór narzędzi/bibliotek wykorzystywanych do automatyzacji zaczyna mieć ogromne znaczenie. Bardzo ciężko może być osiągnąć taką synergię, gdy na przykład do testów backendu wybierzemy takie narzędzie jak Postman, zaś do testów frontendu Katalon Studio. Jako że są to dwa różne produkty niewspółpracujące ze sobą.

Problem ten zaczyna jeszcze narastać w momencie, gdy wykonujemy scenariusze, które generują dane w bazie danych, których nie da się usunąć za pomocą API. Jedynym rozwiązaniem wtedy jest dodanie w ramach frameworku do automatyzacji dodatkowego klienta do bazy danych, który będzie sprzątał po testach. W ramach takich narzędzi jak Postman, Katalon Studio, SoapUI integracja na przykład z klientem MS SQL jest niemożliwa. Oczywiście można zrobić to gdzieś z boku, ale generujemy wtedy dodatkowy zewnętrzny element do utrzymania.

Podsumowując automatyzacja/framework oparty o język programowania zawsze będzie bardziej elastyczny.

Dostępność bibliotek wspierających testy i proof concept

Kolejnym bardzo ważnym elementem jest dostępność bibliotek oraz narzędzi w wybranym języku. Jeszcze parę lat temu dostępność bibliotek wspierających testy była zróżnicowana dla różnych języków programowania. Na dzisiaj te różnice mocno się zacierają, jednakże zdaje się, że Java cały czas pozostaje na podium. Niezależnie od preferencji bardzo ważne jest, aby wykonać proof of concept dla każdego narzędzia/biblioteki, które chcemy na stałe wpleść w ramach frameworka do automatyzacji.

Przed wykonaniem proof of concept powinniśmy zdefiniować wymagania, jakie powinno spełniać dane narzędzie. Takimi wymaganiami mogą być na przykład:

• Płatne lub darmowe narzędzie,
• Dobra dokumentacja narzędzia,
• Wsparcie specyficznych przeglądarek, protokołu komunikacyjnego, systemu,
• Stałe wsparcie community lub producenta,
• Dojrzałe narzędzie (dostępne od wielu lat na rynku),
• Integracja z narzędziami do raportowania lub wbudowane raporty wykonania,
• Wsparcie środowisk CI/CD,
• Możliwość parametryzacji,
• Możliwość pracy wielowątkowo,
• Specyficzne wymagania projektowe lub biznesowe np. Narzędzie musi umieć obsługiwać iframe, ponieważ będą one stosowane w aplikacji.

W ramach proof of concept bardzo łatwo wpaść w pułapkę mody.

Pułapka mody

To nic innego jak wybranie nowo powstałego, modnego narzędzia na rynku, które nie spełnia, któregoś ze zdefiniowanych wymagań. Takiego jak na przykład brak wsparcia dla tagu iframe. Przykładowo Cypress takiego wsparcia nie posiada w tym momencie (26.01.2020). Twórcy pracują nad tym.

Restful-booker -- planowanie

Czas przejść do planowania automatyzacji dla aplikacji restful-booker. Przejdźmy przez postawione wyżej pytania.

W jakim języku będzie tworzona automatyzacja?

• Java. Backend aplikacji jest pisany w Javie.

Jakie główne narzędzia/frameworki wykorzystamy?

• TestNG -- Potężne narzędzie do uruchamiania, konfigurowania i zarządzanie testami,
• Selenium -- do testów GUI Web,
• REST-assured -- do testów REST API,
• Allure -- Raporty TestNG są dla nas nie wystarczające, dlatego zastosujemy Allura, który wspiera TestNG, wielowątkowe wykonanie testów itp.
• Maven -- budowanie i zarządzanie zależnościami,
• Klient do bazy -- użyty build aplikacji restful-booker na ten moment nie zezwala na połączenia do bazy.

Proof of concept

• Wszystkie narzędzia przeszły przez proof of concept spełniając zdefiniowane wymagania.

Utworzenie lub skorzystanie z istniejącego frameworka do testów automatycznych

• W ramach projektu zostanie stworzony framework od podstaw. Decyzja ta wynika z ograniczeń biznesowych i technicznych. Nie możemy skorzystać z testów ani repozytorium twórców aplikacji restful-booker.

Zdefiniowanie zakresu testów, co testujemy, a czego nie,

• Wraz z zespołem deweloperskim została podjęta decyzja o przejęciu przez zespół testerski testów integracyjnych oraz testów E2E.
• Zespół deweloperski będzie odpowiadał za testy jednostkowe. Będzie też uczestniczył w utrzymaniu testów tworzonych przez zespół testowy.

Inne wymagania biznesowe

• Wsparcie dla dwóch przeglądarek Chrome oraz Firefox.
• Jak najszybsze wykonanie testów.
• Testy mają wspomagać wydanie na produkcję.

Zdefiniowanie typu testów oraz pokrycia,

• W ramach projektu automatyzacji zostaną przygotowane testy dymne, integracyjne oraz end-2-end.

Infrastruktura

• Testy będą uruchamiane w ramach Jenkinsa hostowanego na środowisku Linux i/oraz Windows.
• Infrastruktura do testów (Selenium GRID) i inne mają działać w ramach kontenerów Dockerowych.

Na tym zakończymy pierwszą część planowania. W kolejnym artykule przejdziemy do przygotowania aplikacji do testów automatycznych.

Potrzebujesz więcej informacji?

Artykuł powstał na bazie kursu Automatyzacja testów z wykorzystaniem Selenium.

O Autorze

Nazywam się Mateusz Ciołek i od 2011 roku zajmuję się testowaniem oprogramowania ze specjalizacją w automatyzacji testów.