Patrycja Krzywaniak
Za jedno z najczęściej użytkowanych narzędzi w ramach zarządzania projektami można uznać Jirę firmy Atlassian.
Atlassian wyposażył Jirę w imponującą liczbę funkcji, które wspierają zespoły w efektywnym zarządzaniu projektami o różnym stopniu złożoności. Najistotniejszą ideą Jiry jest zarządzanie projektami znajdującymi się w centralnej bazie, przy czym każdy z projektów podzielony jest na mniejsze zadania, które w zależności od metodologii prowadzenia projektu, procesowane są w ramach wypracowanego przez zespół przepływu pracy (ang. workflow). Odpowiednio zdefiniowany workflow zawiera zasady dotyczące projektu, m.in. priorytety poszczególnych zadań, osadzenie poszczególnych zadań w ramach etapów przepływu pracy oraz ich podziału ze względu na priorytety.
Jira słynie z możliwości rozbudowywania funkcjonalności, które użytkownicy mogą implementować poprzez instalację dodatkowych rozszerzeń do istniejącego już widoku projektu. Jest w pełni konfigurowalna, a stopień personalizacji i ilość wtyczek dedykowanych działom testów w zespołach znacznie przewyższa zasoby konkurencyjnych rozwiązań. Jednym z takich dodatków, który pomoże udoskonalić i poszerzyć możliwości zarządzania testami jest Requirements and Test Management for Jira (RTM) oferowane przez działającą na globalnym rynku firmę Hexygen Inc., która jest gałęzią polskiej firmy Deviniti.
Jakie są założenia RTM for Jira?
Requirements and Test Management (dalej w skrócie - RTM) dla Jira jest aplikacją wspierającą zarządzanie i organizację procesu testowego w organizacji. Jedną z funkcji jest śledzenie testów w ramach dowolnego projektu Jira. Narzędzie pomaga nam usystematyzować testy, co powinno się przekładać na poprawę procesu testowego i ostatecznie na jakość końcowego produktu.
W ramach wtyczki RTM dla Jira użytkownicy mogą tworzyć wymagania i łączyć je z określonymi przypadkami testowymi. Zarówno wymagania, jak i przypadki testowe zawarte są w planach testów i mogą być realizowane i rozliczane przez wykonywanie testów. Aplikacja RTM zapewnia także zarządzanie defektami, określanymi jako awaria lub incydent, występującymi w procesie testowym.
Ogólnie, aplikacja zapewnia szerokie spektrum nadzorowania i sterowania działaniami testowymi. Poprzez powiązania ze sobą poszczególnych elementów procesu, umożliwia generowanie raportów opartych o dane dostarczone z testów.
Przyjrzyjmy się jednak jak działają wymienione funkcje narzędzia.
Konfiguracja i pierwsze kroki z RTM
Dodanie wtyczki do Jiry jest standardową procedurą. Użytkownicy, którzy kiedykolwiek dokonywali instalacji wtyczki do Jiry nie powinni mieć z tym problemu. Wtyczkę należy po przejściu do widoku projektu wyszukać z poziomu zakładki Aplikacje > Znajdź nowe aplikacje. Po wpisaniu w wyszukiwarce frazy ‘Test management’ i kliknięciu ‘Enter’ pojawia się kafelek z poszukiwaną wtyczką RTM. Dalsze kroki instalacji są równie intuicyjnie i przebiegają dość sprawnie.
Po zainstalowaniu wtyczki i przejściu do sekcji ‘Ustawienia projektu’ na samym dole panelu bocznego pojawia się opcja ‘RTM Configuration’. Narzędzie jest pobrane i gotowe do konfiguracji.
Pełna dokumentacja wspierająca użytkownika jest dostępna w wersji angielskiej na stronie wtyczki i pozwala na przejście krok po kroku procesu konfiguracji RTM dla naszej Jiry.
Pierwszym etapem jest wybranie projektu, dla którego chcemy wdrożyć wtyczkę. Ważnym elementem, który warto podkreślić jest to, że aplikacja RTM nie wspiera projektów next-gen (więcej o projektach tego typu https://confluence.atlassian.com/jirasoftwarecloud/working-with-agility-boards-945104895.html), a dostępna jest tylko dla projektów klasycznych. To ważne, aby zweryfikować do jakiego typu projektu chcemy dodać nasze narzędzie, gdyż komunikat błędu, który pojawia się przy dodaniu RTM do projektu typu next-gen jest nieprecyzyjny i nie informuje o przyczynie niepowodzenia instalacji. Informacja o wyłączeniu projektów next-gen z dostępności RTM jest dodana w dokumentacji narzędzia.
Kolejnymi krokami dodawania narzędzia do projektu jest wybranie typów issues. Wszystkim niewtajemniczonym wyjaśniamy, że wokół issue zbudowana jest cała Jira. Może to być zadanie, wymaganie czy też defekt. Projektowany w RTM przypadek testowy czy też egzekucja testu jest typem issue, a cały projekt również może być oparty na typach pobranych z aplikacji RTM. W kolejnym kroku następuje mapowanie typów issue zdefiniowanych we wcześniej wykonanej akcji. W przypadku mapowania należy przypisać poszczególne typy issues do obiektów: Wymagania, Przypadki Testowe, Plany Testów, Egzekucje Testów. Typy issue muszą zostać dodane w ustawieniach projektu. Jeśli użytkownik nie zrobił tego przed przejściem do konfiguracji RTM do projektu, to musi to wykonać w ustawieniach projektu, inaczej przejście do kolejnego kroku nie będzie możliwe.
Dalej należy dodać ekrany, czyli miejsca, w których aplikacja RTM będzie widoczna w konfigurowanym projekcie. Należy wybrać wszystkie wymagane pola do konfiguracji ekranów projektu, w przeciwnym razie RTM nie będzie działać poprawnie.
Po tym kroku następuje potwierdzenie -> konfiguracja jest zakończona. Wartościową opcją jest możliwość wygenerowania przykładowych danych dla wszystkich elementów niezbędnych do sprawdzenia możliwości aplikacji RTM.
Wystarczy przełączyć “switch” widoczny na ostatnim kroku konfiguracji i po rozpoczęciu pracy z narzędziem w Backlogu projektu i na drzewie plików w aplikacji RTM > Test Management pojawi się zestaw przykładowych typów zgłoszeń, jak przypadki testowe, czy wymagania. Jest to bardzo wygodne, jeśli użytkownik chce szybko rozpocząć naukę możliwości RTM na nowo utworzonym projekcie.
Aplikacja jest gotowa do użytku. Jeśli użytkownik dodaje ją do istniejącego, wcześniej skonfigurowanego projektu, przebiega to szybko i bezproblemowo. Konfiguracja dla nowego projektu, wymaga kilku dodatkowych kroków, wszystkie są czytelnie opisane w dokumentacji narzędzia.
Raporty w widoku Dashboard
Po prawidłowym dodaniu RTM do naszego projektu i przejściu do zakładki Test Management pojawia się widok drzewa z modułami aplikacji. Pierwszym nadrzędnym modułem jest kokpit (Dashboard), który służy do wyświetlania raportów, wygenerowanych i wysłanych przez użytkownika. Aby stworzyć taki raport należy przejść do Aplikacje > Test Management. Tutaj widoczne są wszystkie raporty jakie użytkownik może utworzyć:
- Monitorowanie,
- Pokrycie,
- Egzekucje przypadków testowych,
- Egzekucje testów.
Raporty są też widoczne w drzewie modułów aplikacji. Użytkownik może generować własne raporty i wysyłać je do „Raportów użytkownika”. Administrator projektu może dodatkowo zdefiniować raporty i wysłać je do zakładki „Raporty projektowe”.
Utworzone i wysłane do Dashboardu raporty prezentują się następująco:
Aplikacja RTM dla Jira umożliwia wyświetlanie raportów z wykonania testów i wykonania przypadków testowych na dashboardach. Możliwe są dwie opcje przekazywania raportów:
- Przesłanie do dashboardu testów (wykonywane przez użytkownika) - wszyscy użytkownicy mogą wysyłać raporty do własnych dashboardów,
- Przesyłanie do pulpitu testowego (w ramach danego projektu) - użytkownicy posiadający uprawnienia administratorów projektu mogą wysyłać raporty do pulpitu nawigacyjnego projektu.
Wygenerowane raporty wpływają na większą przejrzystość procesu testowego. Mają estetyczną formę i są zrozumiałe dla użytkowników na różnych poziomach zaawansowania.
Prawdopodobnie jedną z najważniejszych wartości we wspólnym zarządzaniu wymaganiami i przypadkami testowymi przy pomocy jednej wtyczki będzie łatwe generowanie matryc śledzenia (ang. traceability matrix). W podstawowym ujęciu jest to oczywiście obserwowanie stopnia pokrycia przez zaprojektowane testy dla wymagań.
Możliwości generowania matryc jest jednak znacznie więcej. Praktycznie każdy “issue type” możemy mapować na inny.
Dzięki tej funkcji możemy między innymi sprawdzić jakie testy w ramach zdefiniowanego Planu Testów zwracają najwięcej defektów lub które wymagania i w jakim zakresie zostały przetestowane.
Jeśli matrycę uznamy za zbyt nieczytelną, zawsze możemy wygenerować raport pokrycia.
Zarządzanie wymaganiami
W ramach modułu Wymagania użytkownicy mogą przechowywać wszystkie typy zgłoszeń zdefiniowanych jako wymagania dla danego projektu. Przy początkowej konfiguracji narzędzia można wybrać opcję zaimportowania typów wymagań zapewnionych przez aplikację RTM lub można je utworzyć samodzielnie, zależnie od preferencji użytkownika. Jeśli podczas konfiguracji RTM wybrana została opcja zaimportowania domyślnych typów dostarczonych przez wtyczkę, to dodane zostają następujące typy wymagań:
- Functional Requirement
- UI Requirement
- Non-functional Requirement
- Business Requirement.
Moduł zapewnia też szereg opcji edycji, zarządzania czy tworzenia nowych wymagań.
Dostępne operacje na istniejących wymaganiach to:
- tworzenie folderów i importowanie do nich wybranych z listy wymagań (drag and drop)
- klonowanie istniejących wymagań
- wyszukiwanie po nazwie/numerze wymagań istniejących na liście
- możliwość importu wcześniej utworzonych wymagań w projekcie,
- ustawienia klucza testowego dla wybranych lub wszystkich wymagań.
Dodatkowo można tworzyć nowe wymagania. Po kliknięciu ikony ‘+’ pojawia się formularz tworzenia wymagania. Każde wymaganie można skonfigurować jako zwykły Jira Issue Type oraz powiązać z konkretnym Test Casem.
Istnieje również możliwość filtrowania wymagań oraz zapisywania utworzonych filtrów. Dotyczy to nie tylko modułu Wymagania, ale wszystkich innych modułów w drzewie. Filtry dostępne są w sekcjach: wymagania (Requirements), przypadki testowe (Test Cases), plany testów (Test Plans), egzekucje testów (Test Executions) i defekty (Defects).
To co najważniejsze, czyli Test Case, Test Plan i Test Execution
Wszystkie omówione do tej pory moduły aplikacji RTM to dodatki niezaprzeczalnie wspierające procesy testowe. Jednak rdzeniem każdego takiego procesu są przypadki testowe (Test Cases), plany testów (Test Plans) oraz egzekucja testów (Test Execution).
Pierwszym i najistotniejszym elementem, w oparciu o które tworzone są pozostałe elementy procesu testowego jest Test Case. Aplikacja RTM zapewnia bardzo dokładny moduł do zarządzania czy edycji pojedynczych przypadków testowych. Po kliknięciu w zakładkę ‘Przypadki Testowe’ (Test Case) użytkownik rozwija widok listy z przypadkami dodanymi w ramach tworzonego projektu, ze wszystkimi funkcjami jak w przypadku Wymagań. Test case’y w tym widoku można dodawać, usuwać, importować, grupować w foldery, wyszukiwać na liście itd.
Po kliknięciu w wybrany na liście przypadek testowy wyświetla się on w szczegółowym widoku:
W ramach szczegółowego widoku pojedynczego przypadku testowego użytkownik ma możliwość podglądu danego przypadku z podziałem na czynniki pierwsze. W zakładce szczegóły znajdują się bazowe informacje, standardowe dla dobrze opisanego przypadku testowego, jak np. status, osoba zgłaszająca lub priorytet. Pojawia się tutaj również tzw. klucz testowy (ang. test key). Jest to generowany dla każdego obiektu testowego unikalny identyfikator, który pozwala łatwiej do niego referować.
W tym miejscu można dołączyć również wszelkie załączniki, plany, dokumenty, dodawać komentarze, czy obserwować historię zmian danego przypadku. W kolejnej zakładce - Kroki - zdefiniowane są warunki początkowe danego przypadku testowego oraz rozpisane kroki wykonania danego przypadku. Przydatną opcją jest również możliwość wyeksportowania przypadku do pliku CSV, co pozwala na jego przenoszenie do innych narzędzi/projektów.
W zakładce wymagania znajdują się wymagania, które zostały powiązane z danym TC. Można dodawać nowe wymagania do przypadku, tworzyć nowe wymagania oraz usuwać przypisane wymagania z danego przypadku. Każdy przypadek testowy może pokrywać kilka wymagań.
Ostatnią z zakładek stanowią Relacje. Test Case’y zawierają się w Test Planach. Jeden przypadek testowy może być powiązany z kilkoma planami testowymi. Istnieją dwa rodzaje relacji: bezpośrednie i pośrednie. Łączenie zgłoszeń w relacje wymaga odpowiednich uprawnień w ramach danego projektu.
Każdy proces testowania wymaga Planu Testów, w którym uwzględnione są wszystkie powiązane Przypadki Testowe (i pośrednio jego Wymagania). Oznacza to, że Plany Testów podsumowują wszystkie działania podczas procesu testowego. Plan testów można zrealizować poprzez wykonanie przypadków testowych do niego przypisanych. Można wykonywać je kilkakrotnie, na przykład, jeśli realizowany plan testów dotyczy kilku środowisk lub w ramach testów regresji, czyli po wdrożeniu zmian w tworzonym projekcie.
Widok i opcje w ramach modułu Plany Testów niewiele różnią się od możliwości zaimplementowanych w module Przypadki Testowe - można tworzyć, edytować, usuwać Test Plany. Można także zapisywać ustawione filtry. W ramach edycji Test Planów można zmieniać kolejność przypisanych do niego Przypadków Testowych.
Egzekucja Testów jest modułem wspierającym proces wykonywania planów testów i monitorowania wyników wykonania przypadków testowych. Moduł ten ma taką samą strukturę jak Plan Testów. Składa się z listy przypadków testowych, na której można monitorować aktualny stan wykonania przypadku testowego. Podczas egzekucji testów możliwe jest również sprawdzenie szczegółów Planu Testów i dodanie relacji między zgłoszeniami.
Zakładka ‘Relacje’ w module Egzekucja Testów prezentuje i porządkuje bieżące zależności między wymaganiami, przypadkami testowymi i planami testów.
W celu dokonania egzekucji Test Planu lub pojedynczych przypadków należy przejść do modułu Zarządzanie testami> Plany testów. Po kliknięciu wybranego Planu Testów i przejścia do sekcji Egzekucje, pojawia się opcja ‘Wykonaj plan testów’. Można również przejść do folderu docelowego, wybrać Plan Testu i kliknąć “Wykonaj”. Oba sposoby dają identyczny efekt.
Egzekucję testów utworzoną na podstawie wybranego Planu Testów można śledzić. Bieżący stan wykonań jest widoczny w sekcji ‘Wykonania planu testów’.
Po kliknięciu przycisku ‘Rozwiń’ obok paska postępu, wyświetlona zostaje lista przypadków testowych.
Przypadki Testowe są wykonywane tylko jako część Planu Testów i są widoczne w Egzekucji Testów w postaci listy, na której można monitorować wyniki lub przypisać do każdego z nich testera, który ma wykonać dany przypadek.
Co z defektami?
W ramach modułu ‘Defekty’ użytkownik może zarządzać zgłoszeniami do projektu. W wyniku znalezienia błędów w projekcie w wykonaniu przypadków testowych tester tworzy defekt. Defekty dotyczą całego Przypadku Testowego.
Błędy domyślne z aplikacji RTM stanowią osobny typ zgłoszeń. Przed podejściem do projektu należy upewnić się, że do projektu RTM dodano typ zgłoszeń z defektem. Drzewo defektów jest dostępne tylko wtedy, gdy projekt podczas konfiguracji został zdefiniowany z defektami - musi to być ten sam projekt, w którym przechowywane są wymagania i testy. Jeśli użytkownik wybierze kilka projektów, drzewo defektów nie będzie widoczne. Można to zweryfikować w każdym momencie poprzez przejście do modułu: Konfiguracja RTM> Typy problemów> Defekty.
Defekty mogą mieć różne przyczyny. Mogą odnosić się do bieżącego wykonania przypadku testowego lub być niesklasyfikowanym błędem. Te defekty, które są jasne i łatwe do sklasyfikowania, mogą być tworzone z poziomu Egzekucji Testów. Te, które pojawiają się jako osobny błąd i nie mogą być połączone z żadnym przypadkiem testowym, powinny być tworzone w sekcji Zarządzanie testami (Zarządzanie testami> Defekty> Dodaj defekt).
Defekty są widoczne na karcie ‘Relacje’ w każdym powiązanym elemencie.
Podsumowanie - zalety i wady
Requirements and Test Management to zdecydowanie jeden z ciekawszych i bardziej rozbudowanych pluginów Jiry. Z jednej strony prezentuje praktycznie wszystkie elementy powiązane z procesem testowym, pozwala je uporządkować i śledzić. Z drugiej - jest niezwykle prosty i estetyczny, użytkownicy na każdym poziomie doświadczenia z takimi aplikacjami powinni sobie bez problemu z nim poradzić.
Wymagania, przypadki testowe, plany testów, wykonania testów i defekty są wyświetlane w postaci drzewa. Ta struktura pomaga organizować elementy poprzez tworzenie folderów, przeciąganie i upuszczanie lub dodawanie nowych komponentów.
Aplikację cechuje prostota i przejrzystość. Użytkownicy ceniący sobie transparentność procesu testowego począwszy od nadzorowania egzekucji przypadków testowych po zarządzanie defektami skończywszy będą zadowoleni ze wsparcia jakie daje narzędzie RTM.
Dla testera niedogodnością, wynikającą ze specyfiki zawodu mogą być niespójności językowe elementów opisanych w zakładce. Jest to typowe dla wielu obszarów Jiry, jednak w takim narzędziu powinno to być doprecyzowane. Jako przykłady można podać np. w strukturze drzewa moduł ‘Wymagania’ opisany jest po polsku, jednak Typy wymagań, np. ‘Functional Requirement’ jest już po angielsku. Nie jest to jednak duża wada, a kwestia estetyki. Dla uniknięcia takich niespójności zalecam wybranie angielskiej opcji językowej dla projektu.
Można uznać, że specyfikacja samego rozwiązania jest na dobrym poziomie, co nie zawsze zdarza się w pluginach Jiry.
https://deviniti.com/support/addon/cloud/requirements-test-management/latest/overview/
Niewielkim jej minusem jest niewłaściwa kolejność kroków do wykonania, w szczególności w zakładce ‘First steps’. Zakładając, że użytkownik od razu będzie chciał przejść do konfiguracji, warto ponowić komunikat, np. o tym, że aplikacja nie jest przeznaczona dla projektów typu next-gen lub przynajmniej dodać tę informację w komunikacie błędu w trakcie konfiguracji. Podobnie sprawa ma się w przypadku konfiguracji ekranów. Zakłada się, że użytkownik dokonał już takiej konfiguracji, jeśli jednak projekt jest zupełnie nowy i nieskonfigurowany, wymaga to dodatkowej pracy i blokuje kolejne kroki instalacji RTM. W skrócie - dokumentacja na każdym opisanym kroku powinna zakładać opcje instalacji dla nowych i istniejących projektów, wtedy zdecydowanie cała procedura będzie dużo bardziej przejrzysta dla użytkownika.
Po stronie minusów zapiszemy również, że przy pierwszym wejściu na dany widok trzeba długo czekać na jego załadowanie. Jest to o tyle irytujące, że czasami zobaczymy dwa typy elementów sygnalizujących ładowanie elementów, na jakiś czas pusty ekran, a potem “kręciołę” w załadowanych polach zanim możemy wykonać działania na danym widoku. Na szczęście przy kolejnych ładowaniach widać, że treści się zbuforowały i czas ładowania jest już niezauważalny.
Warto docenić dość kompletne API, które umożliwia importowanie zarówno testów, jak i planów jak i wyników uruchomienia testów. Będzie to szczególnie przydatne w przypadku automatyzacji części testów.
Cena aplikacji zależy od instancji Jiry i zaczyna się od 10$ miesięcznie dla najmniejszych zespołów (do 10 osób).
Zalety
- Prostota i łatwość użycia narzędzia.
- Matryce śledzenia powiązań między obiektami.
- Przejrzystość funkcji w ramach struktury drzewiastej.
- API dla testów i ich wyników.
- Możliwość generowania przejrzystych raportów z procesu testowego, widocznych dla użytkowników aplikacji w Dashboardzie.
Wady
- Wolne działanie Jiry i ładowanie się widoków w ramach aplikacji RTM [po zaraportowaniu problemu dostaliśmy informację, że zespół intensywnie pracuje nad tym optymalizacją].
- Aplikacja nie jest przeznaczona dla projektów typu next-gen.
- Niespójności językowe w wersji polskiej.
Ciekawostki
Twórcy pluginu wiedzą, z kim ścigają się na rynku. Zobacz ich porównanie z dwoma największymi konkurentami:
