Na samym początku tego wpisu śmiało mogę stwierdzić, że znaczna część osób odpowiedzialna za jakość oprogramowania, prędzej czy później myśli o przekwalifikowaniu się na automatyka testów. Dzieje się tak głównie dlatego, że jest to najbardziej naturalna ścieżka rozwoju testera. Testerzy manualni po kilku latach pracy szukają nowych wyzwań i sposobu na przerwanie monotonii pracy. Pozwala to poszerzyć wiedzę i kwalifikacje a co za tym idzie powiększyć zarobki.

Wielu początkujących nie zastanawia się jednak nad fundamentalnymi kwestiami dotyczącymi całego procesu, na jaki składa się automatyzacja testów. Większość uwagi skupiają tylko i wyłącznie na tym, aby znaleźć ofertę umożliwiającą pisanie testów automatycznych. Najczęściej kończy się to tym, że przez większość czasu, jaki poświęcają na automatyzowanie, poprawiają istniejące już testy lub kopiują większość dostępnych metod. Oczywiście nie jest to zła praktyka na start. Każdy kiedyś zaczyna. Warto jednak od samego początku przyswajać dobre praktyki i nie stać się osobą, która po jakimś czasie, przepracowanym w wyżej wymienionym trybie pracy, biorąc udział w rozmowach rekrutacyjnych, nie jest w stanie samodzielnie napisać prostego testu. Takie sytuacje mają miejsce, ponieważ dana osoba tylko i wyłącznie dotychczas, kopiowała istniejące rozwiązania. Na rynku coraz częściej pojawiają się właśnie tacy testerzy automatyzujący.

Muszę Wam powiedzieć, że pisanie testów automatycznych służących tylko i wyłącznie do powiększania liczby zautomatyzowanych testów nie ma większego sensu.

Szukając pracy lub pracując już jako automatyk, powinniście się zastanowić nad tym, czy macie świadomość tego, czy wasza praca nad testami automatycznymi jest efektywna i rzeczywiście wykonujecie ją w sposób przemyślany. W tym wpisie chce zachęcić Was do odpowiedzi na poniższe pytania, które zobrazują Wam czy to, w jaki sposób automatyzujecie testy lub zamierzacie to zrobić, daje waszemu projektowi maksymalną wartość.

Najważniejsze elementy, które powinniście wziąć pod uwagę przygotowując plan automatyzacji testów:

Pierwsze z najbardziej fundamentalnych pytań to takie czy nasz projekt naprawdę potrzebuje zautomatyzowanych testów?

Automatyzacja testów jest obecnie bardzo popularna, głównie przez korzyści, jakie za sobą niesie. Zmniejszenie ilości pracy manualnej, pokrycie najbardziej podatnych na błędy ścieżek czy też najczęściej wykonywanych akcji przez użytkowników naszego systemu, pozwalają na uniknięcie wprowadzenia krytycznych błędów na produkcje. Popularność tego rozwiązania, nie powinna być jednak głównym powodem jego stosowania. Trzeba zastanowić się, czy koszty i zasoby wykorzystane do tworzenia tych testów są adekwatne do korzyści, jakie chcemy osiągnąć. Powinniśmy mieć świadomość, że ktoś będzie musiał poświęcić określoną ilość czasu na pisanie tych testów, ich aktualizacji, naprawy a na samym początku również na research dotyczący narzędzi, jakie powinny zostać do tego wykorzystane. Co za tym idzie? Kolejne pytania. Czy mamy na pokładzie ludzi, którzy mogą poświęcić na to czas? Jeśli nie, musimy ich zatrudnić. Proces rekrutacji i wdrożenia nowego pracownika trwa. Od tego momentu do napisania testów automatycznych będziemy inwestować pieniądze, czas i zasoby a korzyści nie będą widoczne od razu. Warto mieć to na uwadze. Jeśli mamy osoby, które są w stanie automatyzować, musimy mieć świadomość, że będą poświęcać część swojego czasu na to i będzie się to odbywało kosztem innych obowiązków. Te kwestie mogą wydawać się bardzo trywialne, ale ich ignorowanie może przynieść więcej strat niż korzyści. Jeśli nasz projekt jest mały, liczba osób jest mocno ograniczona, ważne jest to, aby wybrać, optymalny sposób zredukowania ilości pracy, być może inny niż automatyzacja testów.

Wyobraźmy sobie sytuacje w której co dwa tygodnie kilku testerów musi przeprowadzać regresje całego systemu. Do ich obowiązków należy manualne klikanie co najmniej kilkaset przypadków testowych. Pierwszym rozwiązaniem jakie nasuwa się, aby mniejszych ilość manualnej pracy jest automatyzacja tych testów. Kluczową kwestią jest odpowiedzenie sobie na pytanie: Czy warto zautomatyzować wszystkie TCs? Odpowiedź oczywiście brzmi: Nie. Istnieje wiele testów, których automatyzacja może zająć ogromną ilość czasu, kombinacji i w efekcie będzie to test z ogromną ilością zamokowanych danych, nie mających zbyt wiele wspólnego z tym co robi użytkownik. Stracimy tym samym mnóstwo czasu a efekt będzie praktycznie żaden. Dodatkowo wyniki tego testu mogą być zakłamane przez stosowanie wielu różnych sztuczek przy jego automatyzacji.

Co więc powinniśmy automatyzować w pierwszej kolejności? Mając stworzonych kilkaset przypadków testowych, musimy je przegrupować pod względem ich krytyczności, ważności, wpływu, jaki mają na cały system oraz najczęściej podstawowych ścieżek wykonywanych przez użytkownika. Te właśnie ścieżki powinny zostać zautomatyzowane w pierwszej kolejności. Wszystkie przypadki testowe, których wykonanie wpływa na ocenę prawidłowego działania całego systemu, powinny znaleźć się bardzo wysoko na liście do zautomatyzowania. Zmniejszy to nie tylko ilość manualnej pracy, ale również zrobi sporą różnicę przy tworzeniu nowych funkcjonalności i możliwości szybszego sprawdzenia, czy nie został wprowadzony z nim jakiś błąd. Będzie się to działo bez konieczności klikania po najbardziej krytycznych ścieżkach przez testera, ponieważ będą już one zautomatyzowane, a wyniki tych testów pozwolą ocenić czy wszystko działa tak jak dotychczas. Na samym początku trzeba podzielić aplikację na moduły i wybierać najważniejsze i najczęściej użytkowane przez naszych klientów. Wraz ze wzrostem liczby zautomatyzowanych testów możemy pomyśleć o automatyzowaniu testów już w trakcie dewelopmentu nowych funkcjonalności.

Bardzo istotną kwestią jest również to czy testy automatyczne powinny być osobnym projektem, czy też lepszym rozwiązaniem jest umieszczenie ich razem z resztą kodu całej aplikacji. Bazując na własnych doświadczeniach, zdecydowanie zalecam, aby wszystkie testy były umiejscowione razem z resztą kodu. Niesie to za sobą wiele korzyści. Przede wszystkim deweloperzy mają łatwy dostęp do tych testów, dodatkowo widoczna jest cała historia dodawania kolejnych testów do repozytorium. W przypadku, gdy umknie nam jakiś błąd, może on być łatwo zauważony przez deweloperów, jak i również automaty mogą być od razu wykorzystane przez nich, w momencie sprawdzenia, czy ich kod niczego nie popsuł. Bardzo fajnym pomysłem jest również wykonywanie review naszych testów przez deweloperów. Jest to dużo łatwiejsze, gdy nie jest to osobny projekt. Deweloperzy również poważniej traktują te testy, jeśli są one integralną częścią kodu, a nie osobnym bytem, który musieliby szukać, jeśli chcieliby coś sprawdzić. Ułatwia to nie tylko pracę, ale podnosi też jakość pisanego kodu przy pomocy deweloperów.

Narzędzia, jakie będą stosowane przez nas do automatyzacji testów, powinny być dopasowane do standardów panującym w naszym projekcie. Wybierając framework, język i narzędzia powinniśmy pomyśleć, jak duża liczba osób będzie mogła bez większych szkoleń i przygotowania tworzyć w nich automaty. Warto zastanowić się, czy nie wybrać języka, który jest stosowany również do pisania frontendu/backendu w naszej aplikacji. Pozwoli to rozszerzyć listę potencjalnych osób, które nie koniecznie muszą być zaangażowane w ich pisanie, ale będą mieć wiedzę i możliwości do ich sprawdzania oraz utrzymania określonych standardów. Nie warto doprowadzić do sytuacji, w której każdy tester będzie pisał według swoich standardów, a później nikt poza nim nie będzie w stanie odnaleźć się w tym kodzie.

