Przywództwo w testowaniu: testowanie jako zespół

W ostatnich latach odpowiedzialność za testowanie stała się bardziej rozproszona. Zamiast dedykowanych zespołów odpowiedzialnych za testowanie, zespoły zachęcają obecnie użytkowników, analityków, programistów i testerów do dzielenia się odpowiedzialnością za testowanie, aby wspierać lepszą współpracę. W związku z tym niektóre działania i obowiązki związane z testowaniem są przesuwane w lewo.

W tym artykule omówię:

• Przesunięcie w lewo
• Testowanie jako działanie, a nie rola
• Nowa rola
• Interwencje testowe w podejściu zwinnym
• Relacje z programistami
• Wyzwania związane z zespołami rozproszonymi i zewnętrznymi

Wprowadzenie do przesunięcia w lewo

Przesunięcie w lewo może odnosić się do kilku różnych scenariuszy. Może oznaczać, że programiści przejmują większą odpowiedzialność za własne testowanie. Może również oznaczać, że testerzy angażują się w projekt na wcześniejszym etapie, kwestionują wymagania i przekazują programistom przykłady w ramach procesu rozwoju sterowanego zachowaniem (BDD). 

Czasami może to oznaczać całkowity brak testerów (ta-dam-daaa), a pełną odpowiedzialność za testowanie przejmują analitycy biznesowi i programiści.

Przesunięcie w lewo nie jest nowym pomysłem — propagatorzy testowania od wielu lat głoszą zasadę „testuj wcześnie, testuj często”. Już w 1993 roku sugerowano, że wszystkie artefakty w procesie etapowym — zarówno dokumentacyjne, jak i programowe — można (i często należy) testować.

Przesunięcie w lewo polega głównie na wcześniejszym uwzględnieniu myślenia o testowaniu w procesie.

Chociaż w tamtym czasie dominującym podejściem do cyklu życia był model kaskadowy, liczba etapów ani ich czas trwania nie są najważniejsze. Podstawowa zasada głosiła, że źródła wiedzy wyznaczające kierunek projektowania i tworzenia oprogramowania powinny być kwestionowane lub testowane. 

W projekcie etapowym może to obejmować formalne przeglądy. W projekcie zwinnym tester (lub programista, analityk biznesowy czy użytkownik) może zaproponować scenariusze, które skłonią autora wymagania lub historyjki do przeanalizowania konkretnych przykładów i omówienia ich przed napisaniem jakiegokolwiek kodu.

Oto najważniejsze zmiany związane ze zjawiskiem przesunięcia w lewo:

1. Podejście oparte na rozwoju sterowanym zachowaniem (BDD) umożliwiło programistom, użytkownikom/analitykom biznesowym i testerom współpracę wokół tego, co można nazwać historyjkami biznesowymi. Rozwój sterowany testami jest wykorzystywany przez wielu programistów od co najmniej 15 lat. Obecnie BDD jest wdrażane na szerszą skalę, ponieważ zachęca do lepszej współpracy w zespołach zwinnych, a także wprowadza narzędzia BDD, z których mogą korzystać programiści. Jest to łatwiejsze podejście oparte na zasadzie „testowanie najpierw”.
2. Dostarczanie ciągłe (CD) jest obecne od 5–10 lat, a jego korzenie tkwią w wysoce zautomatyzowanych podejściach do budowania i wydawania oprogramowania, rozwijanych przez duże firmy internetowe. Obecnie jest wdrażane przez większość organizacji posiadających obecność w internecie.
3. CD usystematyzowało i przyspieszyło proces wydawania oprogramowania dzięki automatyzacji. Uwydatniło jednak również opóźnienia w produkcji, wdrażaniu i zmianach infrastruktury, które wcześniej były maskowane przez powolne procesy budowania, testowania i wydawania. DevOps to zmiana kulturowego sposobu myślenia, w ramach której programiści znacznie ściślej współpracują z pracownikami operacyjnymi. Obecnie niemal codziennie pojawiają się nowe narzędzia, a dostawcy promują DevOps jako „kolejną wielką rzecz”. Jest to bardzo nagłośniona i dynamiczna sytuacja.
4. SMAC, czyli media społecznościowe, urządzenia mobilne, analityka i chmura, oznacza zmianę sposobu, w jaki organizacje zarządzają zmianami biznesowymi i systemowymi w środowisku mobilnym. Eksperymenty biznesowe wdrażane jako zmiany w systemach produkcyjnych są monitorowane na szczegółowym poziomie. Przechwycone „duże” dane są przetwarzane, a decyzje biznesowe podejmowane na podstawie uzyskanych analiz.

