W zeszłym tygodniu szef poprosił o krótkie spotkanie z jednym z zespołów projektowych w celu znalezienia rozwiązań które poprawi jakość w projekcie. Przedstawił problem, następnie zapytał jakie mamy możliwości tzn. co zespół może zrobić aby działo się lepiej, oczywiście podczas spotkania ustalono kilka kroków naprawczych ale spotkanie było dla mnie jednocześnie inspiracją do nieco szerszego przyjrzenia się problemowi zapewniania jakości w projektach zwinnych. Wobec powyższego problemu w tytule posta pojawia się ciekawe połączenie, piramida testów agile. Co to jest właściwie? Spróbuje rozwinąć temat na tyle aby dam odpowiedzieć na to pytanie…

Jednym z potencjalnych rozwiązań które padło podczas spotkania była piramida testów agile i co za tym idzie potrzeba szerokiej automatyzacji testów na wszystkich poziomach, począwszy od poziomu testów jednostkowych backendu a skończywszy na automatyzacji interfejsu użytkownika, oczywiście w granicach wykonalności. Skoro piramida to można się domyślać, że model kształtem musi przypominać trójkąt, otóż to! Pomagając zrozumieć Wam idee kryjącą się za tym chciałbym zacząć od opisu klasycznej piramidy testów. 

W podejściu tradycyjnym znacząca większość, o ile nie wszystkie testy są tworzone w oparciu o graficzny interfejs użytkownika aplikacji. Zespół a zdecydowanie wśród nich testerzy mając namacalny wycinek produktu przystępują dopiero do definiowania, budowania i egzekucji testów. Czasem idą krok dalej, próbują automatyzować czasochłonne testy dotykając warstw pośrednich a nawet prosząc developerów o automatyczne testy jednostkowe rdzennych funkcji systemu. Klasyczne rozwiązanie ilustruje poniższy rysunek.

Pierwsze co przychodzi do głowy to pytanie dlaczego tak?

Odpowiedź nie zawsze jest jednoznaczna. Domyślam się, że może to wynikać z kilku powodów, między innymi braku odpowiednich zasobów, umiejętności czy generalnie podejścia do testów gdzie testerzy poruszają się w swojej strefę komfortu nakierowanej w dużym stopniu na testy funkcjonalnie w oparciu o GUI. Z kolei programiści którzy potencjalnie mogą rozpocząć automatyzacje testów na poziomie jednostkowym nie są tym zainteresowani, często nie widząc w tym sensu. Z ich perspektywy wysiłek włożony w  pisanie testów nie jest opłacalny… Na końcu łańcucha pokarmowego jest oczywiście biznes, który zawsze chce mieć szybko dostarczane nowe funkcjonalności. Osoby reprezentujące biznes często nie zdają sobie sprawy z ważności testów lub świadomie odkładają czynności testowe na jak najdalsze etapy projektu, co jest w mojej opinii błędem. 
Jak pokazało życie, model klasyczny nie zawsze się sprawdzał dlatego razem z nastaniem ery podejść zwinnych nie trzeba było czekać na nowe rozwiązania dedykowane testom, bardziej responsywne na realia otaczające projekt. Świadomie rezygnując z automatyzacji lub opierając ją w całości na interfejsie użytkownika narażamy się na ciągle zmiany na wskroś aplikacji powodowane li tylko zmianami w GUI. Co przekłada się na regułę,gdzie dużo zmian GUI równa się dużemu wysiłkowi związanemu z utrzymaniem testów.  Myślę, że już powoli widzicie co za tym idzie, zespołowi może zwyczajnie zabraknąć czasu na dopięciem wszystkich prac związanych z zaplanowanymi testami na ostatni guzik przed upływem deadline, tak niestety bywa…. Co wtedy zazwyczaj przysłowiowo „obcinamy rogi” naszych procesów aby się zmieściły. Dlatego znany w środowisku podejść zwinnych, Mike Cohn, zaproponował w kontekście automatyzacji testów w ramach projektów zwinnych nowy model piramidy testów agile.
Jak widać, mam nadzieje że widzicie, zmiana jest znacząca. Model proponuje dogłębną automatyzację testów na wszystkich poziomach począwszy od poziomu testów jednostkowym gdzie proponuje się pokrycie nawet do 99% kodu poprzez odpowiednio proporcjonalnie wartości w % na kolejnych poziomach idąc ku górze piramidy.  Równocześnie, choć ograniczone zostawia miejsce na testy manualne, zazwyczaj niemożliwe do automatyzacji testy UI oraz wysublimowane testy  eksploracyjne (funkcjonalne i niefunkcjonalne). Kolejna zmiana nie widoczna bezpośrednio na modelu ale wspierająca go to struktura zespołów zwinnych, członkowie zespołów zwinnych nie mają nadawanych ról projektowych, co oznacza, że nie  tylko testerzy są odpowiedzialni za testy, za jakość produktu ale cały zespół… Bardzo liczy się tutaj współpraca i komunikacja pomiędzy osobami o dominujących umiejętnościach testerskich a programistycznych. Osoby znające  sztukę programowania często biorą na swoje barki pisanie testów jednostkowych w postaci junit, nunit czy ngunit, a automatyzacją testów wyższych poziomów piramidy (np. integracyjne, mogą być wspierane przez koncepcje ATDD/BDD, warstwy interfejsu graficznego czy eksploracyjne całości) są wykonywane bardziej przez testerów. Dodatkowo jak widzicie nie wystarczy mieć już jedno narzędzie, jedno podejście do testów tak jak było kiedyś, tutaj również liczy się zwinność całego zespołu 🙂
Zapytacie o korzyści płynące z zastosowania piramidy testów agile, a ja odpowiem, że są znaczące. Przejawia się to w samej koncepcji gdzie stawiając na rozbudowane testów jednostkowe na najniższym levelu stawiamy na prewencje powstawania błędów zamiast skazywania się na późniejsze szukanie ich na wyższych poziomach. Domyślam się, że doskonale wiecie ile kosztuje błąd znaleziony na wczesnych etapach cyklu życia oprogramowania względem błędu zgłoszonego na późnych etapach lub na produkcji. Dlatego piramida stawia testy jednostkowe za najważniejsze, sa najobszerniejsze, bo dają szybko szeroki obraz całości. Parafrazując członkowie zespołów zwinnych powinni rozpoczynać dzień od przeglądu rezultatów wszystkich testów automatycznych i poprawek błędów zanim wezmą się za nowe zadania.  Nie chcemy przecież nadbudowywać nowych rozwiązań na nie w pełni działającym kodzie…. 
Kolejna korzyść to łatwy rozwój i stosunkowo łatwo utrzymywać testów, również  to powinno być zadaniem całego zespołu. Dodatkowo aby nadać odpowiednią rangę czynnościom testowym można poprzeć to odpowiednimi wpisami w definicji ukończenia gdzie będzie zapis np. każdy item musi być pokryty testami automatycznymi – mrzonka? nie, są zespoły które w ten sposób pracują…  Co więcej model proponuje pokrycie testami większości produktu, zarówno od strony frontendu i backendu aplikacji. 
Nie zapominajmy tu o innym, ważnym problemie. W miarę rozwoju projektu w ramach kolejnych iteracji nasz przyrost produktu a co za tym idzie ilość testów rośnie nieliniowo. Jeśli strategia testów przyjęta na początku jest konsekwentnie realizowana jesteśmy w domu, jeśli nie możemy skończyć z kopytkami w górze jak koń próbujący uciągnąć wóz na który włożono niemożliwy do przewiezienia towar, w przypadku projektów zwinnych nazywa się to długiem technicznym/technologicznym.