Dlaczego nazwana piramidą testów zapytasz? A dlaczego nie? Piramidy budowane były przez Majów, Inków, Egipcjan. Powodem ich budowy była chęć zbliżenia do bogów, pokazania bogactwa, siły. W piramidzie testów nazwa nie jest kojarzona z żadnym z tych powodów oczywiście, moim zdaniem chodzi tutaj o powiązanie faktu czasochłonności budowy poszczególnych elementów i ich wzajemnych zależności.
Łatwo jest ułożyć pierwszą warstwę piramidy, tak naprawdę tylko przesuwamy kamienie i układamy je obok siebie. Oczywiście nadal bierzemy pod uwagę położenia kamieni, właściwe ich wysokości i tak dalej, niemniej nadal można przyjąć, że jest to jeden z prostszych etapów, choć wielce istotny. Wszak pierwsza warstwa piramidy to podstawa, na której opierać ma się reszta budowli.
Każda kolejna warstwa jest trudniejsza, zajmuje więcej czasu, angażuje większą ilość rąk potrzebnych do położenia kolejnego kamyka. Co za tym idzie, rosną koszty, bo trzeba zrobić jakieś rusztowanie, pochylnie, wyciągi, przeciwwagi.
Czy widzisz już analogię do wytwarzania oprogramowania i jego testowania?
Na początku mamy unit testy, które są bazą i podstawą dla pozostałych składowych. Wraz z upływem czasu ilość osób zaangażowanych w projekt, w każdy znaleziony błąd rośnie. Proces staje się bardziej kosztowny i pracochłonny.
Piramida obrazuje zatem wyważenie ilości i rodzaju przeprowadzanych testów na danym etapie powstawania oprogramowania.
Jeszcze jedno skojarzenie nasuwa mi się z piramidą żywienia, poziom dolny „jedz, ile chcesz”, poziom środkowy „miej umiar”, poziom górny „możesz zjeść, bo to również jest potrzebne do życia, ale pomyśl, czy naprawdę warto przesadzać z ilością, i jakie to niesie za sobą konsekwencje”. Spójrz zatem na schemat piramidy testów.
No dobrze, ale o co chodzi w piramidzie testów?
Dlaczego testy jednostkowe są na samym dole?
Myślę, że po przeczytaniu mojego przydługiego wstępu, sprawa jest dla Ciebie prosta i oczywista. Testy jednostkowe są bardzo szybkie. Feedback po ich wykonaniu dostajemy natychmiast. Testy te są tanie w przygotowaniu i implementacji, na ogół są zautomatyzowane. Obejmują bardzo mały wycinek kodu, czasami zamykający się w jednej funkcjonalności, module, oderwany od innych składowych. W testach jednostkowych wykorzystujesz metody czarnoskrzynkowe, gdy weryfikujesz czy wymagania stawiane testowanemu modułowi są spełnione oraz białoskrzynkowe – sprawdzające / testujące wszystkie ścieżki w danym fragmencie kodu.
Głównym celem testów jednostkowych jest wykrycie ewentualnych błędów logicznych w danej implementacji. Naprawa znalezionego błędu jest szybka i nie wpływa na pozostałą część aplikacji.
Testy integracyjne stanowią kolejną warstwę piramidy testów.
W ramach tych testów sprawdzamy interface oraz interakcje między poszczególnymi modułami. Nasze interakcje mogą być wewnętrzne, pomiędzy poszczególnymi modułami wewnątrz aplikacji, albo zewnętrzne, np. z serwerem, chmurą, bazą danych.
Testy te mają za zadanie wychwycić błędy w komunikacji pomiędzy mającymi współpracować modułami. Mogą również wyłapywać błędy logiczne, które zostały przeoczone przy okazji testów jednostkowych.
Sprawdzamy tutaj pewną, zwykle większą część aplikacji, nierzadko cały system. Oczywiście lepiej ograniczyć się do kilku elementów tworzących wspólny moduł, realizujący poszczególne zadanie.
Testy te wymagają znajomości i zrozumienia większej części systemu. Zajmują zdecydowanie więcej czasu niż testy jednostkowe. Może i pojedynczy test trwa kilka sekund, ale cały zestaw może trwać więcej niż godzinę. W tym przypadku również można je automatyzować. Naprawa znalezionego błędu jest już obarczona większym ryzykiem pojawienia się kolejnego błędu, będącego wynikiem zmian w relacjach między modułami.
Na samej górze piramidy testów znajdują się testy akceptacyjne.
Spotkać się można również z określeniem systemowe, end to end (E2E). Testy te odbywają się na całej aplikacji, w środowisku produkcyjnym. Sprawdzamy przejścia przez wszystkie warstwy aplikacji. Weryfikujemy, czy spełnione zostały wszystkie wymagania wysokopoziomowe (czarnoskrzynkowe), oraz czy działają wszystkie scenariusze dla użytkownika końcowego. Głównym celem jest tu wyłapanie błędów współpracy pomiędzy poszczególnymi modułami, złej interpretacji wymagań stawianych aplikacji, czy też poprawności działania na środowisku produkcyjnym. Ze względu na wielkość i złożoność ciężko je zautomatyzować oraz utrzymywać. Są jednocześnie niezbędne, gdyż sprawdzają działanie całej, kompletnej aplikacji w docelowym środowisku użytkowym.
Piramida nie byłaby piramidą, gdyby pominąć jakiś etap.
Dlatego ważne jest, byś wiedział, że testy każdego poziomu są jednakowo ważne. Każdy rodzaj testów skupia się na wykrywaniu konkretnego, w każdym przypadku innego typu błędów, problemów oraz słabo radzi sobie z pozostałymi przypadkami.
Nie da się jednymi testami zastąpić drugich. To znaczy, da się, oczywiście, jednak koszt i nakład pracy będą ogromne, ekonomicznie nieuzasadnione.
Z ekonomicznego punktu widzenia najbardziej opłacalne jest tworzenie testów jednostkowych, które są łatwe do wykonania. Naprawa wykrytego błędu nie ingeruje w większą część kodu, co za tym idzie, nie powoduje możliwości powstania kolejnych błędów. Testy jednostkowe są zautomatyzowane. Aby sprawdzić działanie „sklejenia” ze sobą w całość kilku modułów i interakcji między nimi posługujemy się testami integracyjnymi. Na zakończenie, po złożeniu w całość naszej aplikacji i uruchomieniu jej w środowisku produkcyjnym, przeprowadzamy testy akceptacyjne. Wykonujemy je, by dostarczyć informacji o poprawności działania całej aplikacji oraz o jej jakości.
Piramidę testowania możemy oczywiście dość mocno rozbudowywać o kolejne warstwy, w zależności od potrzeb, i tak możemy mieć np.:
- testy eksploracyjne (staramy się „zepsuć” aplikację),
- testy penetracyjne (sprawdzamy luki bezpieczeństwa, podatność na włamanie, kradzież danych),
- testy wydajnościowe (sprawdzamy szybkość),
- testy wytrzymałościowe (sprawdzamy zachowanie pod dużym obciążeniem),
- testy kompatybilności (sprawdzamy poprawność funkcjonowania na różnych platformach).
Ile jakich testów powinniśmy wykonywać?
Można powiedzieć, że sztandarowym podziałem procentowym piramidy jest 60%, 30%, 10%. W momencie, gdy wprowadzamy kolejne poziomy, musimy uszczegóławiać nasze procenty, 40/30/20/10, 40/30/15/10/5 itd. w zależności od „ilości schodków” w naszej piramidzie.
Posługując się uproszczeniem, jeżeli w aplikacji masz 400 testów jednostkowych, 200 testów integracyjnych, i 250 testów akceptacyjnych to musisz mieć świadomość, że proporcje są zachwiane, należy przeanalizować wszystkie testy, zastanowić się, a na koniec wprowadzić konieczne i niezbędne poprawki.
Więc do czego jest ta piramida testów?
Wróćmy do mojego porównania do piramidy żywienia. Czy można 3 razy dziennie jeść frytki ociekające tłuszczem, popychać to burgerem, zapijać colą, a na deser wbić chipsika? Można, bo kto mi zabroni. Jednak patrząc na konsekwencje, którymi są:
- stałe i błyskawiczne przybieranie na wadze,
- konieczność ciągłego zmieniania ubrania, żeby kochane ciałko się w nim zmieściło,
- częste wizyty u lekarza, bo organizm przeciążony i niedomaga, leki, co dzień to więcej,
to wszystko pociąga za sobą przecież koszty, nie wspominając już nawet o dramatycznym pogorszeniu się JAKOŚCI naszego życia.
We wszystkim trzeba mieć umiar i nie zawsze więcej znaczy lepiej.
W testowaniu, jak w życiu, piramida jest obrazem proporcji pomiędzy różnymi rodzajami testów, Obrazuje zachowanie kosztów i czasu w zależności od danego poziomu testowania. Po prostu pomaga racjonalnie zarządzać testami.