Częste eksperymentowanie z systemami produkcyjnymi umożliwia innowacje biznesowe „w tempie marketingu”. Eksperymentowanie stanowi sedno tego, co było najważniejszym trendem drugiej dekady XXI wieku — transformacji cyfrowej.

Testowanie jako działanie, a nie rola

Przesunięcie w lewo zmienia rolę testerów. Redystrybucja testowania wywołana podejściem przesunięcia w lewo jasno pokazuje, że testerzy nie ponoszą wyłącznej odpowiedzialności za testowanie, tzn. testowanie nie należy już tylko do testerów. 

Jeśli się nad tym zastanowić, testerzy nigdy tak naprawdę nie byli właścicielami testów, ale w projektach istniało milczące porozumienie, że niezależnie od tego, co w ramach testowania robiła reszta zespołu, a w szczególności deweloperzy, testerzy zapewniali siatkę bezpieczeństwa. Jeśli deweloperzy byli pod presją czasu i ograniczali zakres testów, aby dostarczyć rozwiązanie, siatkę bezpieczeństwa zapewniali testerzy.

Testowanie jest teraz działaniem, a nie rolą.

Deweloperzy stosują lepsze praktyki testowania i zapewniają większą widoczność swojej pracy. Dobre testy na poziomie komponentów lub testy jednostkowe mają określone cele, odrębne od celów testowania systemu (to tylko przykład). Dlatego zakres (lub ilość) testów na poziomie systemu może zostać ograniczony. 

Właściwe rozłożenie celów testowania oraz testów służących do ich osiągnięcia jest głównym celem strategii testów. Niestety do niedawna deweloperzy nie byli skutecznie rozliczani ze swojej odpowiedzialności, dlatego polegali na późnym testowaniu systemu jako środku zaradczym.

Podejście shift-left zwiększa odpowiedzialność deweloperów.

Ogólnie rzecz biorąc, odpowiedzialność za testowanie zostaje rozdzielona na nowo, przez co zmienia się rola testera. Testerzy mogą wykonywać mniej testów taktycznych, ale ich wkład strategiczny wzrasta. Testerzy mogą być właścicielami strategii testów, kwestionować wymagania, konsultować się z interesariuszami i nawiązywać bliższą współpracę z deweloperami, aby wspierać lepsze testowanie przez deweloperów oraz automatyzację testów.

Nowa rola

Przesunięcie testów w lewo oznacza, że zawsze, gdy możliwe jest przekazanie informacji zwrotnej, która pomoże zespołowi zrozumieć, zakwestionować i udoskonalić cele, wymagania, projekt lub implementację – należy ją przekazać. 

Użytkownicy, BA, deweloperzy i cały zespół programistyczny powinni być gotowi do wymiany informacji zwrotnej w ten sposób. Czasami pojawia się opór, ale ogólnym celem jest prowadzenie lepszego, bardziej świadomego projektu — i tylko o to chodzi.

Najłatwiej podsumować to zachowanie słowami: „zaangażuj się wcześnie” — tak wcześnie, jak to możliwe. Włączaj się do dyskusji i współpracuj nad pomysłami, wymaganiami oraz na każdym etapie, na którym wynik danego etapu wpływa na wartość końcowego produktu projektu. 

Mówiąc prosto, tester kwestionuje źródła wiedzy, niezależnie od tego, czy są nimi interesariusze, użytkownicy, deweloperzy, historyjki biznesowe, dokumenty czy wcześniejsze rozwiązania.

