Czy zdarzyło Ci się kiedyś rozwijając swój produkt, stracić perspektywę oczekiwań, wymagań i kierunku, w którym Twój projekt dąży? Czy spotkałeś się z sytuacją, gdzie właściciele Twojego produktu co chwile zmieniają zdanie lub, co gorsza, nie mogą dojść do porozumienia odnośnie funkcjonalności?
Dla mnie powyższe problemy były codziennością. Długo brakowało mi narzędzia, którym można opisać, zlecić, a nawet raportować testy, które bezpośrednio i jasno powiązane będą z wymaganiami. Szczęśliwie, pracując z moim obecnym klientem – odkryłem oprogramowanie Polarion ALM.
Czym jest Polarion?
Polarion jest oprogramowaniem typu ALM (Application Lifecycle Management) i jest to firmowany przez Siemensa produkt służący do zarządzania cyklem życia aplikacji. Łączy w sobie wiele funkcji: zaspokaja potrzeby właściciela produktu, projektanta, a także testera. Ułatwia pracę nad rozwojem produktu w wielu branżach, od rozwoju oprogramowania po urządzenia mechaniczne. Korzystam z niego już od 4 lat jako inżynier testów do dokumentowania testów urządzeń automatyki dla rolnictwa opartych o PLC (sterowniki karuzel udojowych, zgarniacze nieczystości, automaty myjące). W tym samym czasie koledzy z działów mechaniki z powodzeniem posługują się nim do zarządzania rozwojem części mechanicznych w tych samych projektach. Dzięki czemu uzyskujemy synergię działania posługując się jednym i tym samym narzędziem – co daje dużą korzyść dla organizacji i porządku w projekcie.
Oczywiście, jest to oprogramowanie płatne – producent udostępnia je w chmurze, jak i z możliwością instalacji na infrastrukturze klienta. Jednak dostępna jest darmowa wersja demo z założonym już projektem, co pozwala na dokładne zapoznanie się z dostępnymi opcjami jeszcze przed decyzją o zakupie.
Co to jest ALM?
Zanim jednak zagłębimy się w tajniki samego Polariona, warto dodać kilka słów o tym, czym właściwie są programy Application Lifecycle Management. Oprogramowanie ALM pozwala na zaplanowanie produktu, zdefiniowanie jego wymagań, definicję funkcjonalności, powiązanie ich z testami aż do finalnego wdrożenia. Jest to więc opcja kompletna – pozwalająca sprawować kontrolę na przebiegiem cyklu od jego początku do końca. Umożliwia ustalenie kamieni milowych produktu oraz śledzenie postępu prac za pomocą statystyk. Narzędzie jest dedykowane osobom piastujących następujące stanowiska w projekcie:
- właściciele projektu,
- deweloperzy/projektanci,
- testerzy,
- analitycy biznesowi,
- menadżerowie.
Co kryje wnętrze?
Poniżej spróbuję przestawić podstawy oprogramowania typu ALM z perspektywy testera – na przykładzie wersji demo, która jest dostępna dla każdego po uprzednim zarejestrowaniu się na stronie Polariona. Zainteresowanych zapraszam na stronę, a teraz zajrzymy do wnętrza oprogramowania i sprawdzimy, co przygotował dla nas Siemens.
W artykule przyjrzymy się sposobowi prezentacji wymagań z perspektywy inżyniera testów, czyli temu jak powiązywać wymagania z przypadkami testowymi, ułożyć z tych par Test Runs, a następnie je wykonać.
Służący tu za przykład projekt DrivePilot w wersji demonstracyjnej jest fikcyjnym systemem wspomagającym prowadzenie samochodu i to na jego przykładzie prezentowane będą możliwości Polariona.
Wymagania
Według mnie – jak i według wielu testerów z branży – absolutnie podstawowym kluczem do optymalnego zarządzania rozwojem produktu z poziomu oprogramowania ALM jest zdefiniowanie jego wymagań. Nie mam tutaj na myśli jakichkolwiek wymagań, które brzmią jak przypadkowe ogólniki, ale dyrektyw precyzyjnych. Takich, w których każde słowo niesie za sobą konkretną informację o funkcjonalności. Doskonale wiadomo, że niedokładne, niechlujnie napisane wymagania zamiast pożytku mogą przynieść kłopoty – zwłaszcza w przypadku błędnej interpretacji (np. przy pisaniu testów), przez co generują niezliczoną ilość pytań skierowanych w stronę właściciela produktu, przyczyniają się do zatracenia bazowych wytycznych, sprowadzają chaos i niezrozumienie w zespole pracującym nad projektem.
Twórcy Polariona doskonale zdawali sobie sprawę z powyższych aspektów pracy w wymaganiami i ich kluczowości w konstrukcji produktu. Dlatego też w Polarionie istnieją dwie metody na wyświetlanie wymagań: LiveDoc oraz Tree View.
Widok LiveDoc
LiveDoc przypomina nieco klasyczny dokument tekstowy z Worda, jednak z dodatkowymi możliwościami śledzenia danych. W LiveDocu wymagania widoczne są jedne pod drugimi z wcięciami w przypadku wymagań, które zależą od innych (nadrzędnych względem nich). Oznaczone mogą być numerami wersji oraz okraszone dodatkowym tekstem, np. wstępem lub opisem produktu. Dodatkowo pod każdym pojedynczym wymaganiem widoczne są symbole Severity (np. Must Have, oznaczający że dana funkcjonalność jest niezbędna w produkcie) oraz stan akceptacji przez interesariuszy (np. Approved). Bardzo wygodne i przejrzyste zobrazowanie wymagań. Szczególnie polecam wszystkim fanom list priorytetowych z krótkimi opisami, gotowych ściągawek z wymaganiami zawsze dostępnych pod ręką.
Widok Tree View
Nieco inaczej natomiast można przeglądać wymagania w Tree View, który stał się z czasem moim faworytem.
Jest to widok, z którego osobiście korzystam o wiele częściej niż z LiveDoc. Widać w nim więcej informacji na temat wymagania (takie jak jego kategorię, personel i dodatkowe pola) wraz z komentarzami innych użytkowników (ważne!), które niejednokrotnie zawierają przydatne informacje o danej funkcjonalności, umożliwiając nam jej pełne i przede wszystkim właściwe zrozumienie.
Ciekawą częścią tego widoku wymagania jest sekcja Approvals.
Jest to nic innego jak system zatwierdzania wymagań poprzez wielu użytkowników. W przypadku, w którym mielibyśmy kilka osób z nie do końca spójnym zdaniem odnośnie danej funkcjonalności można uruchomić głosowanie. Dopiero po uzyskaniu kompletu głosów wymaganie może osiągnąć status Approved, a wtedy niemożliwa się stanie jego modyfikacja bez uprzedniej ręcznej zmiany statusu na np. Draft. Uważam to za świetny komponent ułatwiający komunikację i podejmowanie decyzji bez zbędnych dyskusji i tworzenia mailowych tasiemców.
Przypadki testowe, czyli Test Case’y
Spójrzmy następnie na przypadki testowe (test case’y). Są one niczym innym, jak scenariuszami testu, który można podpiąć do konkretnego wymagania. Pisze je osoba projektująca testy (może to być właściciel produktu, jak i sam tester) w postaci dokumentu tekstowego opisującego kroku niezbędne do sprawdzenia danej funkcjonalności. Każdy krok ma przypisany oczekiwany rezultat i podczas wykonywania testu, sprawdzając ten rezultat można umieścić przy krokach wynik Pass/Failed/Blocked/Not applicable i opcjonalnie napisać kilka słów werdyktu. Dodatkowo każdy przypadek może zawierać parametry pomocne przy odfiltrowywaniu go spośród innych, takie jak Status (Active, Inactive, Draft, Approved), projekt, do którego należy lub osoby, do których jest przypisany.
Sekwencje testowe, czyli Test Runy
Następnym krokiem jest zebranie naszych przypadków testowych i ułożenie z nich sekwencji testów, czyli test runa, który później wykonamy.
Widzimy powyżej kilka przykładowych, wykonanych już z różnymi rezultatami, test runów. Tworząc taką sekwencję, należy nadać jej tytuł sugerujący zakres przypisanych do niej testów, może to być np. zakres funkcjonalności czy wersja testowanego programu.
Na tym ekranie możemy skorzystać z przycisku zębatki, a następnie „Select test cases” aby dobrać przypadki, a następnie aby „Execute Test” przejdziemy do ekranu wykonywania samego testu. Wykonując go i przydzielając mu rezultat otrzymujemy test record, czyli wpis z datą wykonania, nazwą test runa oraz wynikiem testu (Pass/Fail/Blocked/Not applicable).
Wielokrotne wykonanie tego samego przypadku w różnych sekwencjach testowych da nam wiele wpisów testowych z każdego z tych test runów. Natomiast ponowne wykonanie w tym samym test runie raz już odhaczonego test case’a spowoduje nadpisanie poprzedniego wyniku. Finalne werdykty z poprzednich prób będą cały czas widoczne, a następujące po nich werdykty otrzymają nagłówek „Retest comment”.
Co jeśli wykonany test będzie miał wynik negatywny?
Wtedy poza wpisem z testu i jego rezultatem otrzymamy jeszcze fault report – dodatkowy raport w osobnej zakładce stanowiący informację o nieprawidłowym działaniu systemu. Znajdują się w nim informacje takie jak Severity (Low, Medium, High), Status (Open, Closed, Rejected i pozostałe, zgodne z przepływem pracy).
Fault reports są pomocne przy identyfikowaniu niezbędnych poprawek w produkcie, a sposób opisywania błędów w Polarionie jest zbliżony do tego, co stosuje np. Jira, więc osoby korzystające z produktu Atlassiana poczują się tutaj jak w domu.
Na zakończenie wspomnę jednak o jeszcze jednej funkcji Polariona, która niesamowicie ułatwia pracę nad wszystkimi tworzonymi elementami, zarówno tymi opisanymi w tym artykule (wymaganie, test case, test run, test record), jak i pozostałymi. Jest to funkcja filtrowania przy wyszukiwaniu. Na pierwszy rzut oka niepozorna, bo czym niezwykłym jest zaznaczanie pól w celu zawężenia wyników, ale w Polarionie możliwe jest tworzenie skomplikowanych kwerend wyszukiwania.
Przykładowo, jeśli chcielibyśmy wyfiltrować wymaganie ze statusem Approved / Zaakceptowany, stworzone przez użytkownika System Administrator oraz nieposiadające żadnych załączników, możemy tego dokonać klikając na znak dodawania przy polu wyszukiwania, zaznaczając Approval State: Approved, Author: System Administrator a następnie Has Attachments: No.
Osobiście uważam to za dobry pomysł i świetną funkcję, która skraca wyszukiwania i nie pozwala użytkownikowi błądzić w setkach wpisów.
Podsumowanie
O zaletach Polariona można by wiele napisać, ale nie jest to broszura reklamowa, a kilka słów zachęty od kolegi po fachu, więc pokrótce – dla kogo jest to oprogramowanie?
Dla każdego kto chce mieć kontrolę nad sytuacją, więc zarówno dla menadżera jak i analityka. Dla każdego, kto ceni swój czas i lubi przejrzyste struktury. A z mojej perspektywy – szczególnie dla testerów i osób po kursie ISTQB, którzy znajdą tutaj dobrze sobie znane hasła jak test case, test run, test record czy requirement. Ponieważ nie byłoby przesadą, gdybym powiedział, że Polarion jest niejako uosobieniem metodyki testów według ISTQB – tak popularnej i znanej w naszym kręgu.
Zachęcam Cię do dalszego zapoznanie się z tematem już samodzielnie (link do demo). Powodzenia!
Zostaw komentarz