Wieża testów

Dlatego zamiast piramidy coraz częściej możemy spotkać się z nową metaforą: Testing Tower, czyli Wieża testów.

Dlaczego wieża?

Piramida czy diament próbowały uporządkować testowanie, ale zawsze sprowadzały je do jednego kształtu i proporcji. Wieża działa inaczej, pokazuje, że każdy zespół może zbudować własną wersję, dopasowaną do kontekstu projektu. Piramida ma być w tej formule statyczna, podczas gdy wieża może być elastyczna i różnorodna np. smukła i wysoka (w sensie wysoko zautomatyzowana); może być też masywna, z silnym naciskiem na testy eksploracyjne. Jedno jest pewne: próba odwrócenia wieży spowoduje, że się zawali. 

Fundamenty. Testy szybkie i powtarzalne 

Podstawa każdej wieży to testy, które dają największy zwrot przy najmniejszym koszcie. To one uruchamiane są przy każdej zmianie w kodzie i trzymają cały system w ryzach. Zaliczamy do nich testy jednostkowe (sprawdzające logikę w izolacji), testy dymne (smoke testy, które błyskawicznie potwierdzają, że system w ogóle działa po wdrożeniu) i regresję automatyczną (która chroni przez powracającymi błędami). Bez takiego gruntu żadna konstrukcja nie utrzyma się długo. 

Trzon wieży. Komunikacja

Kiedy system składa się z wielu mikroserwisów, problemem staje się komunikacja. Tutaj wchodzą w grę testy kontraktowe, które są lekkie, szybkie i skuteczne. Dzięki nim można sprawdzić, czy serwisy dogadują się ze sobą bez konieczności uruchamiania całego, ciężkiego środowiska integracyjnego. 

Warstwa systemów. Realne interakcje

To poziom, na którym zaczyna być widoczne prawdziwe zachowanie aplikacji. Znajdziemy tu testy komponentowe, które badają usługę z kontrolowanymi zależnościami i testy integracyjne, które sprawdzają faktyczne połączenia z bazami danych, kolejkami czy zewnętrznymi API. Takie testy są wolniejsze i droższe, ale nie da się ich pominąć. To na tym etapie najczęściej ujawniają się błędy, które trudno jest wykryć niżej. 

Pokład obserwacyjny

Nie wszystkie testy muszą być uruchamiane na każdą zmianę. Niektóre mają sens dopiero na etapie stabilizacji czy tuż przed produkcją. To właśnie poziom, gdzie pojawiają się testy wydajnościowe i obciążeniowe, chaos engineering, testy end-to-end i testy funkcjonalne w podejściu BDD. Można je traktować jak okna w wieży. Dają szerszą perspektywę, pozwalają zobaczyć, jak system działa w całości. 

Szczyt wieży

Na najwyższym poziomie są testy, których nie zastąpi żadna automatyzacja: użyteczności i dostępności (sprawdzające, czy produkt jest intuicyjny i dopasowany do osób ze szczególnymi potrzebami), eksploracyjne (odsłaniające nieoczekiwane scenariusze) i akceptacyjne (potwierdzające zgodność z wymaganiami biznesu). Są one jak strażnicy na murach. Nie pracują bez przerwy, ale są nieocenione w najważniejszych momentach. 

Jak korzystać z wieży?

Zamiast traktować wieżę jako schemat do ślepego kopiowania, warto spojrzeć na nią jak na sposób myślenia i dobierać testy pod kątem wartości, a nie mody, dopasowywać strategię do fazy życia produktu i pamiętać, że nie wszystko musi być testowane zawsze i wszędzie. 

Wieża podpowiada, że testowanie to proces dynamiczny i kontekstowy. W startupie może być bardziej automatyczna, w przypadku systemu krytycznego bardziej konserwatywna, ale zawsze powinna mieć mocne fundamenty i spójne dobrane poziomy.