Najczęściej stosowanym podejściem jest kwestionowanie za pomocą przykładów. Na wszystkich etapach przykłady te można traktować jako testy. Mogą zostać szybko odrzucone po użyciu albo skodyfikowane w ramach automatyzacji testów lub kontroli manualnych. Przykłady te mogą służyć wyłącznie taktycznie do wskazywania błędów w rozumowaniu ludzi albo mogą zostać przekazane deweloperom jako pomysły lub zalążki testów deweloperskich. Mogą również służyć jako pomoc szkoleniowa, pokazując użytkownikom lub deweloperom, jak tworzyć lepsze testy.

Potraktuj swój projekt programistyczny jako proces zdobywania wiedzy. Wiedza ta jest gromadzona przez cały projekt i często ewoluuje z czasem. Celem podejścia polegającego na przesunięciu testów w lewo jest zapewnienie wiarygodności tej wiedzy poprzez kwestionowanie i testowanie w pobliżu jej źródła, a także zapewnienie, wszędzie tam, gdzie jest to możliwe, że wiedza ta zostanie uznana za wiarygodną, zanim zostanie utrwalona w kodzie.

Przesunięcie testów w lewo rozwija filozofię testowania od pierwszej chwili. Metodyka zwinna od zawsze promowała współpracę i szybką informację zwrotną — przesunięcie testów w lewo można postrzegać jako skoordynowane podejście oparte na szybkiej informacji zwrotnej. Jeśli Twój zespół przyjmuje podejście polegające na przesunięciu testów w lewo do testowania, odpowiednie narzędzia mogą mieć ogromne znaczenie. Zapoznaj się z naszą wyselekcjonowaną listą narzędzi do testowania oprogramowania, aby znaleźć rozwiązanie najlepiej dopasowane do Twojego zespołu.

Interwencje testowe w Agile

Podejście polegające na przesunięciu testów w lewo ma fundamentalne znaczenie dla strategii testów w projektach zwinnych. W kontekście metodyki zwinnej strategię testów można postrzegać jako serię interwencji testowych. We wszystkich projektach występują kluczowe momenty, w których pojawiają się możliwości gromadzenia i przekazywania informacji zwrotnej. Tester musi koncentrować się na tych kluczowych momentach i być gotowy do wniesienia swojego wkładu w odpowiednim czasie.

W swoich projektach musisz zidentyfikować kluczowe momenty, w których możliwa jest interwencja, oraz określić wybory, jakich możesz dokonać podczas testowania jako zespół. Czy tester powinien na przykład pisać testy jednostkowe dla deweloperów, dostarczać przykłady, aby pomóc im rozpocząć pracę, czy też szkolić ich w celu poprawy umiejętności testowania? Tylko Ty i Twój nowy zespół ds. testowania oprogramowania możecie o tym zdecydować.

Posłużymy się typowym procesem Scrum, aby pokazać, jak można umiejscowić interwencje testowe w podejściu Scrum. Interwencje występują na poziomie projektu (lub wydania) albo na poziomie sprintu. Poniższy diagram przedstawia widok na poziomie projektu oraz pięć kluczowych interwencji.

Kwestionowanie historyjki i definiowanie historyjki to etapy, na których tester odpowiednio sprawdza historyjkę użytkownika i proponowane kryteria akceptacji dla historyjki. Testy integracyjne sprawdzają, czy nowe funkcje prawidłowo łączą się z innymi funkcjami i z całym systemem. Testy systemowe i testy użytkownika (akceptacyjne) są przeprowadzane w zależności od potrzeb.

Projekt zwykle składa się z wielu sprintów, a cztery interwencje sprintu przedstawiono na poniższym diagramie. Codzienne spotkanie zespołu jest okazją do raportowania postępów, zgłaszania obaw, identyfikowania zagrożeń lub omawiania pytań zadanych i odpowiedzi otrzymanych w trakcie sprintu. 

Doskonalenie historyjek i udział w testowaniu przez deweloperów to codzienne działania, które odbywają się w ramach dyskusji z użytkownikami, analitykami i deweloperami. Tester włącza testy deweloperskie i nowe testy systemu do stale rosnącego zbioru testów przeznaczonych do automatyzacji.

W poniższej tabeli można zobaczyć tabelaryczne podsumowanie interwencji testerów. Twój proces może wyglądać inaczej lub może opierać się na Scrumie z pewnymi modyfikacjami, ale tabela przedstawia typowe rodzaje interwencji w typowym procesie Scrum. W różnych punktach własnego, unikalnego procesu możesz mieć aktywnych więcej lub mniej interwencji.

Sugeruję, aby zidentyfikować kluczowe momenty, zaproponować swój wkład i negocjować z zespołem. Oferujesz większe przywództwo i wskazówki w zakresie testów, zamiast po prostu zgłaszać się do wzięcia odpowiedzialności za pracę związaną z testowaniem. Takie podejście znacznie ułatwi zademonstrowanie swojej wartości zespołowi, ale zespół może nie potrzebować aż tylu testerów.

Relacje z programistami

W niektórych organizacjach relacje między programistami mogą być pełne nieufności, wzajemnych oskarżeń i antagonizmów. W najgorszym przypadku relacja jest toksyczna: programiści prawie w ogóle nie testują, a testerzy są postrzegani jako słudzy programistów. Testerzy przyjmują zachowania, które można nazwać współzależnymi, i zachowują się jak ofiary. Taka sytuacja jest dokładnie tym, czego ma pomóc uniknąć podejście polegające na przesuwaniu testów na wcześniejszy etap.

Do opisania dobrej relacji między programistą a testerem używano wielu metafor. Posłużymy się stylem pracy pilot-nawigator, aby zilustrować, jak może funkcjonować porównywalna relacja między programistą a testerem. Najpierw jednak przyjrzyjmy się dysfunkcyjnej sytuacji.

Nawigator nie wsiada do samolotu, ale macha pilotowi na pożegnanie, gdy ten startuje. Nawigator podróżuje autobusem, osobno, ale powoli. W końcu nawigator dociera do celu, jednak po pewnym czasie okazuje się, że samolot poleciał w złym kierunku i rozbił się o górę.

Czy nawigator z pewnością nie powinien był znajdować się w samolocie? Wyobraź sobie, jak w rzeczywistości współpracują piloci i nawigatorzy.

• Pilot nie może lecieć samolotem bez nawigatora. Nawigator nie może pilotować samolotu.
• Pilot i nawigator uzgadniają plan lotu przed rozpoczęciem podróży.
• Pilot startuje i leci samolotem.
• Nawigator śledzi kurs i porównuje go z planem lotu lub miejscem docelowym, uwzględniając niekorzystne zdarzenia, w szczególności pogodę.
• Nawigator wyszukuje odchylenia, wyznacza nowy kurs i powiadamia pilota, który wprowadza korekty do toru lotu.
• I tak dalej.

Relacja pilot/nawigator jest porównywalna z relacją programista/tester. Rozdzielanie programistów i testerów na odrębne zespoły pracujące sekwencyjnie również nie ma sensu. A jednak właśnie tak postępowaliśmy zwyczajowo przez ostatnie około trzydzieści lat – szczególnie w przypadku większych projektów realizowanych w dłuższym okresie.

Przesuwanie testów na wcześniejszy etap zmienia sposób myślenia o testowaniu i skutecznie przesuwa je na wcześniejszy etap. Testerzy działają jako pełnoprawni partnerzy programistów, podobnie jak nawigatorzy współpracują z pilotami:

• Tester i programista wspólnie gromadzą informacje dotyczące wymagań.
• Zazwyczaj tester podważa wymagania za pomocą przykładów (potencjalnych lub rzeczywistych pomysłów na testy).
• Programista myśli o implementacji, wykorzystując przykłady do wyznaczenia kierunku dla swojego projektu.
• Tester, programista, interesariusze, użytkownicy i analitycy uzgadniają wspólne rozumienie wiarygodnego wymagania.
• Tester pozostaje w stałym kontakcie z programistą, omawiając zmiany wymagań, ryzyko niepowodzenia oraz sposób, w jaki testowanie może pokazać działanie funkcji lub ujawnić błędy.
• Tester analizuje, jak opracowywana funkcja zintegruje się zarówno na poziomie technicznym, jak i na poziomie ścieżki użytkownika, oraz jak można przetestować integrację.
• Tester wychodzi poza bezpośredni zakres funkcji, nad którą pracuje programista, aby zidentyfikować przyszłe wyzwania, zagrożenia, zmiany i niepewności.
• I tak dalej.