Tworząc testy automatyczne, musimy mieć również świadomość tego, że nie zlikwidują one 100% manualnej pracy. Jest to po prostu niemożliwe. Najważniejszą korzyścią jest to, że testy te mogą bardzo mocno skrócić czas manualnej pracy. W późniejszym czasie staną się one przepustką do wypuszczania kodu bez konieczności wykonywania ręcznego klikania przez testerów. Dojście do tego momentu wymaga jednak stworzenia wysokiej jakości testów automatycznych, które spokojnie będziemy traktować, jako strażnika jakości naszej aplikacji. Obszary, które nie jest w stanie obsłużyć automat lub jest to całkowicie nieopłacalne powinny być jak najbardziej zredukowane do formy sanity cheków, które wykonuje tester.

Ostatnią poruszaną w tym wpisie kwestią, jest to czy raz napisane testy automatyczne nie będą wymagać już od nas żadnej pracy. Jak się zapewne domyślacie, odpowiedź jest trywialna 🙂 Oczywiście, że będą. Tak samo, jak kod naszej aplikacji zmienia się każdego dnia, tak i również będzie w przypadku testów automatycznych. Będą się one psuły przez wprowadzanie nowych funkcjonalności do naszego systemu oraz tworzenia nowych koncepcji biznesowych, które mogą całkowicie zmienić istniejące już ścieżki w aplikacji. Bardzo ważne jest to, aby mieć przygotowane zasoby na konieczność ciągłej pracy nad tymi testami. Pozostawione same sobie, bez dbania o ich, szybko przestaną działać i ich wykonywanie straci jakikolwiek sens.

Mam nadzieję, że po przeczytaniu tego obszernego wpisu, wyniesiecie z niego mnóstwo przydatnej oraz praktycznej wiedzy. Jak u Was wygląda praca nad automatyzacją testów? Jak radzicie sobie z problemami, jakie spotykacie na swojej drodze?

Skomentuj Testerka Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany.

  • 19 lutego, 2020 o 6:32 pm

    Cześć, bardzo fajny wpis. Mamy tanie bo nie napisałaś tego: jakiego języka programowania używasz do testów, jakiego narzędzie (czy to jest selenium) i czy dobrze ci się z tą konfiguracją pracuje? Z doświadczeń wiem, że może to być trudne dla testera. Zwłaszcza dla tych, którzy nie mieli wcześniej styczności z programowaniem.

    • Testerka
      23 lutego, 2020 o 4:26 pm

      W swojej pracy pisze automaty w Cypressie w JavaScript. Selenium porzuciliśmy pod 3 miesiącach na rzecz języka w którym piszą nie tylko QA, ale też deweloperzy. Dzięki takiemu rozwiązaniu ilość pisanych testów i ich jakość znacznie wzrosła. Dla początkujących owszem może być to trudne, ale tak samo, jak ze wszystkim praktyka czyli mistrza.

      • 24 lutego, 2020 o 3:07 pm

        Dzięki za odpowiedź. Nie znałem Cypressa, pogooglałem trochę i całkiem fajnie to wygląda 😉

        • Testerka
          24 lutego, 2020 o 3:18 pm

          Następne wpisy będą właśnie o Cypressie, więc podzielę się wiedzą z mojego punktu widzenia.

  • Przemek
    25 marca, 2020 o 12:30 pm

    Hej Dorota! :)))) Bardzo chętnie poczytałbym o alternatywach dla Appium. A może powinienem zostać przy Appium?
    Pozdrawiam! :)))

  • Tomasz Diakowski
    9 grudnia, 2021 o 11:06 am

    Czesc,

    Bardzo fajny artykuł, jednak nie moge się z Tobą zgodzić, że lepszym rozwiązaniem jest, że testy automatyczne i kod aplikacji jest w tej samej solucji. Jak 99% rzeczy w pojektach odpowiedzią jest to zależy. Jednak mimo to, byłbym za tym, żeby to był osobny byt, ponieważ taka solucja będzie dużo ważyć. W jaki sposób jest wdrażana na produkcję. Wtedy zostają usuwane testy , wydzielane? Czy wszystko razem leci? Dodatkowa praca. Rownież review kodu przez developerów uważam za słabe podejście. Szanujmy zawód testera, niech co developerskie bedzie developerskie, a co testerskie zostanie testerskie. Czy naprawde sami nie możemy sprawdzać kodu? To znaczy mamy za mało wiedzy?
    Moim zdaniem to się nie sprawdza, ponieważ angażujemy czas developerów w nie ich działkę. Przez to produkt powstaje wolniej.

    Pozdrawiam

Ten serwis wykorzystuje pliki cookies. Korzystanie z witryny oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej
Zgoda