Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów

Czas czytania: około 13 minut

Zespół ma osiemset testów automatycznych przez interfejs, regresja trwa dwie noce, co trzeci przebieg pada na czymś, co nie jest błędem, a i tak najpoważniejsze awarie wychodzą na produkcji. Testów jest dużo, tylko są w złym miejscu. Piramida testów to model, który mówi, gdzie testów powinno być najwięcej, a gdzie najmniej, i dlaczego zespół z tysiącem testów interfejsu ma gorszą ochronę niż zespół z tysiącem testów jednostkowych i pięćdziesięcioma przez interfejs.

W tym tekście wyjaśniamy, czym jest piramida testów i skąd się wzięła, jakie ma warstwy i proporcje, dlaczego odwrócona piramida jest droga, czym różni się od poziomów testowania ISTQB, czy nadal obowiązuje w czasach mikroserwisów, jakie techniki projektowania testów wypełniają każdą warstwę i jak przebudować istniejący zestaw testów krok po kroku. Piszemy z projektu, w którym przeniesienie testów z interfejsu na API skróciło regresję z pięciu dni do dziesięciu godzin.

Czym jest piramida testów?

Piramida testów to model opisany przez Mike’a Cohna w książce Succeeding with Agile z 2009 roku i spopularyzowany przez Martina Fowlera: testy automatyczne układa się w warstwy, gdzie podstawą są liczne testy jednostkowe, środkiem testy integracyjne, a szczytem nieliczne testy przez interfejs użytkownika.

Martin Fowler podaje, że większość ludzi zna piramidę dzięki Cohnowi, który w swojej książce z 2009 roku nazwał ją piramidą automatyzacji testów. Kształt nie jest ozdobą: szerokość warstwy oznacza liczbę testów, a wysokość ich koszt. Słownik ISTQB ujmuje ją jako graficzny model przedstawiający relację między ilością testów na poziom a ich szczegółowością, szybkością wykonania i kosztem utrzymania.

Piramida odpowiada na jedno pytanie: gdzie umieścić sprawdzenie danej reguły, żeby było najtańsze w napisaniu, najszybsze w uruchomieniu i najstabilniejsze w utrzymaniu. Reguła naliczania rabatu sprawdzona testem jednostkowym trwa milisekundę i pada tylko wtedy, gdy ktoś zepsuje rabat; ta sama reguła sprawdzona przez przeglądarkę trwa minutę i pada także wtedy, gdy ktoś zmieni kolor przycisku.

Jakie warstwy ma piramida testów?

Piramida ma trzy warstwy automatyczne: testy jednostkowe (funkcja lub klasa w izolacji), testy integracyjne i API (współpraca modułów, usług, bazy) oraz testy end to end przez interfejs (pełna ścieżka użytkownika); nad nimi często rysuje się chmurkę testów manualnych i eksploracyjnych, których piramida nie zastępuje.

Środek piramidy jest tym, o którym Cohn pisał jako o zapomnianej warstwie: zespoły mają testy jednostkowe i testy przez interfejs, a między nimi pustkę, którą wypełniają testami UI sprawdzającymi logikę dostępną przez API. Jak wygląda ta warstwa w praktyce, opisujemy w tekstach o testach integracyjnych i testach API w Postmanie, a szczyt w tekście o testach end to end.

Jakie proporcje testów zakłada piramida?

Najczęściej cytowana proporcja to 70 procent testów jednostkowych, 20 procent integracyjnych i 10 procent end to end, podana przez Google jako pierwsze przybliżenie; sam autor tej reguły zastrzega, że dokładny rozkład zależy od produktu, a liczby są punktem wyjścia, nie celem.

W tekście Just Say No to More End-to-End Tests na blogu Google Testing Blog z 2015 roku pada podział 70/20/10 jako dobre pierwsze przybliżenie, z dopiskiem, żeby nie przywiązywać się do tych liczb, tylko myśleć o własnym produkcie i jego ryzykach. Fowler w The Practical Test Pyramid idzie dalej: ważniejsze od proporcji są dwie zasady, pisać testy o różnej ziarnistości i mieć ich tym mniej, im wyżej w piramidzie.

Liczby z projektu dla Argos, potwierdzone przez klienta. Proporcja u tego klienta nie wyszła 70/20/10 i nie musiała. Wyszło to, co miało: reguły biznesowe zeszły na poziom, na którym sprawdza się je w sekundę, a przez interfejs zostały tylko ścieżki, które użytkownik naprawdę klika.

