Smutne jest, że (nie tak młoda już) branża IT nie wykształciła jak dotąd standardowego, spójnego podejścia do roli testera oprogramowania. Co kraj, to obyczaj – w każdej firmie czy projekcie QA pracuje inaczej bądź… nie pracuje wcale. Niektórzy wciąż przecież twierdzą, że Scrum z QA nie ma racji bytu. Ma, o ile na etapie budowy zespołu unikniemy kilku pułapek.
Pułapka #1 „W Scrumie nie ma testerów”
Przewodnik po Scrumie głosi:
W skład Scrum Teamu wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy. (…) Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności
Scrum Guide
potrzebne do wytwarzania wartości co Sprint.
Czy oznacza to, że Scrum z QA to twór przeczący zasadom Scrum Guide’a? Wręcz przeciwnie! Przede wszystkim określenie „developer” odnosi się tu do wszystkich wykonawczych funkcji w interdyscyplinarnym zespole, niezależnie od specjalizacji. I tak programiści, DevOpsi, testerzy, analitycy, projektanci UX itd. to z punktu widzenia Scrum Guide’a po prostu developerzy (ciut więcej o testerach w Scrumie na testerzy.pl).
A co na to Agile’owi eksperci?
- Lizzy Morris, współautorka książki „Agile Transformation: Using the Integral Agile Transformation Framework to Think and Lead Differently”, stwierdza, że testerzy powinni być integralną częścią zespołu deweloperskiego,
- Lisa Crispin i Janet Gregory, autorki książek „Agile Testing” i „More Agile Testing”, podkreślają, że kluczową koncepcją w Scrumie jest wielofunkcyjność. Testerzy nie są wyizolowaną rolą, ale pełnoprawnymi członkami zespołu, którzy przyczyniają się do tworzenia wartości.
Pułapka #2 „Jeden QA wystarczy”
OK, zgodziliśmy się, że powinniśmy mieć testera w naszym zespole. No właśnie, testera. Bo jeden wystarczy, prawda?
Nie… (zazwyczaj) nie wystarczy. Biznes, który często nie rozumie roli Quality Assurance w projekcie, będzie próbował ograniczyć jego liczebność do absolutnego minimum – w myśl zasady „więcej developmentu!”. Jednak o tym ilu specjalistów QA umieścić w naszym zespole powinien zdecydować nie biznes, a kilka czynników:
- wielkość i doświadczenie zespołu,
- złożoność produktu i projektu,
- strategia testowania,
- liczba i rodzaj zadań QA.
Właściwe ratio QA:Dev w zespole
Eksperci podkreślają, że ze względu na czynniki powyżej, nie istnieje jedna, wzorcowa struktura zespołu Scrum z QA. W przypadku większości interdyscyplinarnych zespołów Agile, zdrowym ratio QA:Dev będzie 1:2 – 1:3 (jeden tester przypadający na dwóch-trzech developerów). Taki układ sił pozwala na bieżące testy produktów sprintu oraz wytwarzanie i utrzymywanie niezbędnych testów automatycznych.
Oczywiście w praktyce występują również inne rozwiązania, np.:
- 1:1 (Microsoft) – w przypadku testowania systemów tzw. wysokiej niezawodności (np. związanych z bezpieczeństwem). Co ciekawe, ta sama firma – Microsoft – stosuje różne struktury zespołów (1:1-1:5) pracując nad różnymi produktami, o różnym stopniu złożoności i ryzyka.
- 1:4 (Spotify) – gdzie zespoły dążą do wysokiego stopnia automatyzacji, obniżając przy tym zapotrzebowanie na testy manualne (w automatyzację testów zaangażowani są także developerzy).
Przyjmując wskaźnik 1:2-1:3 za standard, ośmioosobowy zespół Scrum powinien przyjąć następującą strukturę:
a) 5 x DEV, 3 x QA
b) 6 x DEV, 2 x QA
Pułapka #3 „Testy automatyczne to strata czasu i pieniędzy”
Aż trzech testerów w jednym zespole scrumowym? Do klikania po aplikacji?
Otóż nie. Współczesne testowanie oprogramowania nie polega (wyłącznie) na manualnej weryfikacji poprawności działania. Stan aplikacji powinny kontrolować testy automatyczne, których wykonaniem i utrzymywaniem przeważnie zajmują się właśnie specjaliści Quality Assurance.
Wdrożenie i późniejsze rozwijanie testów automatycznych jest oczywiście kosztowne, stąd część firm nie decyduje się na ich implementację. Według dogq.io do roku 2023 jedynie 33% organizacji testowało swoje oprogramowanie w sposób zautomatyzowany. To niewiele, zważywszy na długofalowe oszczędności i korzyści płynące z ograniczenia testów manualnych na rzecz automatów. Aż 60% firm deklaruje satysfakcjonującą stopę zwrotu w inwestycji w testy automatyczne, podkreślając ich efektywność kosztową oraz ogromny, pozytywny wpływ na jakość budowanych produktów.
Co z pozostałymi 40%? Cóż, testy automatyczne same w sobie jeszcze nic nie dają. Jeśli automatyzowane są niewłaściwe przypadki testowe, albo zespół nie robi z nich właściwego użytku (np. nie uruchamia ich cyklicznie ani nie wyłapuje nieprawidłowości na ich podstawie) wówczas rzeczywiście, tego typu inwestycja nie przyniesie korzyści.
Według Martina Fowlera, autora książki "Refactoring: Improving the Design of Existing Code" automatyzacja testów jest kluczowa dla efektywności zespołów zwinnych. Pomaga ona szybko i efektywnie testować kod, co jest krytyczne w krótkich iteracjach typowych dla Scruma.
Pułapka #4 „Za testy odpowiadają testerzy”
Właściwa struktura zespołu i automatyzacja pracy to nie jedyne czynniki, o które musimy zadbać łącząc Scrum z QA. Aby zbudować efektywny team, równie ważne jest odpowiednie zaprojektowanie procesu – efektywnego przepływu pracy, w którym testerzy i developerzy są współodpowiedzialni za cel sprintu (zwykle konkretny przyrost funkcjonalności tworzonego produktu).
Cały zespół deweloperski jest odpowiedzialny za jakość. Testerzy w Scrumie wnoszą swoje umiejętności do zapewnienia, że produkt spełnia wymagania jakościowe, ale nie są jedynymi odpowiedzialnymi za testowanie. Programiści również są odpowiedzialni za pisanie testów jednostkowych, integracyjnych i innych form testów automatycznych.
Mike Cohn, „Succeeding with Agile: Software Development Using Scrum”
Testerzy powinni stanowić integralną część zespołu i procesu developerskiego. Nie zajmować się jedynie testami tego, co napiszą programiści (nie daj Boże w kolejnym sprincie), a aktywnie współtworzyć produkt – m.in. współpracując z Product Ownerem przy zarządzaniu Product Backlogiem, uczestnicząc w procesie jego refinementu i projektowaniu rozwiązań.
W Scrumie tester to nie „mniej techniczny developer”, który testuje, bo nie nauczył się programować. Współczesny QA to specjalista w swojej dziedzinie, o ukierunkowanych kompetencjach technicznych i biznesowych. Nie zapominajmy o nich budując zwinny, interdyscyplinarny zespół projektowy.