Zautomatyzowane testowanie oprogramowania

Why is testing automation important to continuous delivery?

Ciągłe dostarczanie (CD) polega na jak najszybszym dostarczaniu klientom nowych wydań kodu. Zautomatyzowane testowanie ma kluczowe znaczenie dla osiągnięcia tego celu. Nie ma możliwości zautomatyzowania procesu dostarczania kodu użytkownikom, jeśli w jego ramach stosowane są ręczne, czasochłonne czynności.

CD jest częścią większego pipeline'u wdrażania. Proces CD jest następcą ciągłej integracji (CI), a równocześnie jest od niej zależny. Na CI spoczywa pełna odpowiedzialność za przeprowadzanie zautomatyzowanych testów wszelkich nowych zmian w kodzie i sprawdzanie, czy zmiany te nie powodują problemów w działaniu istniejących funkcji lub nie wprowadzają nowych błędów. Proces CD jest wyzwalany, gdy ciągła integracja przejdzie przez etap planu zautomatyzowanych testów.

Ta relacja pomiędzy zautomatyzowanym testowaniem, CI i CD zapewnia wiele korzyści zespołom programistycznym, które pracują z dużą prędkością. Zautomatyzowane testowanie zapewnia jakość na każdym etapie rozwoju, gwarantując, że w nowych commitach nie ma żadnych błędów, dzięki czemu oprogramowanie jest zawsze gotowe do wdrożenia.

1. Testy kompleksowe

Prawdopodobnie najbardziej wartościowymi testami do wdrożenia są testy kompleksowe (E2E). Testy E2E symulują środowisko użytkownika w całym stosie oprogramowania. Plany testów E2E zazwyczaj obejmują historyjki na poziomie użytkownika, takie jak na przykład: „użytkownik może się zalogować”, „użytkownik może dokonać wpłaty”, „użytkownik może zmienić ustawienia poczty e-mail”. Testy te są bardzo wartościowe, ponieważ dają pewność, że użytkownicy mogą bezproblemowo korzystać z oprogramowania, nawet po wprowadzeniu nowych commitów.

Narzędzia do testowania E2E przechwytują i odtwarzają działania użytkowników, więc plany testów E2E stają się zapisami kluczowych przepływów środowiska użytkownika. Jeśli w oprogramowaniu nie wprowadzono żadnego rodzaju zautomatyzowanych testów, największą wartość można uzyskać poprzez wdrożenie testów E2E w zakresie najbardziej kluczowych przepływów biznesowych. Testy E2E umożliwiają przechwycenie i zapisanie sekwencji przepływu użytkownika, ale mogą być kosztowne. Jeśli nie udostępniamy codziennie nowych wydań oprogramowania, bardziej ekonomicznym rozwiązaniem może być ręczne realizowanie planów testów E2E przez zespół pracowników.

2. Testy jednostkowe

Jak sama nazwa wskazuje, testy jednostkowe obejmują poszczególne jednostki kodu. Najlepszą miarą jednostek kodu są definicje funkcji. Test jednostkowy obejmuje pojedynczą funkcję. Tego rodzaju testy pozwalają upewnić się, że oczekiwane dane wejściowe do funkcji odpowiadają oczekiwanym danym wyjściowym. Najlepiej sprawdzają się w przypadku kodu zawierającego wrażliwe obliczenia (mogą dotyczyć np. finansów, opieki zdrowotnej czy przemysłu lotniczego). Testy jednostkowe są niedrogie i szybkie do wdrożenia oraz zapewniają wysoki zwrot z inwestycji.

3. Testy integracyjne

Często zdarza się, że jednostka kodu nawiązuje zewnętrzne połączenie z usługą innej firmy. Podstawowa testowana baza kodu nie ma dostępu do kodu tego narzędzia innej firmy. Testy integracyjne polegają na symulowaniu zależności innych firm i sprawdzaniu, czy łączący się kod działa zgodnie z oczekiwaniami.

Testy integracyjne są podobne do testów jednostkowych w zakresie sposobu pisania i oprzyrządowania. Testy integracyjne mogą stanowić niedrogą alternatywę dla testów E2E, jednak zwrot z inwestycji jest dyskusyjny, jeśli wdrożono już połączenie testów jednostkowych E2E.

4. Testy wydajności

W kontekście tworzenia oprogramowania termin „wydajność” służy do opisania jego szybkości i responsywności. Niektóre przykłady wskaźników wydajności to: „czas ładowania strony”, „czas pierwszego renderowania”, „czas odpowiedzi wyników wyszukiwania”. W ramach testów wydajności tworzone są pomiary i potwierdzenia dotyczące tych przykładowych przypadków. Zautomatyzowane testy wydajności uruchamiają przypadki testowe, korzystając z tych wskaźników, a następnie powiadamiają zespół o wszelkich regresjach lub utracie prędkości.

Jakie rodzaje testów oprogramowania należy wykonywać ręcznie?

Niektórzy twierdzą, że należy zautomatyzować wszystkie możliwe do zautomatyzowania testy. Wiąże się to z ogromnym wzrostem wydajności i znaczną oszczędnością czasu pracowników. Jednak w niektórych przypadkach zwrot z inwestycji w opracowanie zestawu zautomatyzowanych testów nie jest opłacalny w porównaniu z wykonaniem testu ręcznego.

1. Testowanie eksploracyjne

Zautomatyzowane testy są oskryptowane i wykonują sekwencję kroków w celu sprawdzenia poprawności zachowania. Testy eksploracyjne są bardziej losowe i wykonują sekwencje bez użycia skryptów, aby znaleźć błędy lub nieoczekiwane zachowanie. Chociaż istnieją narzędzia programowe do tworzenia zestawów testów eksploracyjnych oprogramowania, nie są one jeszcze w pełni dopracowane ani powszechnie przyjęte. O wiele bardziej efektywne może być przypisanie ręcznego testera QA i wykorzystanie ludzkiej kreatywności do znalezienia sposobu na zepsucie oprogramowania.

2. Testowanie regresji wizualnej

Regresja wizualna ma miejsce, gdy do interfejsu użytkownika oprogramowania zostaje wprowadzona wizualna wada projektowa. Mogą to być np. źle umiejscowione elementy interfejsu użytkownika, niewłaściwa czcionka czy złe kolory. Podobnie jak w przypadku testów eksploracyjnych istnieją narzędzia do pisania testów automatycznych, które pozwalają na wychwycenie tych regresji. Narzędzia te przechwytują zrzuty ekranu przedstawiające różne stany oprogramowania, a następnie wykorzystują technologię OCR do porównania ich z oczekiwanymi wynikami. Opracowanie tych testów jest kosztowne, a narzędzia nie zostały szeroko przyjęte. O wiele skuteczniejsze może być sprawdzenie treści pod kątem problemów wizualnych przez człowieka.

3. Tworzenie ram automatyzacji testów dla zespołu DevOps

Nie istnieje uniwersalne rozwiązanie w zakresie zautomatyzowanego testowania. Planując rozwiązanie do zautomatyzowanego testowania dla swojego zespołu, należy wziąć pod uwagę kilka kluczowych kwestii.

4. Częstotliwość wydawania

W przypadku oprogramowania wydawanego w stałych odstępach czasu, np. co miesiąc lub co tydzień, testowanie ręczne może okazać się lepszym rozwiązaniem. Oprogramowanie, które jest wydawane szybciej, bardzo skorzysta ze zautomatyzowanego testowania, ponieważ procesy CI i CD są zależne od tego typu testów.

5. Dostępne narzędzia i ekosystem

Każdy język programowania ma swój własny ekosystem uzupełniających się narzędzi. Każdy typ wzorca zautomatyzowanego testu charakteryzuje się własnym zestawem narzędzi, które mogą, ale nie muszą być dostępne w ekosystemie danego języka programowania. Pomyślne wdrożenie wzorca zautomatyzowanego testowania wymaga zgodności w zakresie języka i wsparcia narzędzi.

6. Dopasowanie produktu do rynku i dojrzałość bazy kodu

Jeśli Twój zespół pracuje nad nowym produktem, w przypadku którego nie ma jeszcze sprawdzonej grupy docelowej lub konkretnego modelu biznesowego, inwestowanie w zautomatyzowane testy może nie mieć sensu. Zautomatyzowane testy działają jak mechanizm ubezpieczeniowy ograniczający nieoczekiwane regresje kodu. Gdy zespół pracuje z dużą prędkością, a kod ulega dramatycznym i szybkim zmianom, konieczność aktualizowania i utrzymywania zautomatyzowanych testów może wiązać się z frustrująco wysokimi kosztami.

Włącz zautomatyzowane testowanie do swojego pipeline'u CD

Zautomatyzowane testowanie to standardowa, nowoczesna metoda tworzenia oprogramowania. Najlepsze zespoły i firmy korzystają ze zautomatyzowanych testów. Procesy CI/CD są zależne od zautomatyzowanych testów i mają kluczowe znaczenie dla najlepszych zespołów dostarczających klientom niezawodne i solidne oprogramowanie.

Open DevOps firmy Atlassian zapewnia dostęp do otwartej platformy łańcucha narzędzi umożliwiającej tworzenie pipeline'u programistycznego opartego na CD z wykorzystaniem ulubionych narzędzi. Dowiedz się, jak wykorzystać narzędzia firmy Atlassian i innych firm, aby włączyć testowanie do przepływu pracy, sięgając do naszych samouczków dotyczących testowania DevOps.