Dlaczego odwrócona piramida jest tak droga?

Odwrócona piramida, nazywana lodami w rożku, to zestaw, w którym najwięcej jest testów przez interfejs, a najmniej jednostkowych; jest droga, bo każdy test interfejsu trwa sto do tysiąca razy dłużej niż jednostkowy, pada na zmianach niezwiązanych z testowaną regułą i wymaga utrzymania przy każdej zmianie wyglądu.

• Czas. Osiemset testów przez przeglądarkę po minucie to trzynaście godzin. Osiemset testów jednostkowych to kilka sekund. Regresja, która trwa noc, biegnie raz dziennie; regresja, która trwa minutę, biegnie przy każdej zmianie.
• Stabilność. Test interfejsu zależy od przeglądarki, sieci, danych, czasu ładowania i stanu innych systemów. Pada z powodów, które nikogo nie interesują, a zespół uczy się ignorować czerwone wyniki.
• Utrzymanie. Zmiana układu formularza psuje pięćdziesiąt testów, które sprawdzały rabaty, choć rabaty działają. Ktoś musi je poprawić, zanim pipeline znów będzie zielony.
• Diagnostyka. Test end to end mówi „zakup się nie udał”. Test jednostkowy mówi „funkcja zaokrąglania zwraca 179,99 zamiast 180,00″. Pierwszy zaczyna śledztwo, drugi je kończy.
• Fałszywe poczucie pokrycia. Setki testów interfejsu sprawdzają kilkanaście ścieżek, bo każdy klika przez te same ekrany. Warianty logiki, które decydują o błędach, zostają niesprawdzone.

Odwróconą piramidę buduje się nieświadomie: zespół testowy ma dostęp do interfejsu, nie do kodu, więc automatyzuje to, co widzi. Wyjście z tego stanu opisujemy krok po kroku niżej, a od strony strategii w tekście o shift left testing. Ten sam mechanizm od strony kosztów regresji pokazujemy w tekście o testach regresyjnych.

Piramida testów a poziomy testowania ISTQB: czym się różnią?

Poziomy testowania ISTQB (jednostkowe, integracyjne, systemowe, akceptacyjne) mówią, kiedy w cyklu wytwarzania i wobec czego testujemy, a piramida mówi, ile testów automatycznych opłaca się mieć na każdym z tych poziomów; poziomy to mapa, piramida to budżet.

Oba modele się uzupełniają: plan testów układa się według poziomów, a w każdym poziomie piramida podpowiada, co automatyzować. Poziomy opisujemy w tekście o poziomach testowania oprogramowania, a typy testów, które przecinają wszystkie poziomy, w tekście o typach testów.

Czy piramida testów nadal obowiązuje: trofeum, diament i mikroserwisy

Piramida obowiązuje jako zasada „im wyżej, tym mniej”, ale jej kształt zmienia się z architekturą: w aplikacjach frontendowych popularne jest trofeum testowe z naciskiem na testy integracyjne komponentów, w mikroserwisach diament z naciskiem na testy kontraktowe i API, a w każdym z nich szczyt zostaje wąski.

Kent C. Dodds w tekście o trofeum testowym argumentuje, że w aplikacjach frontendowych najlepszy zwrot dają testy integracyjne komponentów, a nie masa testów jednostkowych izolujących każdą funkcję. W mikroserwisach środek piramidy rośnie, bo większość ryzyka siedzi na stykach usług, a testy kontraktowe zastępują część testów end to end. Fowler w The Practical Test Pyramid pokazuje ten sam zestaw z dodatkową warstwą testów kontraktowych między usługami.

Wspólny mianownik wszystkich wariantów jest jeden: żaden z nich nie proponuje, żeby na szczycie było dużo testów przez interfejs, a spór dotyczy tylko tego, jak gruby ma być środek. Zespół, który tłumaczy odwróconą piramidę „nowoczesnym podejściem”, nie stosuje trofeum ani diamentu, tylko nie ma testów niżej.

Jakie techniki projektowania testów wypełniają piramidę?

Techniki projektowania testów to metody wyboru przypadków testowych: czarnoskrzynkowe (klasy równoważności, wartości brzegowe, tablice decyzyjne, przejścia stanów, przypadki użycia), białoskrzynkowe (pokrycie instrukcji i gałęzi) oraz oparte na doświadczeniu (zgadywanie błędów, testowanie eksploracyjne, listy kontrolne); bez nich piramida ma właściwy kształt i przypadkowe wypełnienie.

Tablica decyzyjna: rabat w koszyku (fragment)

Warunki                      T1    T2    T3    T4    T5
Klient stały                 tak   tak   nie   nie   tak
Koszyk >= 500 zl             tak   nie   tak   nie   tak
Kod promocyjny wazny         nie   nie   nie   nie   tak

Akcje
Rabat 10% (staly klient)     X     X                 X
Rabat 5% (koszyk >= 500)     X           X           X
Rabat z kodu 15%                                     X
Laczny rabat ograniczony     15%   10%   5%    0%    15%  (limit 15%)

Kazda kolumna to jeden test. T5 sprawdza limit sumowania rabatow,
czyli regule, o ktorej zwykle nikt nie pamieta, dopoki nie zaplaci.

Definicje technik w słowniku ISTQB: klasy równoważności, wartości brzegowe, tablice decyzyjne, przejścia stanów, testowanie eksploracyjne. Techniki uczymy na przykładach z realnych systemów na szkoleniach Analiza testowa: od wymagań do przypadków testowych oraz ISTQB Certyfikowany Tester 4.0, gdzie są jednym z głównych rozdziałów sylabusa.

Jak dobrać technikę projektowania do warstwy piramidy?

Techniki dobiera się do warstwy: klasy równoważności, wartości brzegowe i pokrycie gałęzi do testów jednostkowych, tablice decyzyjne i przejścia stanów do testów integracyjnych i API, przypadki użycia do testów end to end, a eksplorację do wszystkiego nowego; ten sam przypadek testowy napisany na złej warstwie kosztuje wielokrotnie więcej.

Najczęstszy błąd to sprawdzanie tablicy decyzyjnej przez interfejs: dwadzieścia kolumn tablicy rabatów jako dwadzieścia testów klikających przez koszyk. Te same dwadzieścia przypadków na poziomie API biegnie w kilka sekund i nie pada na zmianie wyglądu koszyka. Technika mówi, które przypadki napisać. Piramida mówi, gdzie. Dopiero razem dają zestaw, który jest jednocześnie mały, szybki i skuteczny.

Jak zbudować piramidę testów w istniejącym projekcie krok po kroku?

Przebudowa zestawu w istniejącym projekcie zajmuje sześć kroków: inwentaryzacja testów według warstw i czasu, wskazanie testów interfejsu sprawdzających logikę, przeniesienie tej logiki na API i testy jednostkowe, wycięcie duplikatów, zostawienie na szczycie tylko ścieżek krytycznych oraz wpięcie warstw w pipeline z limitami czasu.

Tak wyglądał projekt dla Argos: najpierw tabela z kroku pierwszego, potem miesiące przenoszenia logiki z interfejsu na API, na końcu regresja w dziesięć godzin zamiast pięciu dni. Wdrażamy to w ramach automatyzacji testów, a plan takiej przebudowy jest zwykle częścią strategii jakości oprogramowania. Różnice między testowaniem manualnym a automatycznym, które decydują o tym, co w ogóle trafia do piramidy, opisujemy w tekście o testowaniu manualnym i automatycznym.

Jakie są najczęstsze błędy przy piramidzie testów?

Najczęstsze błędy to odwrócona piramida, pusta warstwa środkowa, testy jednostkowe sprawdzające implementację zamiast zachowania, traktowanie proporcji 70/20/10 jako normy, brak technik projektowania (właściwy kształt, przypadkowe wypełnienie) oraz mierzenie pokrycia kodu zamiast pokrycia ryzyka.

1. Odwrócona piramida. Najwięcej testów przez interfejs, bo zespół testowy widzi tylko interfejs. Rozwiązanie: dostęp do API i kodu dla testerów, wspólna odpowiedzialność za warstwy.
2. Pusta warstwa środkowa. Jednostkowe i end to end, a między nimi nic. Styki między modułami sprawdzane przez przeglądarkę albo wcale.
3. Testy implementacji. Test jednostkowy, który pada przy każdej refaktoryzacji, choć zachowanie się nie zmieniło. Testuje się wynik, nie sposób jego uzyskania.
4. Proporcja jako cel. Zespół dopisuje testy jednostkowe, żeby dojść do 70 procent, zamiast sprawdzić, czy krytyczne reguły są pokryte gdziekolwiek.
5. Kształt bez technik. Piramida wygląda dobrze, a testy sprawdzają wartości losowe zamiast klas równoważności i brzegów. Pokrycie kodu wysokie, pokrycie ryzyka niskie.
6. Piramida jako zamiennik testów manualnych. Automatyzacja nie zastępuje eksploracji, użyteczności ani odbioru z użytkownikami. Chmurka nad piramidą jest częścią modelu.

Kompetencje w tym obszarze budujemy na szkoleniach z automatyzacji testów i testowania manualnego, gdzie techniki projektowania są osobnym modułem. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o piramidę testów

Co to jest piramida testów?

Piramida testów to model rozkładu testów automatycznych: dużo szybkich testów jednostkowych u podstawy, mniej testów integracyjnych i API w środku, niewiele wolnych testów end to end przez interfejs na szczycie. Opisał ją Mike Cohn w 2009 roku, spopularyzował Martin Fowler.

Jakie są warstwy piramidy testów?

Trzy warstwy automatyczne: testy jednostkowe (funkcja lub klasa w izolacji), testy integracyjne i API (współpraca modułów i usług) oraz testy end to end przez interfejs (pełna ścieżka użytkownika). Nad nimi testy manualne i eksploracyjne, których piramida nie zastępuje.

Jakie proporcje testów zakłada piramida?

Google podaje 70 procent jednostkowych, 20 procent integracyjnych i 10 procent end to end jako pierwsze przybliżenie, z zastrzeżeniem, że dokładny rozkład zależy od produktu. Ważniejsza od liczb jest zasada: im wyżej w piramidzie, tym mniej testów.

Czym jest odwrócona piramida testów?

To zestaw, w którym najwięcej jest testów przez interfejs, a najmniej jednostkowych, nazywany lodami w rożku. Jest drogi, bo testy interfejsu są wolne, kruche i padają na zmianach niezwiązanych z testowaną regułą, a regresja trwa noc zamiast minut.

Czym różni się piramida testów od poziomów testowania ISTQB?

Poziomy testowania (jednostkowe, integracyjne, systemowe, akceptacyjne) mówią, kiedy i wobec czego testujemy. Piramida mówi, ile testów automatycznych opłaca się mieć na każdym poziomie. Poziomy to mapa, piramida to budżet.

Czy piramida testów nadal obowiązuje?

Tak, jako zasada „im wyżej, tym mniej”. Jej kształt zmienia się z architekturą: trofeum testowe w aplikacjach frontendowych kładzie nacisk na testy integracyjne komponentów, diament w mikroserwisach na testy kontraktowe i API. Żaden wariant nie zakłada dużo testów przez interfejs.

Jakie są techniki projektowania testów?

Czarnoskrzynkowe: klasy równoważności, wartości brzegowe, tablice decyzyjne, przejścia stanów, przypadki użycia. Białoskrzynkowe: pokrycie instrukcji i gałęzi. Oparte na doświadczeniu: zgadywanie błędów, testowanie eksploracyjne, listy kontrolne. Wybierają przypadki, które małą liczbą testów pokrywają duże ryzyko.

Jak dobrać technikę projektowania testów do warstwy piramidy?

Klasy równoważności, wartości brzegowe i pokrycie gałęzi do testów jednostkowych; tablice decyzyjne i przejścia stanów do testów integracyjnych i API; przypadki użycia do testów end to end; eksploracja do wszystkiego nowego. Ten sam przypadek na złej warstwie kosztuje wielokrotnie więcej.

Powiązane na blogu Quality Island

• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Testy end to end (E2E): co to jest, kiedy je uruchamiać i ile ich naprawdę potrzebujecie
• Testy regresyjne: co to jest, rodzaje, kiedy je uruchamiać i jak skrócić regresję z dni do godzin
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Testowanie manualne i automatyczne: jakie są różnice i kiedy wybrać każde podejście

Pełna lista źródeł

• Martin Fowler, TestPyramid oraz The Practical Test Pyramid
• Mike Cohn, Succeeding with Agile (2009) oraz The Forgotten Layer of the Test Automation Pyramid
• Google Testing Blog, Just Say No to More End-to-End Tests (2015), proporcja 70/20/10
• Kent C. Dodds, The Testing Trophy and Testing Classifications
• ISTQB Glossary, hasła test pyramid, equivalence partitioning, boundary value analysis, decision table testing, state transition testing, exploratory testing
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych