Naturalna ewolucja? – Jak tester zostaje analitykiem biznesowym, a analityk testerem

let your talent shine ALTEN

Naturalna ewolucja? – Jak tester zostaje analitykiem biznesowym, a analityk testerem

Agile – tak, tak, znowu słyszycie to magiczne słowo. W dzisiejszych czasach wszystko powinno być „agile”, lub do takiego stanu dążyć. Staram się unikać tych obcojęzycznych zapożyczeń, mamy bowiem w języku doskonały odpowiednik tego słowa, którego będę dalej używał. Pandemia Zwinności – bo bycie zwinnym pasuje mi bardziej niż „agile” – dotarła już wszędzie, na stale zmieniając sposób w jaki pracuje się we wszelkiego rodzaju projektach, nie tylko związanych z IT.

Potrzeba bycia zwinnym w testach oprogramowania przekłada się na wiele aspektów, o których napisano w innych artykułach w bardziej profesjonalny sposób. Ja, w tej luźnej formie, chciałem się skupić na tym, jak ewoluuje profesja testera, który już dawno przestał zajmować się szukaniem błędów, jakich narobili w kodzie programiści. Bierze za to na barki większy zakres odpowiedzialności za całkowitą jakość tworzonego oprogramowania, próbując spojrzeć na ten proces dokładniej, także z perspektywy klienta biznesowego.

Wielu z Was na pewno słyszało o koncepcie „Trzech Amigos”. To jeden z fundamentów w grupie metod zwinnych, zakładający ścisłą kooperację pomiędzy 3 grupami, lub też ich przedstawicielami: developerami, testerami i klientem biznesowym. Mamy tutaj ludzi patrzących na problem z trzech różnych perspektyw, współpracujących w taki sposób, aby produkt przez nich przygotowany spełniał zdefiniowane wymagania i działał poprawnie. Programistów zostawimy, ale przyjrzymy się bliżej pozostałym kumplom.

Obie grupy działają bardzo podobnie i wymaga się od nich tego samego, analitycznego podejścia do stawianych zadań, a główna różnica między nimi widoczna była do tej pory w zaangażowaniu na poszczególnych etapach cyklu produkcji oprogramowania. W tradycyjnym podejściu przyjmuje się bowiem, że aby oprogramowanie zostało napisane poprawnie, należy zacząć od dogłębnej analizy wymagań, która zostanie poprawnie zamieniona w kod i dokładnie zweryfikowana testami.

Na kolejnych etapach gromadzenia doświadczenia związanego z testowaniem oprogramowania i rosnącym zaangażowaniem w nowe aspekty produkcji oprogramowania zauważałem, że ten tradycyjny podział zaczyna zamieniać się miejscami, a często także zacierać. Proces testowy zaczyna się bowiem już przed pisaniem kodu, nadając mu pewien kierunek (Test-driven development, Extreme Programming). Wchodzi także na terytorium zajmowane wcześniej przez analityków biznesowych, opierając się na danych zebranych bezpośrednio od klientów, przy tworzeniu przypadków testowych (Behaviour-driven development).

Wiadomym stało się, że w zależności od skomplikowania projektu nie będzie można określić wszystkich wymagań i warunków spełnienia, tzw. kryteriów akceptacji (acceptance criteria). Należy zatem przyjąć założenie, że wraz z postępem w tworzeniu produktu rośnie jego zrozumienie, generując nowe wymagania i kryteria spełnienia. Wnioski są takie, że najpoważniejszym testem dla wyprodukowanego oprogramowania jest oddanie go użytkownikowi i klientowi, a na tym etapie umiejętności oraz wiedza, jaką dysponuje analityk biznesowy stają się kluczowe. Doświadczenie pokazało mi, że jeśli na tym etapie zespół testerów włączy się aktywnie kontakt z biznesem, i tak samo jak analitycy biznesowi zacznie zbierać niezbędne do przeprowadzenia testów informacje bezpośrednio , testy pozwolą wykryć niezgodności z wymaganiami dużo sprawniej i na wcześniejszym etapie.

Wykorzystanie umiejętności analizy biznesowej staje się szczególnie pomocne, gdy stajesz przed wyzwaniem przetestowania czegoś, co nie posiada wystarczającej dokumentacji, lub w zespole nie ma osoby zapewniającej stały dostęp do informacji na temat wymagań biznesowych, kryteriów akceptacji, czy historyjek użytkownika (user stories).

Z biegiem czasu zdałem sobie sprawę, że jeśli nie chcę z testera ewoluować w  developera, będzie to naturalna ścieżka rozwoju, oddająca wręcz idealnie naturę zwinnych metod projektowych. W branży coraz częściej można spotkać się z określeniem Analityka Biznesowo-Jakościowego (Busienss/Quality Analyst), który ma zapewnić kompleksową kontrolę jakości w szerokim spektrum cyklu tworzenia oprogramowania. Ma łączyć umiejętności polegające na zarządzaniu procesem testowym, kontakcie z klientem końcowym, tworząc w ten sposób skuteczniejszą wersję pomostu pomiędzy biznesem, a rdzeniem technologicznym zespołu.

ALTEN at work

Wachlarz obowiązków takich osób może być zróżnicowany i będzie zależał od wielu czynników takich jak: skład zespołu projektowego, liczebność, poziom skomplikowania prac, itp. Opierając się na swoim doświadczeniu zawodowym mogę wyróżnić kilka obszarów, którymi są:

  • Zbieranie wymagań biznesowych
    Na podstawie zebranych od biznesu oraz z dokumentacji danych, tworzone są historyjki użytkownika, które wysokopoziomowo opisują wymaganie dotyczące produktu. Później wykorzystywane są także to tworzenia szczegółowych scenariuszy testów.
  • Spisywanie kryteriów akceptacji
    Tworzone są w celu sprawdzenia, czy historyjka spełnia wymagania zdefiniowane przez biznes i służą do późniejszego tworzenia warunków zaliczenia przypadków testowych.
  • Tworzenie i ulepszanie strategii kontroli jakości w projekcie
    W porozumieniu z właścicielem i menedżerem projektu tworzy się strategię testów na każdym etapie produkcji oprogramowania. Ma ona zapewnić żądany poziom jakości i zaspokojenia potrzeb klienta biznesowego.
  • Komunikacja z developerami
    Skupia się na jasnym i jednoznacznym przetłumaczeniu wymagań biznesowych, które na późniejszym etapie są weryfikowane i testowane. W przypadku wykrycia braków lub niejednoznaczności pomaga je uzupełnić i wyjaśnić.
  • Komunikacja z menedżerem projektu i biznesem
    Jest konieczna w celu poprawnego i wydajnego zarządzania mapą projektu, katalogiem błędów, priorytetami zadań, uaktualnianiem nowych wymagań.
  • Udział w każdym etapie procesu testowego
    Zaangażowanie w planowanie, kontrolę, analizę, projektowanie, implementację, wykonanie, ocenianie, raportowanie i zamykanie czynności testowych.

Jak widać lista jest dość spora, i łączy zadania charakterystyczne dla zespołów testerów i analityków biznesowych. Nie jest jednak prawdą, iż wszystkie te czynności wykonuje jedna osoba. Zespoły lub wybrani specjaliści dzielą się poszczególnymi częściami projektu, najczęściej jest to podział na poszczególne moduły, lub na właścicieli projektu, jeśli takowy ma ich więcej niż jednego. Istotne jest to, iż każdy z nich wykonuje obowiązki opisane powyżej, bez znaczenia do jakiego zespołu należy. W przypadku gdy zespół testerów i analityków jest wieloosobowy, deleguje się jednego przedstawiciela.

Doświadczenie przekonało mnie że ten sposób działania usprawnia pracę w projekcie i daje możliwość lepszego rozwoju umiejętności testerskich. Pozwala lepiej zrozumieć potrzeby, jakie wymagania ma spełniać produkowane oprogramowanie. Otwiera to także nowe pole rozwoju dla analityków biznesowych, którzy coraz mocniej angażowani są w proces testowania. Dzięki temu tworzy się zespół ludzi, którzy podchodzą do stawianych wyzwań kompleksowo i wydajniej wykorzystują zasoby.

Autor:

Tomasz Jochemczyk

Consulting Test Engineer

ALTEN Polska