Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jakie błędy popełnia początkujący tester automatyzujący?

Sprawdź, jakie błędy możesz popełnić jako początkujący tester automatyzujący i unikaj ich w swojej pracy.
Jakie błędy popełnia początkujący tester automatyzujący?

W poniższym tekście skupię się na błędach popełnianych przez początkujących testerów automatyzujących, którzy nie mieli wcześniej okazji pracować z Selenium Webdriver i Javą.


Nie spoczywaj na laurach 

Wielu początkujących testerów uczy się języka programowania i po krótkim wprowadzeniu w podstawową logikę, rozpoczyna pracę z Selenium, jednocześnie zaniedbując bardziej zaawansowane aspekty funkcjonowania Javy. 

Mimo że Selenium może się wydawać proste, stabilne (w kontekście wprowadzanych zmian-update’ów) oraz niewymagające zaawansowanej wiedzy programistycznej, to takie podejście może okazać się potocznym „strzałem w kolano”.

Aby tworzyć profesjonalne testy, musisz poznać i zrozumieć takie pojęcia, jak obiektowość, dziedziczenie, import statyczny, adnotacje, wyjątki, modyfikatory dostępu oraz wiele innych terminów, z którymi na 100% zetkniesz się jako tester automatyzujący. 

Znajomość tych zagadnień nie tylko umożliwi Ci w sprytny sposób rozwiązanie testerskich problemów, ale i znacząco podniesie poziom profesjonalizmu oraz zaufania do stworzonych przez Ciebie skryptów testowych


Wykorzystywanie nagrywarek testów

Oczywiście twórcom nagrywarek przyświecały dobre intencje, jednak wykorzystanie ich na początku swojej przygody z automatami, nie jest dobrym pomysłem. 

Po pierwsze, nagrywarki hamują rozwój Twojego programistycznego talentu :) Mam na myśli to, że nagrywając skrypt, nie utrwalasz swojej wiedzy poprzez aktywne pisanie kodu i nie kształtujesz programistycznego sposobu myślenia. 

Po drugie, osobie początkującej ciężko jest spojrzeć w sposób krytyczny na działający kod. Zazwyczaj, gdy skrypt wykonuje się bez błędu kompilacji, pozostaje już w niezmiennej formie „no bo po co go zmieniać?”. Teoretycznie możesz pomyśleć „o co chodzi temu gościowi, co mam zrobić z działającym kodem? 

Odpowiedz brzmi: poprawić:) serio! Ten wątek rozwinę w kolejnym akapicie.


Pomijanie wzorca projektowego

Wzorzec projektowy to w dużym uproszczeniu koncepcja budowy Twojego kodu według określonego schematu.

Możliwe, że zadasz sobie pytanie: „po co ktoś narzuca mi kolejne zasady? Czy praca programisty (napisałem programisty, ponieważ pisząc testy, też nim jesteś, bez względu na to, jak brzmi Twój oficjalny testerski tytuł zawodowy) to funkcjonowanie w wirtualnej dyktaturze?

Sama odpowiedź brzmi jak stereotypowe hasło rodem z prawdziwej dyktatury :D otóż: to dla Twojego dobra.

Wzorce projektowe de facto chronią Cię przed dodatkową pracą, i to pod wieloma względami ułatwiają debugowanie, poprawiają czytelność, zmniejszają ilość kodu i co najważniejsze, pozwalają na praktycznie błyskawiczne dodawanie nowych przypadków testowych. 

Wracając do nagrywarek, co mają one wspólnego z wzorcami? Praktycznie nic. Nagrywarki tworzą (pozwolę sobie na takie stwierdzenie) najgorszą wersję kodu, jaką byłbyś w stanie napisać. 

Praca z kodem wygenerowanym przez nagrywarkę jest żmudna i prowadzi do frustracji. Trzeba poświęcić dużo czasu na spreparowanie kodu do właściwej formy. W tym przypadku mamy do czynienia z paradoksem: narzędzie, które z definicji powinno ułatwić pracę, jeszcze bardziej ją komplikuje.

Tutaj masz link do jednego z najpopularniejszych wzorców testowych - Page Object.


Pisanie bezużytecznych testów

