Artykuły
Zephyr Test w praktyce projektów bankowych – jak zarządzać procesem testowym w Jira
W wielu projektach testowanie wciąż funkcjonuje w rozproszonych dokumentach, arkuszach i narzędziach. Na pierwszy rzut oka działa to wystarczająco dobrze – do momentu, gdy pojawia się pytanie, które decyduje o powodzeniu projektu:
Czy system jest rzeczywiście gotowy do wdrożenia?
Odpowiedź na to pytanie wymaga przede wszystkim przejrzystości procesu jakości: powiązania wymagań z testami, testów z błędami oraz pełnej historii zmian. Nie tylko informacji o liczbie wykonanych testów.
W naszych projektach bankowo-finansowych takim narzędziem stał się Zephyr Test – rozwiązanie zintegrowane z Jira, które pozwala zarządzać testami w tym samym ekosystemie, w którym powstaje oprogramowanie.
W praktyce taki zestaw scenariuszy testowych powiązanych z wymaganiami tworzy uporządkowany pakiet weryfikacji systemu, który może być wykorzystywany przy kolejnych wdrożeniach, analizie wpływu zmian oraz w testach akceptacyjnych po stronie klienta. Scenariusze są również przekazywane klientowi przed rozpoczęciem testów UAT, dzięki czemu może on wcześniej zapoznać się z zakresem funkcjonalności i przygotować do pracy z systemem.
W tym artykule opowiadamy o naszych doświadczeniach z pracy dwóch zespołów tego samego obszaru bankowo-finansowego. Pokazujemy, jak Zephyr Test pomaga uporządkować proces testowy, zwiększyć transparentność jakości oraz podejmować świadome decyzje dotyczące wdrożenia nowych wersji.
W naszych zespołach droga do Zephyr Test wyglądała nieco inaczej. Dlatego na początku chcemy opowiedzieć o tym, jak zaczęła się nasza praca z tym narzędziem i dlaczego właśnie ono stało się fundamentem naszego procesu testowego.
Dlaczego Zephyr Test stał się naszym narzędziem do zarządzania testami?
[Emilia Franko]
Zaczynając pracę w firmie, zostałam wprowadzona w Zephyr Test – w projekcie dla jednego z banków, w którym testowałam moduł zleceń stałych. Było to dedykowane narzędzie do zarządzania testami. Natomiast w kolejnym projekcie dołączyłam już na etapie utrzymania aplikacji do obsługi rozliczeń transakcji w systemach Elixir i Euro Elixir. Zadania były rejestrowane w JIRZE, natomiast scenariusze i przypadki testowe funkcjonowały równolegle w TestLinku oraz w pliku Excel.
Znając już wcześniej możliwości Zephyr Test, wspólnie z zespołem testerów zaproponowaliśmy przeniesienie całego procesu testowego bezpośrednio do JIRY. Decyzja została podjęta zespołowo i z perspektywy czasu uważam ją za jedną z istotnych dla uporządkowania jakości w projekcie. Zauważyłam wtedy bardzo wyraźną różnicę, że w Excelu można zarządzać listą testów, natomiast Zephyr Test pozwala zarządzać całym procesem testowym.
[Angelika Mitas]
W moim przypadku Zephyr nie był wyborem, tylko narzędziem, które już funkcjonowało w organizacji, choć nie był używany w moim zespole. Testy były prowadzone w różnych dokumentach i arkuszach, co powodowało rozproszenie informacji i brak jednego miejsca, w którym można byłoby kontrolować jakość. Dostałam zadanie uporządkowania procesu testowego i zbudowania w Zephyrze struktury, która będzie spójna, czytelna i możliwa do utrzymania w kolejnych wersjach systemu oraz w całej rodzinie produktów Flexi.
Wymagało to przeanalizowania możliwości i ograniczeń narzędzia oraz zaprojektowania procesu tak, aby testy były prowadzone centralnie, a nie w wielu plikach. Obecny system pracy, który stosuję, powstał na bazie doświadczeń zdobytych w moim pierwszym projekcie i jest efektem wielu iteracji i obserwacji.
I ciągle ewoluuje, ponieważ zależy mi na tym żeby praca w narzędziu była jak najbardziej efektywna i ekonomiczna.
Jak Zephyr Test pomaga połączyć testy z wymaganiami i zgłoszeniami błędów w Jira?
[Angelika Mitas]
Zephyr pozwala powiązać scenariusze z wymaganiami, a wykonania testów z błędami za pomocą różnego rodzaju linków. Dzięki temu powstaje pełna ścieżka pokazująca, jak dana funkcjonalność została zweryfikowana czy wystąpiły błędy i jeśli tak to jakie. To ułatwia kontrolę jakości i pozwala szybko ocenić wpływ zmian na system oraz zidentyfikować newralgiczne miejsca, które są podatne na błędy. Ponadto w trakcie rozwoju oprogramowania wymagania często ewoluują, a to sprawia, że scenariusze muszą być aktualizowane. W Zephyrze można śledzić te zmiany, bo nieaktualny scenariusz można powiązać z nowym, podobnie jak zaktualizowane wymaganie z jego kolejną wersją. Finalnie historia danej funkcjonalności jest przejrzysta i kompletna oraz pozwala szybko dotrzeć do najnowszej wersji.
[Emilia Franko]
Dokładnie tak. W praktyce wymagania, testy, wykonania i zgłoszenia błędów są ze sobą powiązane i widoczne w jednym systemie. Kiedy zmienia się zakres, od razu widać, które przypadki testowe wymagają aktualizacji. Nie trzeba ręcznie przeszukiwać dokumentów ani zastanawiać się, czy coś zostało pominięte. Dzięki temu szybciej reagujemy na zmiany i ograniczamy ryzyko niedotestowanych obszarów.
Możemy też sprawdzić, czy wcześniej w tym obszarze pojawiały się błędy i czy zmiana nie wpłynie na inne funkcjonalności. To znacząco przyspiesza analizę wpływu zmian i pomaga uniknąć niepotrzebnych regresji.
Kiedy tester wykonuje test i napotyka błąd, zgłoszenie defektu powstaje bezpośrednio w JIRZE i jest powiązane z konkretnym przypadkiem testowym. Tworzy się pełna, przejrzysta ścieżka:
Wymaganie → Test → Wykonanie → Błąd → Poprawka → Retest
W praktyce taki model powiązań między wymaganiami, testami i wynikami ich wykonania pozwala zbudować uporządkowany pakiet weryfikacji systemu, który wspiera kontrolę jakości oraz ogranicza ryzyko niezweryfikowanych zmian w kolejnych wersjach systemu.
Dzięki temu cały zespół projektowy może łatwo prześledzić historię danej funkcjonalności i zobaczyć, jak przebiegał proces jej weryfikacji.
Co daje Zephyr Test osobom związanym z projektem – testerom, analitykom, deweloperom, managerom i klientom?
[Emilia Franko]
Przedstawię to na prostym przykładzie z projektu. Na etapie wdrożenia podczas codziennych spotkań daily przeglądamy raport w Zephyr Test. Sprawdzamy, co zostało jeszcze do wykonania, które testy są wstrzymane oraz które scenariusze możemy już przetestować lub zretestować po poprawkach. Dzięki temu mamy obiektywny obraz postępu prac. Zestaw testów zaplanowanych przed wydaniem wersji jest dla nas bardzo dobrym punktem odniesienia w rozmowie z analitykami, deweloperami i projekt managerem. Przed rozpoczęciem testów wspólnie ustalamy zakres i weryfikujemy, czy wszystko jest spójne – czy coś nie zostało pominięte i czy zakres zmian rzeczywiście pokrywa się z zakresem testów. Zdarza się też, że deweloperzy prowadzą własny rejestr prac w Excelu. W takich sytuacjach Zephyr Test działa dla nas jak punkt kontrolny. Sprawdzamy, czy to, co zostało wykonane, znajduje odzwierciedlenie w testach i czy zakres prac rzeczywiście się pokrywa. Manager widzi konkretne dane: pokrycie testowe, status regresji, liczbę otwartych defektów oraz rzeczywisty poziom ryzyka przed wdrożeniem wersji. Dla klienta jest to sygnał, że jakość oprogramowania jest w projekcie zarządzana w sposób świadomy i mierzalny.
[Angelika Mitas]
Skoro Ty, Emilko, pokazałaś to z perspektywy praktyki projektowej, to ja zwrócę uwagę na jeszcze jeden aspekt. W pracy testera bardzo wiele dzieje się zanim pojawi się sam wynik testu. Dużą część tej pracy stanowi analiza wymagań, przygotowanie scenariuszy, danych do testów oraz przejście przez różne ścieżki w systemie. Samo wykonanie testu jest końcowym etapem znacznie dłuższego procesu. Dlatego dla mnie Zephyr jest przede wszystkim miejscem, które pozwala ten wysiłek uporządkować i uczynić go widocznym.
Pokazuje, ile pracy kryje się za każdym scenariuszem i jak czasochłonna potrafi być jego weryfikacja. To nie tylko narzędzie do linkowania testów z wymaganiami czy błędami, ale także miejsce, w którym można przechowywać testalia i budować uporządkowaną wiedzę o systemie. W dużej mierze zależy to również od inicjatywy testera i sposobu wykorzystania narzędzia w projekcie.
Dla analityków Zephyr może być miejscem, w którym łatwo sprawdzić, które wymagania są pokryte testami i jak przebiega ich weryfikacja. Deweloperzy mają dostęp do informacji o błędach i scenariuszach, które je wykryły.
Managerowie widzą postęp prac, ryzyka oraz czasochłonność pełnego procesu testowania. To pozwala lepiej planować kolejne etapy projektu i trafniej wyceniać testy.
Z perspektywy klienta – a mówię tu także jako zwykły użytkownik aplikacji bankowych czy zakupowych – nikt z nas nie zastanawia się, kto i jak testował daną funkcję. Po prostu oczekujemy, że będzie działać. Dlatego tak ważne jest, aby proces testowy był udokumentowany i przejrzysty, bo to on wpływa na jakość produktu, którą klient odczuwa dopiero na końcu.
To, co cenię najbardziej, to jawność Zephyra. Pokazuje, co testuję i nad czym pracuję.
Jak wygląda praca testera z Zephyr Test w projektach bankowo-finansowych?
[Angelika Mitas]
Moja praca w Zephyrze opiera się na zaprojektowanej przeze mnie strukturze. Porządek w dokumentacji to dla mnie priorytet, a zarządzanie nią jest jedną z moich mocnych stron i obszarem, w którym naprawdę dobrze się odnajduję. Kluczem jest planowanie i konsekwencja. Systematyczność pozwala mi utrzymać spójność scenariuszy i łatwo zarządzać nimi w kolejnych wersjach systemu. Każda wersja ma swój cykl testów, a w ramach cyklu znajdują się foldery odpowiadające procesom lub obszarom funkcjonalnym. Dzięki temu wiem, gdzie znajdują się konkretne scenariusze i jaki jest stan ich realizacji.
W codziennej pracy planuję proces testowy: piszę scenariusze, przeprowadzam testy, retesty i przygotowuję regresję. Zephyr daje mi pełną widoczność nad tym, co zostało wykonane, co jest w toku i jakie obszary wymagają ponownej weryfikacji. W moich projektach ważna jest również przenaszalność scenariuszy. W aplikacjach Flexi wiele elementów jest wspólnych, dlatego odpowiednia organizacja testów w Zephyrze pozwala szybko przenosić scenariusze między projektami, co znacząco przyspiesza pracę.
[Emilia Franko]
W moim przypadku codzienna praca testera z Zephyr Test zaczyna się znacznie wcześniej niż samo wykonanie testów. Na początku sprintu lub przy pojawieniu się nowego zakresu zmian przygotowuję lub aktualizuję przypadki testowe powiązane z wymaganiami w Jira. Dzięki temu od razu widzę, czy zakres analizy ma odpowiednie pokrycie w scenariuszach testowych i czy nic nie zostało pominięte.
Podczas testów wykonuję scenariusze bezpośrednio w Zephyr Test. Jeśli pojawia się problem, mogę od razu utworzyć zgłoszenie błędu w Jira, które jest powiązane z konkretnym przypadkiem testowym. Deweloper od razu widzi, w jakim scenariuszu wystąpił problem i w jakich warunkach został wykryty, co znacząco ułatwia komunikację i przyspiesza analizę błędu.
W praktyce oznacza to, że nie pracuję już wyłącznie na liście testów do wykonania. W jednym miejscu mogę przygotowywać scenariusze, realizować testy oraz raportować ich wyniki, mając pełny obraz procesu testowego.
Jak Zephyr Test pomaga budować dojrzały proces jakości oprogramowania w projekcie?
[Emilia Franko]
Dla mnie dojrzały proces zapewnienia jakości oprogramowania zaczyna się wtedy, gdy testowanie nie jest już kontrolą rozwiązania na końcu projektu, ale elementem jego planowania. W praktyce oznacza to podejście shift-left, czyli włączanie perspektywy testowej już na etapie analizy wymagań. Dzięki Zephyr Test możemy przygotowywać scenariusze testowe równolegle z powstawaniem wymagań. Pozwala to bardzo wcześnie analizować przypadki brzegowe, zależności między funkcjonalnościami oraz potencjalne ryzyka. Wiele kwestii wychodzi już na etapie analizy, zanim powstanie kod, co znacząco ogranicza liczbę nieprawidłowości pojawiających się później w testach. Z perspektywy projektu oznacza to bardziej uporządkowany i przewidywalny proces pracy zespołu. Z perspektywy klienta przekłada się to na większe bezpieczeństwo wdrożenia, ponieważ potencjalne problemy są identyfikowane wcześniej – w momencie, gdy ich rozwiązanie jest prostsze, szybsze i mniej kosztowne. Dzięki temu rozmowa o jakości oprogramowania nie dotyczy już tylko liczby błędów, ale poziomu ryzyka, pokrycia testowego oraz gotowości systemu do stabilnego wdrożenia.
[Angelika Mitas]
Z mojej perspektywy dojrzały proces jakości opiera się na jawności informacji, spójnej dokumentacji i kontroli zmian. Zephyr wspiera te elementy, bo pozwala wersjonować scenariusze, łączyć je z analizą, śledzić historię testów i badać jakość w dłuższej perspektywie. Zmiany w wymaganiach można szybko odzwierciedlić w testach, a ich wpływ na system jest widoczny natychmiast. Dzięki temu testy stają się integralną częścią procesu, a nie etapem wykonywanym na końcu. Ważne jest również to, że klarowny proces testowy otwiera przestrzeń do współpracy.
Jakość to nie efekt procesu testowania, tylko całego procesu wytwarzania oprogramowania. Na jakość wpływa poziom szczegółowości informacji potrzebnej do testów, „czujne oko” analizy i dewelopmentu, a także tester, który przekształca te dane w uporządkowany model testów, zapewniający pełne i mierzalne pokrycie kluczowych obszarów aplikacji.
Podsumowanie:
Excel może być dobrym punktem startowym, szczególnie w niewielkich projektach. W momencie jednak, gdy system zaczyna się rozwijać, pojawiają się kolejne wersje, zmiany funkcjonalne i konieczność wykonywania regresji. Zarządzanie testami w rozproszonych dokumentach przestaje być wystarczające. Zespół potrzebuje wtedy narzędzia, które nie tylko przechowuje scenariusze testowe, ale wspiera podejmowanie decyzji projektowych.
Zephyr Test pozwala przenieść proces testowania z poziomu operacyjnego na poziom zarządzania jakością systemu. Dzięki powiązaniu wymagań, scenariuszy testowych, wyników testów i zgłoszeń błędów w jednym środowisku Jira powstaje spójny obraz weryfikacji systemu. Zespół projektowy widzi, co zostało już sprawdzone, gdzie pojawiły się nieprawidłowości i które obszary wymagają dodatkowej uwagi przed wdrożeniem kolejnej wersji.
Z perspektywy dostawcy oznacza to uporządkowany i mierzalny proces jakości, który pozwala lepiej planować testy, analizować wpływ zmian oraz ograniczać ryzyko nieprzewidzianych błędów w kolejnych wersjach systemu.
Z perspektywy klienta wartość jest jeszcze większa. Choć nie zawsze jest to widoczne na pierwszy rzut oka, system przechodzi również kompleksowe, wewnętrzne sprawdzenia po stronie producenta – głównie pod względem technicznym i systemowym. Dzięki temu do klienta trafia już wstępnie zweryfikowany produkt, a on sam może skoncentrować się wyłącznie na ocenie logiki biznesowej.