Opisana właśnie idealna relacja między programistą a testerem nie powstaje automatycznie. Zespół musi ją wypracować. Można potraktować każde z powyższych działań jako interwencję, ale interwencje nie zawsze są komfortowe dla wszystkich stron. Aby dać temu podejściu największą szansę na powodzenie, omów każdy rodzaj interwencji ze swoimi partnerami już na samym początku – gdy po raz pierwszy dowiesz się, że będziecie ściśle współpracować.

Interwencje, podobnie jak dobre historyjki użytkownika, są bodźcami do rozmów.

Każdy rodzaj interwencji wymaga zgody obu stron, że jest to właściwe działanie. Aby czuć się komfortowo, każda ze stron musi ufać drugiej, że istnieje dobry powód do zadawania pytań, zgłaszania problemów oraz kwestionowania wymagań lub sposobu ich rozumienia podczas spotkań na stojąco, sesji planowania czy retrospektyw.

Wyzwania związane z zespołami rozproszonymi i zewnętrznymi

W powyższych rozważaniach milcząco założono, że wszyscy pracują w tym samym zespole i znajdują się w tej samej lokalizacji. Gdy obciążenie zespołu testowania oprogramowania jest zlecane na zewnątrz i/lub realizowane za granicą, pojawia się kilka negatywnych czynników. Tabela przedstawia trzy typowe czynniki, które należy uwzględnić.

Niektóre firmy rozbudowują istniejące zespoły testowania oprogramowania, aby zwiększyć ich możliwości na potrzeby większych projektów, lub zatrudniają wyspecjalizowane firmy testujące zamiast polegać na wykonawcach kontraktowych albo wewnętrznych pracownikach użytkownika przy testowaniu. W innych sytuacjach całość prac programistycznych i/lub testowych może zostać przekazana dostawcom. We wszystkich przypadkach firma klienta musi zarządzać swoimi dostawcami. Nie oznacza to, że wystarczy sporządzić restrykcyjną umowę z surowymi klauzulami dotyczącymi kar.

Gdy coś idzie nie tak, chcesz szybkiej reakcji i współpracy ze strony dostawcy; nie chcesz, aby ukrywał się za zapisami prawnymi w umowach.

Oto klucze do sukcesu:

• Jeśli nie zarządzasz swoim dostawcą, to on będzie zarządzał tobą (jeśli nie jesteście pełnoprawnymi partnerami i pozwolisz dostawcy określać warunki, dostawca będzie miał wszystkie atuty).
• Celem jest zdefiniowanie dobrej relacji roboczej. Należy ją ustanowić na wszystkich poziomach – interesariusza, menedżera, a także praktyka.
• Umowy powinny być sformułowane tak, aby określały wszystkie obowiązki obu stron, a także zawierały odpowiednie środki, wartości progowe, płatności etapowe i kryteria akceptacji zdefiniowane w celu zachęcania do dobrego zachowania (po obu stronach porozumienia).
• Porozumienia powinny zachęcać do otwartości i zaangażowania we wspólny cel, jakim jest sukces projektu.

Coś do przemyślenia

Na koniec kilka pytań, które skłonią cię do refleksji. 

Jaką relację masz jako tester z programistami? A jeśli jesteś programistą i czytasz ten tekst, jaka jest twoja relacja z testerami? Zapytaj osoby współpracujące z tobą przy programowaniu lub testowaniu, jak opisałyby waszą relację. Porównajcie spostrzeżenia!

Aby zespoły testowania oprogramowania były produktywne, muszą się komunikować i współpracować.