Będąc testerem automatyzującym, Twoim podstawowym zadaniem jest sprawdzanie, czy skompilowany i uruchomiony kod, napisany przez developerów z Twojego teamu, działa zgodnie ze specyfikacją. 

W powyższym zdaniu kryje się najważniejsza część - musisz się skupić na tej części aplikacji, która jest dziełem develeperów z Twojego zespołu

Developerzy frontendowi korzystają głównie z gotowych rozwiązań, jedynie dostosowując detale danego elementu, tak, aby były zgodne z wymaganiami

Przykładowo: nie ma sensu budowania skryptów obsługujących kontrolki typu kalendarz (datepicker), które wiernie odzwierciedlają to, co robi użytkownik. (kliknij w rok->wybierze rok->kliknij w miesiąc->wybierz miesiąc->kliknij w dzień…etc.)

Dlaczego? Bo jest to pracochłonne, wydłuża czas wykonania testu i oczywiście sprawdzasz mechanizm elementu, który został już przetestowany przez twórców, zanim trafił do komercyjnego użytku.

Nie zrozum mnie źle - nie oznacza to, że tego typu elementy powinny być pomijane. Wręcz przeciwnie, powinieneś sprawdzić, czy developer prawidłowo „dokleił” kod elementu do kodu Waszej aplikacji, jednak skup się tylko na przekazaniu danych do kontrolki. Jeśli masz kalendarz, to ustaw na nim datę poprzez wstrzyknięcie jej za pomocą np. JavaScriptExecutor (link do dokumentacji), zamiast pisać kilkadziesiąt linijek kodu z pojedynczymi kliknięciami. 

Kolejnym przykładem może być Google captcha, która jest powszechnie implementowana ze względu na bezpieczeństwo serwisów. Ten przypadek może się wydawać trochę „nietrafiony”, ponieważ captcha co do zasady ma chronić przez skryptami automatyzującymi. Więc jaki jest sens mają testy automatyczne tego elementu? No właśnie chcemy się przekonać, że prawidłowa implementacja captchy zablokuje „sztucznego” użytkownika

Poprzez powyższe przykłady chciałem Ci zobrazować różnorodność problemów na etapie analizy testów oraz uświadomić, że zdarzają się przypadki, w których oczywiste rozwiązania nie jest są tymi najlepszymi. Czyli nie zawsze pisanie testów do wszystkiego jest czymś pożądanym. Dlatego zanim napiszesz pierwszą linijkę kodu, powinieneś się solidnie przygotować, ale o tym w kolejnym akapicie.

Podsumowując, bezużyteczne testy to skrypty testowe weryfikujące elementy strony, które same w sobie nie są wytworem pracy developerów z Twojego zespołu oraz wszelki kod, który pokrywa przypadki testowe niezgodne z wymaganiami biznesowymi projektu.


Brak planowania i analizy w procesie testowym

Etap planowania i analizy testów są jednymi z najważniejszych w cyklu testowania aplikacji, a mimo to często są realizowane wybiórczo lub nawet są pomijane.

Zazwyczaj młodzi testerzy opisują od strony formalnej, co będzie testowane i przy pomocy jakiego narzędzia etc., ale w praktyce są to informacje zebrane ze względu na to, że projekt menedżer lub bussines owner po prostu tego wymaga.

Z drugiej strony, w wielu firmach i projektach nie ma jeszcze świadomości, jak ważny są to etapy i tester nie ma oficjalnie określonych ram czasowych na wykonanie tych czynności. Pominę wyliczenie czynników, które utrudnią realizację procesu testowego i skupię się na konsekwencjach.

Plan testów zrobiony na „odwal się”, w dużym stopniu podważa Twoją wiarygodność, ponieważ może dojść do sytuacji, gdzie wydanie aplikacje zostanie przesunięte tylko dlatego, że błędnie określiłeś testowane cechy i nagle okazuje się, że jest ich dwa razy więcej, lub zapomniałeś wspomnieć, że nie masz dostępu do bazy danych i poczekasz na niego kolejne 2 tygodnie. Uwierz mi, takie przypadki zdarzają się w korporacjach, gdzie odpowiedzialność ma bardziej rozproszoną formę.

Co do analizy: wielu początkujących automatyków wykonuje jedynie manualne testy, aby zapoznać się z interfejsem aplikacji, po czym odpalają IDE i zaczynają wklepywać kolejno lokatory i budować testy :) Niestety zakończenie może być tylko jedno - porażka.

Poza oczywistymi kwestiami, jak zapoznanie się dokumentacją, o której i tak wspomniałem oraz o zadawaniu pytań, i wyjaśnianiu niejasności (jako tester powinieneś wykazywać się proaktywnością), jest przygotowanie architektury Twoich testów. W praktyce najlepiej jest to zrobić w aplikacji (jest wiele darmowych wersji online) do projektowania przepływów decyzyjnych. W ten sposób w graficznie zobrazujesz sobie zależności pomiędzy klasami, upewnisz się, że prawidłowo implementujesz wzorzec projektowy. Jednym zdaniem stworzysz „step by step”, przepis na dobre jakościowo testy i nauczysz się wyobrażać sobie działanie kodu. 


Hard code i magic string

Każdemu zdarzyło się kiedyś coś wpisać w kodzie „na sztywno”. Nie muszę wspominać o tym, że jest to jedna z najgorszych praktyk w programowaniu i każdy powinien się jej wystrzegać. 

Początkujący testerzy zazwyczaj popełniają ten błąd przy próbie implementacji klas pobierających dane testowe z zewnętrzny źródeł (pliki CSV, etc.). Błąd przejawia się różnego typu wartościami, które nie posiadają inicjalizacji. Są to wartości, które w kodzie są całkowicie nieczytelne i należy analizować kod, aby ustalić, co właściwie przedstawiają.

Jeśli już skorzystasz z tej opcji, chodźmy ze względu na to, że nie masz pomysłu jak coś napisać, lub robisz to tylko „chwilowo” (chociaż w tym przypadku żadna wymówki nie jest dobra), to dodaj odpowiedni (dobrze widoczny) komentarz do linii, w której świadomie popełniłeś błąd i po prostu napraw go w pierwszej kolejności. 

Na początku możesz odnieść wrażenie, że tego typu błędy nie są szkodliwe, bo Twój kod składa się kilkudziesięciu linijek, jednak waga takiego błędu rośnie wraz z ilością dodania nowego kodu.


Redundancja, czyli nadmiarowość 

Popularne powiedzenie „od przybytku głowa nie boli” nie odnosi się do programowania. W tym przypadku minimalizm jest największą cnotą.

Jednak o jaki nadmiar chodzi? Wyjaśnię od początku. Obecnie w wielu stronach internetowych znajdują się elementy takiej jak np. klawisze (dobrym przykładem jest klawisz i pole obsługujące czynność zapisania użytkownika do „newsletteru”), które są wyświetlane na wszystkich podstronach serwisu.  

Gdy budujesz test w oparciu wzorzec projektowy Page Object*, każda podstrona powinna być reprezentowana przez klasę, a czynności wykonywane na elementach tej strony (klikanie w klawisze, wypełnianie pól, wybieranie z listy) przez metody zdefiniowane w tej klasie. 

Początkujący tester może popełnić błąd poprzez stworzenie kilku identycznych klas i metod obsługujących zapisanie się do newsletteru z poziomu każdej podstrony, i wtedy właśnie mamy do czynienia z nadmiarem. Oczywiście formularz jest tylko jeden i wystarczy jedna klasa, którą możemy użyć w dowolnej części testu.

Aby zrozumieć powyższe musisz rozumieć obiektowość w Javie.

*(Wzorzec wprojektowy Page Object to w dużym uproszczeniu plan budowy testu gdzie każda “część” strony, np.  nagłówek, ciało i stopka, ma swoje odzwierciedlenie w postaci klasy. Więcej informacji znajdziesz pod linkiem, który podałem w części „Pomijanie wzorca projektowego”)


Kończąc...

Mam nadzieję, że przedstawione przez mnie informacje pomogą Ci w uniknięciu błędów. Powodzenia :)

Nie przegap treści Bulldogjob
Subskrybuj artykuły

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej