Testy end to end (E2E): co to jest, kiedy je uruchamiać i ile ich naprawdę potrzebujecie

Czas czytania: około 12 minut

Pojedyncze moduły mogą działać bez zarzutu, a mimo to cały proces biznesowy potrafi się rozsypać w najmniej oczekiwanym momencie. Wystarczy, że zawiedzie jedna integracja, baza danych zwróci błędną odpowiedź albo usługa zewnętrzna przestanie odpowiadać. Testy end to end sprawdzają produkt tak, jak widzi go klient, czyli od pierwszego kliknięcia po ostatni krok procesu.

Ten przewodnik jest dla testerów, liderów QA, product managerów i decydentów technicznych. Wyjaśniamy, czym są testy E2E, jaki jest ich cel, dlaczego mają znaczenie w złożonych systemach, czym różnią się od testów funkcjonalnych i integracyjnych, kiedy je uruchamiać oraz jak wygląda cały proces. Na koniec pokazujemy praktyczny przykład scenariusza i mówimy, ile takich testów naprawdę potrzebujecie.

Czym są testy end to end?

Testy end to end, znane też jako testy E2E, weryfikują, czy system realizuje wymagania biznesowe od początku do końca: sprawdzają wybraną funkcjonalność w całości, razem z bazami danych, zewnętrznymi integracjami i usługami, z perspektywy użytkownika końcowego.

To podejście patrzy na produkt całościowo, a nie przez pryzmat jednego fragmentu. Symulujecie realny scenariusz, którym posłuży się klient, a następnie sprawdzacie system pod kątem integracji i integralności danych. Zamiast pytać, czy ten przycisk działa, pytacie, czy użytkownik przejdzie przez cały proces i osiągnie swój cel.

Ten rodzaj testów zyskuje na znaczeniu, bo oprogramowanie staje się coraz bardziej złożone. Przybywa integracji z innymi systemami, podsystemami i usługami. Gdy zawiedzie jeden z tych elementów, istnieje realne ryzyko, że cały system przestanie działać poprawnie albo nie spełni swoich założeń. Miejsce testów E2E na szerszej mapie pokazujemy w tekście o typach testów oprogramowania.

Dlaczego testy end to end mają znaczenie biznesowe?

Testy end to end mają znaczenie biznesowe, bo awaria w połowie procesu zakupowego albo rejestracji uderza wprost w przychód i zaufanie, a E2E wychwytują takie problemy, zanim zrobi to klient.

Inne metody testowania, takie jak testy modułowe czy integracyjne, dostarczają cennych informacji o poszczególnych komponentach. To jednak testy E2E zapewniają najbardziej kompleksową analizę oprogramowania z perspektywy klienta końcowego. Patrzą na produkt tak, jak patrzy na niego osoba, która za niego płaci. Dzięki temu chronicie nie tylko jakość techniczną, ale też reputację produktu i wynik sprzedaży.

Liczby w pasku pochodzą z naszego projektu dla Argos, sklepu internetowego, i są potwierdzone przez klienta. Zakres obejmował automatyzację testów i uporządkowanie procesów QA. Konwersja wzrosła nie dlatego, że sklep dostał nową funkcję, tylko dlatego, że ścieżka od koszyka do płatności przestała się psuć. To jest wartość testów E2E wyrażona w pieniądzach, nie w liczbie znalezionych błędów.

Czym różnią się testy end to end od testów funkcjonalnych i integracyjnych?

Test funkcjonalny pyta, czy działa dany element, test integracyjny pyta, czy dwa elementy rozmawiają ze sobą poprawnie, a test E2E pyta, czy działa cała droga użytkownika przez wiele modułów, aplikacji i usług.

Po lekturze poprzednich sekcji łatwo pomyśleć, że testy E2E to po prostu testy funkcjonalne wykonywane na wielu etapach. To nie cała prawda. Te podejścia się uzupełniają, ale odpowiadają na inne pytania i działają w innej skali.

Szczegółowo o środkowej kolumnie piszemy w tekście Co to są testy integracyjne?. Najprościej zapamiętać to tak: test funkcjonalny pyta, czy działa dany element, a test E2E pyta, czy działa cała droga użytkownika.

Kiedy uruchamiać testy end to end?

Testy E2E uruchamia się na gotowym systemie, w końcowej fazie developmentu, gdy wszystkie funkcje biorące udział w przepływie już działają, ale ich scenariusze projektuje się dużo wcześniej, równolegle do prac developerskich.

Powód jest praktyczny. Aby przetestować pełen przepływ, wszystkie funkcjonalności biorące w nim udział muszą już w pełni działać. Uruchamianie testów E2E na niedokończonym produkcie prowadzi do fałszywych wyników i straconego czasu. Nie znaczy to jednak, że projektowanie testów E2E zostawiacie na sam koniec. Dzięki wcześniejszym scenariuszom w momencie, gdy produkt jest gotowy, macie komplet testów do uruchomienia, a nie pustą kartkę. W pipeline CI/CD testy E2E krytycznych ścieżek uruchamia się po smoke teście i przed decyzją o wydaniu, o czym piszemy w tekście o smoke teście.

Jak wygląda proces testów end to end?

Proces testów end to end ma cztery fazy: zebranie wymagań biznesowych, zaprojektowanie scenariuszy odzwierciedlających realne procesy, development i wykonanie scenariuszy na gotowym systemie.

Aby nadać temu ramy i powiązać testy E2E z resztą procesu QA, zacznijcie od solidnego planu testów, który porządkuje zakres, priorytety i odpowiedzialności w zespole.

Jakie są najczęstsze wyzwania w testach end to end?

Dwa największe wyzwania to zbudowanie przepływów w poprawnej kolejności oraz dostęp do wyizolowanego środowiska zbliżonego do produkcji. Warto je znać, zanim zaczniecie, bo to one najczęściej obniżają wartość testów E2E.

Tworzenie przepływów pracy. Aby przetestować funkcjonalność w całości, przypadki testowe w zestawie E2E muszą być uruchamiane w poprawnej kolejności. Ta sekwencja powinna odzwierciedlać ścieżkę użytkownika końcowego podczas poruszania się po aplikacji. Budowa zestawów dopasowanych do takiego przepływu bywa trudna i czasochłonna, zwłaszcza gdy mówimy o setkach, a nawet tysiącach testów.

Dostęp do środowiska testowego. Testowanie w środowisku deweloperskim jest stosunkowo proste. Każda aplikacja musi jednak przejść testy w środowiskach testowych, przedprodukcyjnych lub produkcyjnych. Te ostatnie nie zawsze są dostępne, dlatego trzeba korzystać z konfiguracji maksymalnie zbliżonych do produkcji. Skuteczne testy E2E wymagają środowiska na wyłączność, aby nie skrzyżowały się z innymi typami testów i nie zafałszowały wyników. Trzeba też liczyć się z przerwami w rodzaju aktualizacji systemu, które potrafią zatrzymać wykonywanie testów.

Dlaczego testy end to end są konieczne w złożonych systemach?

Testy end to end są konieczne w złożonych systemach, bo każda aplikacja komunikuje się z wieloma systemami i bazami danych poza własnym środowiskiem, a tylko E2E sprawdza, czy te zależności działają razem i czy dane przepływają między nimi poprawnie.

• Backend. Testy E2E weryfikują warstwy bazy danych i integracje backendowe. To konieczne, bo główna logika systemu rozgrywa się właśnie pod spodem.
• System wielowarstwowy. Gdy aplikacja ma złożoną architekturę działającą na wielu warstwach, testy E2E weryfikują zarówno funkcje, jak i interakcje między warstwami.
• Środowisko rozproszone. W architekturze zorientowanej na usługi albo w środowiskach chmurowych testy E2E są niezbędne, zwłaszcza gdy wiele komponentów musi działać w tandemie.
• Spójne doświadczenie użytkownika. Ponieważ testy E2E obejmują też frontend, potwierdzają, że produkt działa spójnie na wielu urządzeniach i platformach, w tym w różnych przeglądarkach.

Im więcej ruchomych części ma Wasz produkt, tym trudniej przewidzieć skutki ich współpracy. Testy E2E są właśnie po to, by sprawdzić te połączenia w warunkach zbliżonych do realnych. Jeśli część scenariuszy chcecie uruchamiać regularnie, warto rozważyć automatyzację testów, która utrzymuje stabilny zestaw E2E bez ręcznego powtarzania całej ścieżki.

Jak wygląda przykładowy scenariusz testu end to end?

Przykładowy scenariusz E2E dla sklepu internetowego prowadzi użytkownika od strony głównej, przez wybór produktu i koszyk, do podsumowania zamówienia, i na każdym kroku sprawdza dane, które przepływają między interfejsem a logiką systemu.

Teoria nabiera sensu na konkretnym przykładzie. Wyobraźcie sobie sklep internetowy i jedną z najważniejszych funkcjonalności, czyli zamawianie produktu. Scenariusz E2E przeprowadza użytkownika przez cały proces zakupu, krok po kroku, i na każdym etapie sprawdza, czy system reaguje zgodnie z oczekiwaniem.

To właśnie istota testu E2E. Nie sprawdzacie pojedynczego pola czy przycisku, lecz całą drogę, którą pokonuje klient, wraz z danymi przepływającymi przez kolejne warstwy systemu.

Scenariusze E2E uruchamiane regularnie, na przykład krytyczne ścieżki zakupu czy rejestracji, warto zautomatyzować, bo ręczne przechodzenie całej drogi za każdym razem pochłania dużo czasu. Kluczem jest utrzymywalność: stabilny zestaw automatyczny daje wartość, a chaotyczny szybko staje się obciążeniem.

Ile testów end to end naprawdę potrzebujecie?

Testów end to end potrzebujecie niewiele: kilkanaście do kilkudziesięciu scenariuszy na ścieżkach, których awaria kosztuje najwięcej, bo są najwolniejsze, najbardziej kruche i najdroższe w utrzymaniu ze wszystkich rodzajów testów.

W piramidzie testów E2E stoją na samym szczycie i to jest miejsce celowo wąskie. Test, który przechodzi przez przeglądarkę, kilka ekranów, bazę danych i integrację płatności, pada przy każdej zmianie interfejsu, czeka na środowisko i trwa minuty zamiast milisekund. Google w klasycznym tekście z 2015 roku radził wprost, żeby nie dokładać kolejnych testów E2E, tylko przesuwać sprawdzanie logiki niżej. Logikę biznesową sprawdzajcie testami jednostkowymi i API, styki modułów testami integracyjnymi, a E2E zostawcie dla zakupu, rejestracji, płatności i tych procesów, które w Waszym produkcie zarabiają albo tracą pieniądze. Jak rozłożyć ten wysiłek, opisujemy w tekście o piramidzie testów.

Sygnał, że macie za dużo testów E2E: zestaw trwa dłużej niż godzinę, zespół nie ufa czerwonym wynikom i przestaje na nie reagować. Sygnał, że macie za mało: błędy na produkcji dotyczą styków między systemami, których żaden test nie przechodził w całości.

Powiązane na blogu Quality Island

• Smoke test: co to jest, kiedy go uruchamiać i czym różni się od sanity testu
• Co to są testy integracyjne?
• Piramida testów i techniki projektowania testów
• Jak napisać plan testów: kompletny przewodnik
• Typy testów oprogramowania: jak je rozumieć i kiedy stosować

Pełna lista źródeł

• ISTQB Glossary, hasło end-to-end testing
• Google Testing Blog, Just Say No to More End-to-End Tests (2015)
• Martin Fowler, Test Pyramid oraz The Practical Test Pyramid
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta