Droga do lepszego testowania Agile

Coroczny raport World Quality Report tworzony przez Capgemini pokazuje, że 42% respondentów ankiety wymienia „brak profesjonalnej wiedzy o testach” jako wyzwanie w stosowaniu testów w programowaniu Agile. Chociaż nadejście Agile przyniosło wzrost szybkości iteracji w rozwoju oprogramowania, w niektórych przypadkach odbywało się to kosztem jakości.

Ostra konkurencja zmusza zespoły do ​​ciągłego dostarczania nowych aktualizacji produktów, ale czasami wiąże się to z własnymi kosztami, w tym mniejszą uwagą poświęcaną testom. Niektórzy, jak Rob Mason, idą jeszcze dalej i twierdzą, że Agile zabija testowanie oprogramowania. Ostatnio Facebook zmienił swoje motto z „poruszaj się szybko i psuj rzeczy” na „poruszaj się szybko ze stabilną infrastrukturą”, próbując rozwiązać pokusę poświęcenia jakości.

Jak zatem można lepiej zintegrować testowanie z nowym światem tworzenia oprogramowania Agile? Testowanie zwinne.

Tradycyjne testowanie jest dość uciążliwe i zależy od dużej ilości dokumentacji. Testowanie zwinne to podejście do procesu testowania, które naśladuje zasady tworzenia oprogramowania zwinnego, zgodnie z którym:

• Testowanie odbywa się znacznie częściej,
• Testowanie opiera się w mniejszym stopniu na dokumentacji, a bardziej na współpracy członków zespołu oraz
• Niektóre czynności testowe są podejmowane nie tylko przez testerów, ale także przez programistów.

W ciągu ostatnich siedmiu lat przeniosłem wiele zespołów do testowania Agile i pracowałem ramię w ramię z testerami, aby pomóc ich procesom dopasować się do nowej metodologii. W tym artykule podzielę się niektórymi z najbardziej znaczących wskazówek, których nauczyłem się na swojej drodze do lepszego testowania Agile. Chociaż naturalne jest tarcie między szybkością a jakością w ramach praktyk Agile, w tym artykule omówimy kilka technik, które można wykorzystać do zwiększenia jakości testowania bez uszczerbku dla zwinności. Większość przedstawionych tu sugestii będzie wymagała zaangażowania zespołu, więc korzystne będzie zaangażowanie zarówno programistów, jak i testerów w planowanie.

Sformalizuj proces cyklu testowego wydania

Jednym z problemów związanych z testowaniem jest brak cyklu testowego wydania, brak harmonogramu wydania lub nieregularne żądania testowania. Żądania testów na żądanie utrudniają proces kontroli jakości, zwłaszcza jeśli testerzy obsługują wiele projektów.

Wiele zespołów wykonuje tylko jedną kompilację po każdym sprincie, co nie jest idealne w przypadku projektów zwinnych. Przejście na wydania raz w tygodniu może być korzystne, stopniowo przechodząc na wiele wersji tygodniowo. W idealnym przypadku kompilacje programistyczne i testowanie powinny odbywać się codziennie, co oznacza, że ​​programiści wypychają kod do repozytorium każdego dnia, a kompilacje mają być uruchamiane o określonej godzinie. Aby pójść o krok dalej, programiści będą mogli wdrażać nowy kod na żądanie. Aby to wdrożyć, zespoły mogą zastosować proces ciągłej integracji i ciągłego wdrażania (CI/CD). CI/CD ogranicza możliwość nieudanej kompilacji w dniu wydania głównego.

Po połączeniu CI/CD i automatyzacji testów możliwe jest wczesne wykrywanie krytycznych błędów, dzięki czemu programiści mają wystarczająco dużo czasu na naprawienie krytycznych błędów przed planowanym wydaniem klienta. Jedna z zasad Agile mówi, że działające oprogramowanie jest podstawową miarą postępu. W tym kontekście sformalizowany cykl wydawniczy sprawia, że ​​proces testowania jest bardziej elastyczny.

Wzmocnij testerów dzięki narzędziom do wdrażania

Jednym z typowych punktów tarcia podczas testowania jest wdrożenie kodu w środowisku pomostowym. Proces ten zależy od infrastruktury technicznej, na którą Twój zespół może nie mieć wpływu. Jeśli jednak istnieje pewna elastyczność, można utworzyć narzędzia dla osób nietechnicznych, takich jak testerzy lub menedżerowie projektów, które umożliwią im wdrożenie zaktualizowanej bazy kodu do samodzielnego testowania.

Na przykład w jednym z moich zespołów używaliśmy Git do kontroli wersji i Slacka do komunikacji. Twórcy stworzyli Slackbota, który miał dostęp do Gita, skryptów wdrożeniowych i jednej maszyny wirtualnej. Testerzy mogli pingować bota z nazwą gałęzi uzyskaną z GitHub lub Jira i wdrożyć go w środowisku pomostowym.

Ta konfiguracja uwolniła dużo czasu dla programistów, jednocześnie redukując marnotrawstwo komunikacji i ciągłe przerwy, gdy testerzy musieli prosić programistów o wdrożenie gałęzi do testowania.

Eksperymentuj z TDD i ATDD

Programowanie sterowane testami (TDD) to rodzaj procesu tworzenia oprogramowania, który kładzie duży nacisk na jakość. Tradycyjnie programista pisze kod, a następnie ktoś go testuje i zgłasza ewentualne błędy. W TDD programiści najpierw piszą testy jednostkowe, zanim jeszcze napiszą jakikolwiek kod, który uzupełniłby historyjkę użytkownika. Testy początkowo kończą się niepowodzeniem, dopóki programista nie napisze minimalnej ilości kodu, aby przejść testy. Następnie kod jest refaktoryzowany w celu spełnienia wymagań jakościowych zespołu.

Programowanie sterowane testami akceptacyjnymi (ATDD) opiera się na podobnej logice co TDD, ale, jak sama nazwa wskazuje, koncentruje się na testach akceptacyjnych. W takim przypadku testy akceptacyjne są tworzone przed rozwojem we współpracy z programistami, testerami i zleceniodawcą (klient, właściciel produktu, analityk biznesowy itp.). Testy te pomagają wszystkim członkom zespołu zrozumieć wymagania klienta, zanim zostanie napisany jakikolwiek kod.

Techniki takie jak TDD i ATDD sprawiają, że testowanie jest bardziej elastyczne, przenosząc procedury testowe na wczesne etapy cyklu rozwoju. Pisząc scenariusze testowe na wczesnym etapie, programiści muszą naprawdę dobrze zrozumieć wymagania. Minimalizuje to niepotrzebne tworzenie kodu, a także rozwiązuje wszelkie wątpliwości dotyczące produktu na początku cyklu rozwoju. Gdy pytania lub konflikty dotyczące produktów pojawiają się dopiero na późniejszych etapach, zwiększa się czas i koszty opracowywania.

Odkryj nieefektywności, śledząc ruch karty zadań

W jednym z moich zespołów mieliśmy programistę, który był niezwykle szybki, zwłaszcza z małymi funkcjami. Otrzymywał wiele komentarzy podczas przeglądu kodu, ale nasz mistrz Scrum i ja opisaliśmy to jako brak doświadczenia. Jednak gdy zaczął kodować bardziej złożone funkcje, problemy stały się bardziej widoczne. Opracował wzorzec przekazywania kodu do testowania, zanim był w pełni gotowy. Ten wzorzec zwykle pojawia się, gdy w procesie rozwoju brakuje przejrzystości — np. nie jest jasne, ile czasu różne osoby spędzają na danym zadaniu.

Czasami programiści spieszą się z pracą, próbując jak najszybciej udostępnić funkcje i „zlecić” jakość testerom. Taka konfiguracja tylko przesuwa wąskie gardło dalej w sprincie. Zapewnienie jakości (QA) jest najważniejszą siecią bezpieczeństwa, jaką dysponuje zespół, ale może to oznaczać, że istnienie QA daje programistom możliwość rezygnacji z rozważań dotyczących jakości.

Wiele nowoczesnych narzędzi do zarządzania projektami ma możliwość śledzenia ruchu kart zadań na tablicy Scrum lub Kanban. W naszym przypadku wykorzystaliśmy Jira do przeanalizowania, co stało się z zadaniami danego programisty i dokonaliśmy porównań z innymi programistami w zespole. Dowiedzieliśmy się, że:

• Jego zadania spędziły prawie dwa razy więcej czasu w kolumnie testowej naszej tablicy;
• Jego zadania znacznie częściej były zwracane z kontroli jakości za drugą lub trzecią rundę fixów.

Więc oprócz tego, że testerzy musieli spędzać więcej czasu na swoich zadaniach, musieli to robić wiele razy. Nasz nieprzejrzysty proces sprawiał wrażenie, jakby programista był naprawdę szybki; jednak okazało się to fałszywe, gdy wzięliśmy pod uwagę czas testowania. Przenoszenie historyjek użytkowników tam iz powrotem nie jest oczywiście podejściem lean.

Aby rozwiązać ten problem, zaczęliśmy od szczerej dyskusji z tym deweloperem. W naszym przypadku po prostu nie zdawał sobie sprawy z tego, jak szkodliwy był jego tryb pracy. W ten sposób przyzwyczaił się do pracy w swojej poprzedniej firmie, która miała niższe wymagania jakościowe i większą pulę testerów. Po naszej rozmowie i przy pomocy kilku sesji programowania w parach z naszym mistrzem Scrum, stopniowo przechodził do wyższej jakości podejścia do programowania. Ze względu na swoje umiejętności szybkiego kodowania nadal był bardzo wydajny, ale usunięte „marnotrawstwo” procesu kontroli jakości sprawiło, że cały proces testowania był znacznie bardziej zwinny.

Dodaj automatyzację testów do zestawu umiejętności zespołu QA

Testowanie w projektach niezwinnych obejmuje czynności takie jak analiza testów, projektowanie testów i wykonywanie testów. Czynności te są sekwencyjne i wymagają obszernej dokumentacji. Kiedy firma przechodzi na Agile, najczęściej przejście skupia się głównie na programistach, a nie na testerach. Przestają tworzyć obszerną dokumentację (filar tradycyjnego testowania), ale nadal wykonują testy ręczne. Jednak testowanie ręczne jest powolne i zazwyczaj nie radzi sobie z szybkimi pętlami sprzężenia zwrotnego Agile.

Popularnym rozwiązaniem tego problemu jest automatyzacja testów. Testy automatyczne znacznie ułatwiają testowanie nowych i małych funkcji, ponieważ kod testowy może działać w tle, podczas gdy programiści i testerzy skupiają się na innych zadaniach. Co więcej, ponieważ testy są uruchamiane automatycznie, pokrycie testami może być znacznie większe w porównaniu do testów ręcznych.

Testy automatyczne to fragmenty kodu oprogramowania podobne do testowanej bazy kodu. Oznacza to, że osoby piszące testy automatyczne będą potrzebowały umiejętności technicznych, aby odnieść sukces. Istnieje wiele różnych wariantów implementacji testów automatycznych w różnych zespołach. Czasami sami programiści przejmują rolę testerów i powiększają bazę kodu testowego z każdą nową funkcją. W innych zespołach testerzy manualni uczą się korzystać z narzędzi do automatyzacji testów lub zatrudniany jest doświadczony tester techniczny do automatyzacji procesu testowania. Niezależnie od tego, jaką ścieżkę wybierze zespół, automatyzacja prowadzi do znacznie sprawniejszego testowania.

Zarządzaj priorytetami testowania

W przypadku tworzenia oprogramowania niezwinnego testerzy są zwykle przydzielani na podstawie projektu. Jednak wraz z pojawieniem się Agile i Scrum stało się powszechne, że ci sami specjaliści ds. kontroli jakości działają w wielu projektach. Ta nakładająca się odpowiedzialność może powodować konflikty w harmonogramach i prowadzić do tego, że testerzy nie biorą udziału w krytycznych ceremoniach, gdy tester traktuje priorytetowo testy wersji jednego zespołu przed sesją planowania sprintu innego zespołu.

Powód, dla którego testerzy czasami pracują nad wieloma projektami, jest oczywisty — rzadko istnieje stały przepływ zadań, aby testerzy mogli pełnić pełnoetatową rolę. W związku z tym może być trudno przekonać interesariuszy do posiadania dedykowanego zasobu testowego przydzielonego zespołowi. Istnieją jednak pewne rozsądne zadania, które tester może wykonać, aby wypełnić swój przestój, gdy nie angażuje się w czynności testowe.

Wsparcie klienta

Jedną z możliwych konfiguracji jest, aby tester spędził swój czas przestoju, pomagając zespołowi wsparcia klienta. Poprzez ciągłe stawianie czoła problemom, które mają klienci, tester lepiej rozumie wrażenia użytkownika i jak je ulepszyć. Mogą wnieść swój wkład w dyskusje podczas sesji planowania. Co więcej, stają się bardziej uważni podczas czynności testowych, ponieważ są lepiej zaznajomieni z tym, w jaki sposób klienci faktycznie korzystają z ich oprogramowania.

Zarządzanie produktem

Inną techniką zarządzania priorytetami testerów jest zasadniczo uczynienie ich młodszymi menedżerami produktu, którzy przeprowadzają testy ręczne. Jest to również opłacalne rozwiązanie wypełniania czasu wolnego testera, ponieważ młodsi menedżerowie produktu spędzają dużo czasu na tworzeniu wymagań dla historyjek użytkowników, a zatem mają gruntowną wiedzę na temat większości zadań.

Automatyzacja testów

Jak już wcześniej wspomnieliśmy, testowanie ręczne jest często gorsze od automatyzacji. W tym kontekście dążenie do automatyzacji może być połączone z tym, aby tester poświęcił całą swoją uwagę zespołowi i wykorzystał swój wolny czas na naukę do pracy z narzędziami do automatyzacji testów, takimi jak Selenium.

Podsumowanie: Zwinne testowanie jakości

Sprawienie, by testowanie stało się bardziej zwinne, jest nieuniknioną kwestią, z którą boryka się obecnie wiele zespołów programistycznych. Jednak jakość nie powinna być zagrożona przez przyjęcie nastawienia „test tak szybko, jak to tylko możliwe”. Konieczne jest, aby przejście Agile obejmowało przejście na testowanie Agile i istnieje kilka sposobów, aby to osiągnąć:

• Sformalizuj proces cyklu testowania wydania.
• Zapewnij testerom narzędzia do wdrażania.
• Eksperymentuj z programowaniem sterowanym testami i programowaniem opartym na testach akceptacyjnych.
• Odkryj nieefektywności, śledząc ruch karty zadań.
• Dodaj automatyzację testów do umiejętności zespołu QA.
• Zarządzaj priorytetami testerów.

Z roku na rok oprogramowanie staje się coraz lepsze, a oczekiwania użytkowników rosną. Co więcej, ponieważ klienci przyzwyczajają się do wysokiej jakości produktów czołowych marek oprogramowania, takich jak Google, Apple i Facebook, te oczekiwania przenoszą się również na inne produkty programistyczne. Dlatego w nadchodzących latach nacisk na jakość będzie prawdopodobnie jeszcze ważniejszy. Te testy i ogólne ulepszenia procesu rozwoju mogą sprawić, że testowanie stanie się bardziej sprawne i zapewnić wysoki poziom jakości produktu.