Automatyzacja testów to temat bardzo na czasie. Podobnie jak idea Agile. W jaki sposób testy automatyczne wpływają na zwinny proces tworzenia oprogramowania? I jak sprawić, aby były widoczne? W niniejszym artykule postaram się wskazać miejsca w procesie zwinnym, gdzie testy (w tym automatyczne) powinny być uwzględnione, aby cały Zespół Developerski czerpał z nich korzyści, a świadomość dotycząca ważności testów – rosła.

Estymacje

Wyobraźmy sobie taką sytuację. Dzień jak co dzień – Zespół Developerski dokonuje estymacji zadania. I nagle ze strony developerów pada stwierdzenie: „To proste zadanie. Szybko się z nim uwiniemy!”. W sali na moment zapada cisza, a osoby odpowiedzialne za testy zaczynają zastanawiać się, czy ktoś uwzględnił wpływ tego zadania na projekt testów automatycznych. Może trzeba będzie dodać do nich zupełnie nową funkcjonalność (np. obsługę tokenów autoryzacyjnych albo procesu logowania)? A może będzie trzeba dokonać zmian w wielu miejscach? Rolą testera (a właściwie developera, gdyż metodyki zwinne nie wyróżniają nazw członków zespołu) jest zadbanie o to, by testy, w tym testy automatyczne, zostały uwzględnione w estymacji. Efektywna komunikacja to jedno z podstawowych założeń metodyk zwinnych. „Wam to zajmie mało czasu, ale testerzy spędzą nad tym dużo, dużo więcej”. Dlatego też praca testerów również powinna znaleźć odzwierciedlenie w estymacji.

Takie podejście w trakcie estymacji wpłynie pozytywnie na pracę całego Zespołu Developerskiego, bo testy automatyczne to również kod. I tak samo jak kod produkcyjny powinien podlegać procesowi code review. Wydawać się to może stratą czasu bo to tylko testy. Ale kod złej jakości jest ciężki w utrzymaniu. Nie bez powodu 63% doświadczonych developerów biorących udział w badaniu HackerRank przyznaje, że spaghetti code jest jedną z najbardziej irytujących rzeczy w pracy projektowej. Dodatkowo taki kod nie daje jednoznacznych wyników, a także może pomijać istotne przypadki biznesowe.

Przeczytaj także: Automatyzacja testów – obalamy mity.

Testy automatyczne a Definition of Ready i Definition of Done

Definiton of Ready

Definition of Ready (DoR) określa stan zadania, co do którego zespół uznaje, że je rozumie i jest je w stanie wykonać. DoR powinno również określać, czy zadanie jest testowalne i jeżeli tak, to w jaki sposób. Dotyczy to również testów automatycznych. Zespół powinien nakreślić i zrozumieć wszystkie czynności, jakie należy wykonać, aby uwzględnić omawiane zadanie w projekcie testów. Już na tym etapie jesteśmy w stanie określić, jakie testy zostaną zautomatyzowane. Warto pamiętać, że na pewno wpłyną one na velocity Zespołu Developerskiego. O co chodzi? Już wyjaśniam. Velocity jest miarą tego, jak szybko Zespół Developerski jest w stanie zrealizować wymagania Product Ownera. Warto wziąć ten czynnik pod uwagę, ustalając zakres prac w danym Sprincie.

Przykładowo w przypadku zadania, które dotyczy aktualizacji wykorzystywanych w systemie narzędzi, testy automatyczne zostaną ograniczone jedynie do ich uruchomienia po wprowadzeniu zmian celem wykonania regresji, czyli potwierdzenia, że system działa prawidłowo. Inaczej sytuacja wygląda w przypadku zadania, które dotyczy wprowadzenia nowej funkcjonalności. Wtedy estymacja musi uwzględnić development oraz code review testów.

Definition of Done

Definition of Done, czyli w skrócie DoD, określa moment, kiedy uznajemy, że realizowane zadanie z Backlogu Sprintu zostało ukończone. Czy zatem powinno ono zawierać informację o testach automatycznych, dotyczących danego zadania? Opinie na ten temat są różne.

Jedni uważają, że spowolni to development, a tym samym spowoduje obniżenie velocity zespołu. Obawy dotyczą również potencjalnej sytuacji, w której developerzy zakończyliby swoje zadania, a następnie bezczynnie czekali, aż testerzy skończą testowanie. Inni z kolei twierdzą, że dzięki temu jakość tworzonego oprogramowania będzie jeszcze wyższa, a to pozytywnie wpłynie na  świadomość Zespołu Developerskiego w temacie testów. Zwolennicy tego podejścia podkreślają, że pozwoli ono wskazać wpływ dostosowania testów do złożoności zadania, które to powinno zostać uwzględnione w trakcie estymacji.

Moim zdaniem, aby wpisywać testy automatyczne do DoD, potrzebny jest zgrany i zaangażowany zespół, posiadający wysoką świadomość pracy w metodyce zwinnej. Brak świadomości w zespole nie powinien być jednak argumentem przeciwko takiemu zabiegowi. Wręcz przeciwnie – będzie to wyzwanie do zrealizowania, które dodatkowo wpłynie pozytywnie na wiedzę w zakresie roli testów automatycznych na proces dostarczania oprogramowania.

W jednym z projektów, przy których pracowałem, zespół zadecydował o wpisaniu testów automatycznych do DoD, ponieważ potwierdzały one działanie systemu przed zaprezentowaniem go klientowi. Następnie developerzy poprosili o szkolenie, tak aby w przypadku dużego obciążenia testerów lub ich nieobecności testy nie były zaniedbywane. Podejście to bardzo szybko okazało się owocne. Testy przygotowane przez developerów pokazały, że zmiana w kodzie spowodowała uszkodzenie systemu w zupełnie innym miejscu, niż się spodziewaliśmy. I to wszystko jeszcze przed code review samego rozwiązania!

Zobacz także: Rola testera w Zespole Scrumowym

Planowanie Sprintu

Czy zadania dotyczące tworzenia i utrzymywania testów automatycznych powinny mieć wpływ na zakres Sprintu? Moim zdaniem należy tutaj wyróżnić dwa obszary. Pierwszy z nich dotyczy DoD, o którym pisałem powyżej. Jeżeli testy zostały tam uwzględnione, wtedy zakres Sprintu musi odzwierciedlać velocity zespołu, w tym testerów automatyzujących.

Drugi obszar to z kolei zadania okołotestowe, czyli takie, które bezpośrednio nie dotyczą testów, ale mają na nie znaczący wypływ. Trzeba tu zadać sobie kilka pytań. Czy testerzy mają osobne środowisko do wykonywania swoich testów? Jeśli tak, to czy posiada ono odpowiednią infrastrukturę? Czy testerzy posiadają odpowiednią wiedzę i/lub dostępy, aby móc z niego korzystać? Być może w trakcie poszukiwania odpowiedzi na te pytania zorientujemy się, że trzeba zaangażować innych członków zespołu (developerów, DevOpsów), co wpłynie na Scope Sprintu.

Sprint Review

W jaki sposób zaprezentować testy automatyczne na spotkaniu podsumowującym prace dokonane w danym Sprincie?

Dobre praktyki:

  • Na pewno należy krótko omówić, co zostało zrobione i jaki zakres funkcjonalności został pokryty testami. Ważne jest też to, w jakim stopniu odciąży to testerów podczas testów regresji wykonywanych ręcznie. To najlepszy sposób, by pokazać całemu Zespołowi Developerskiemu wpływ testów automatycznych na wspólną pracę.
  • Jeżeli nad daną aplikacją pracuje się z wieloma zespołami, to warto również wspomnieć o napotkanych problemach i sposobach ich rozwiązania. Dlaczego? Może się okazać, że problem został już rozwiązany przez kogoś innego lub wprost przeciwnie – być może to my rozwiązaliśmy problem, nad którym pracuje ktoś inny.
  • Jeżeli jest potrzeba, może warto w projekcie testów automatycznych uwzględnić ich odpowiednie raportowanie. Na przykład poprzez skonfigurowanie dedykowanego narzędzia, tak aby można było pokazać gotowy raport ze statystykami.

Czego unikać:

  • Nie należy pokazywać i omawiać poszczególnych scenariuszy testowych. Sprint Review to nie jest odpowiedni moment, ponieważ ich ocena powinna być zrobiona na etapie planowania i późniejszego code review.
  • Zdecydowanie nie należy fundować zespołowi czegoś, co można określić „seansem testów”. Myślisz, że uruchomienie testów automatycznych i wspólne oglądanie jak automat klika po aplikacji” to świetny pomysł? Pewnie tak – jeśli chcesz, aby część Sprint Review dotycząca testów była nużąca i traktowana przez innych jak zło konieczne.

Podsumowanie

W artykule omówiłem obecność testów automatycznych w zwinnym procesie tworzenia oprogramowania oraz to, jaki mają wpływ na pracę Zespołu Developerskiego. Warto pamiętać, że testy automatyczne są częścią usługi testerskiej, jednak bez odpowiedniego procesu i zrozumienia ich funkcjonowania – nie będą skuteczne. W zespołach pracujących zwinnie testy automatyczne stanowią ułatwienie w procesie dostarczania oprogramowania dla całego Zespołu Developerskiego. Dlatego testerze (developerze), dbaj o to i spraw, żeby inni je zobaczyli. Widoczność automatycznych testów oprogramowania na każdym etapie planowania prac z pewnością pozwoli na lepsze ich zrozumienie przez cały zespół i bardziej efektywne wykorzystanie ich potencjału w przyszłości.

Zobacz webinar: Testowanie w zespołach zwinnych

Autorem wpisu jest:
Mariusz Skomra

Żadna przygoda w moim życiu zawodowym nie zaczęła się od: „Potrzymaj mi sałatkę!", ale wiele zaczęło się od: „Mariusz – mam problem. Pomożesz?" Z wykształcenia biotechnolog, z zawodu tester automatyzujący. Obecnie doskonali swoją wiedzę z Javy w kontekście testów automatycznych aplikacji webowych oraz API. Prywatnie fotograf.

Dodaj komentarz

Komentarze:

Skontaktuj się z nami

Chcesz dowiedzieć się więcej o naszych usługach? Napisz do nas – odpowiemy na każdą wiadomość.

Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach handlowych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach marketingowych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma w celach rekrutacyjnych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma na potrzeby przyszłych rekrutacji.
W związku z obowiązującymi przepisami dotyczącymi ochrony danych osobowych tj. Ustawą o ochronie danych osobowych z dnia 10 maja 2018 roku, jak również treścią Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO), informujemy, że: 1. Administratorem danych osobowych jest JCommerce Sp. z o.o. z siedzibą w Katowicach, ul. Ściegiennego 3, 40-114 Katowice (KRS: 00007393418).
2. Powyższe dane osobowe przetwarzane będą przez JCommerce Sp. z o.o. – w zależności od udzielonych przez Panią/Pana zgód (podstawa prawna przetwarzania: art. 6 ust. 1 pkt a) RODO):
• w celach handlowych,
• w celach marketingowych,
• w celach rekrutacyjnych;
• w celach przyszłych rekrutacji.
3. Podanie powyższych danych osobowych nie jest wymogiem ustawowym, umownym lub warunkiem zawarcia umowy. Nie jest Pan/Pani zobowiązany/a do podania powyższych danych osobowych, jednak brak ich podania uniemożliwi realizacje ww. celu.
4. Posiada Pan/ Pani prawo dostępu do treści swoich danych, w tym otrzymania ich kopii i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do przenoszenia danych, prawo do sprzeciwu wobec przetwarzania, prawo do cofnięcia zgody w dowolnym momencie, jeśli została udzielona. Wycofanie zgody nie wpływa jednak na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem; oświadczenie o cofnięciu zgody na przetwarzanie danych osobowych należy złożyć w siedzibie JCommerce Sp. z o.o. lub przesłać na adres mailowy zgody@jcommerce.pl. Cofnięcie zgody na przetwarzanie danych osobowych skutkuje brakiem możliwości realizacji ww. celów przetwarzania;
5. Dane osobowe są udostępniane przez JCommerce Sp. z o.o. upoważnionym pracownikom i osobom współpracującym z JCommerce Sp. z o.o. na podstawie umów cywilnoprawnych, przez których realizowany jest cel przetwarzania;
6. Wszelkie pytania dotyczące ochrony danych osobowych oraz realizacje przysługujących praw, prosimy kierować na adres odo@jcommerce.pl;
7. W zależności od udzielonej zgody, dane osobowe będą przetwarzane przez czas niezbędny do realizacji ww. celów przetwarzania. W przypadku wniesienia sprzeciwu, JCommerce Sp. z o.o. przestanie przetwarzać Pani/Pana dane w ww. celu, chyba że będzie w stanie wykazać, że w stosunku do tych danych istnieją ważne prawnie uzasadnione podstawy, które są nadrzędne wobec Pana/Pani interesów, praw i wolności, lub niezbędne do ewentualnego ustalenia, dochodzenia lub obrony roszczeń;
8. Nie przekazujemy Pani/Pana danych poza teren Europejskiego Obszaru Gospodarczego oraz do organizacji międzynarodowych.
9. Pani/Pana dane osobowe nie podlegają zautomatyzowanemu podejmowaniu decyzji, w tym profilowaniu.
10. Ma Pani/Pan prawo wniesienia skargi do organu nadzorczego gdy uzna Pan/Pani, iż przetwarzanie ww. danych osobowych narusza przepisy ogólnego rozporządzenia o ochronie danych osobowych z dnia 27 kwietnia 2016 r.