Testowanie wymagań
Gdy wśród znajomych zaczynamy rozmawiać o Quality Assurance (QA) bardzo często osoby nie związane z tą rolą, mają wyobrażenie, że zadaniem takiej osoby jest sprawdzenie końcowego produktu. Dobrym przykładem jest rola QA w automotive, gdzie taka osoba odpowiedzialna jest za sprawdzenie poprawnego wyprodukowania pewnych elementów do pojazdu. Gdy spojrzymy na świat IT, to możemy zauważyć, że bardzo często również i tu rola QA jest postrzegana jako ostatni element w trakcie wytwarzania oprogramowania. Jest to błędne podejście i zrozumienie roli. Należy pamiętać, że jednym z ważniejszych zadań jakie wykonuje osoba na stanowisku QA jest branie odpowiedzialności za prawidłowy przebieg procesu, nie tylko testowego ale całej fazy developmentu. W związku z tym, jak podaje literatura, QA powinien uczestniczyć w pracach już od początku powstawania projektu. Pytanie jakie się nasuwa w takim razie - co QA powinien robić/ za co jest odpowiedzialny w momencie gdy nie ma jeszcze gotowych funkcjonalności do sprawdzenia? Jednym z zadań, które powinien wykonywać QA już na starcie projektu jest testowanie wymagań!
Wymagania
Zapewne zastanawiacie się teraz jak można testować wymagania - czyli tak naprawdę opis przyszłej funkcjonalności. Zacznijmy od początku. Czym są wymagania? Według literatury wymaganie to:
A condition or capability that is necessary and is a usable representation. A requirement represents what is needed for a product, service, or result [1].
Druga część tej definicji jest bardzo istotna, bo wspomina o potrzebach. Czym są potrzeby można przeczytać tutaj: https://tsh.io/blog/user-stories-business-needs-software-development/ Business needs reprezentowane są przez wymagania. Należy również pamiętać, że wiele wymagań może realizować jedną potrzebę biznesową.
Wymagania możemy podzielić na kilka typów:
wymagania biznesowe,
wymagania interesariuszy,
wymagania rozwiązania,
Istnieje również podział na wymagania funkcjonalne i niefunkcjonalne.
Każdy z tych typów wymagań powinien być uwzględniony w trakcie trwania projektu i spisany, aby go nie pominąć. Istnieje parę metod na opisywanie wymagań wśród, których możemy wymienić te najbardziej znane czyli User Stories czy Uses Cases. Niezależnie jaką formę zapisu wybierzemy, to od momentu powstania wymagań możemy zacząć je testować. Dlaczego na tak wczesnym etapie powinniśmy to robić? Jak podaje literatura, dobrym argumentem na rozpoczęcie testów na tak wczesnym etapie jest to, że:
Many bugs emerge in software because of incompleteness, inaccuracy and ambiguities in functional requirements. That’s why it is highly important to test requirements and eliminate ambiguities before you start to develop a project [2].
Jak napisać dobre wymaganie?
W cytowanym właśnie fragmencie artykułu możemy znaleźć główne argumenty, dla których warto sprawdzać opis wymagań już na samym początku ich powstawania. Na co należy zwrócić uwagę, aby dostarczyć dobrej jakości wymaganie? Z pomocą przychodzi nam tabela zaprezentowana na gitconnected [3] i opisująca czym powinny charakteryzować się wymagania:
W tabeli zaprezentowano zasady jakimi należy kierować się przy tworzeniu wymagań. Trzymając się tych zaleceń możemy tworzyć dobre wymagania, niezależne od siebie a jednocześnie spełniające potrzeby biznesowe.
Innym równie dobrze znanym sposobem tworzenia wysokiej jakości wymagań jest stosowanie metody INVEST. Rozwijając ten skrót otrzymamy takie o to wartości:
I - Independent - nie posiadają żadnych elementów uzależniających skończenie naszego zadania od innych zespołów,
N - Negotiable - oznacza to, że do momentu rozpoczęcia prac, można nad treścią i zakresem zadania pracować,
V - Valuable - dostarcza nowej wartości, przede wszystkim dla użytkownika,
E - Estimable - da się je wycenić,
S - Small,
T - Testable - czyli zespół potrafi przetestować dane zadanie.
Jest to bardzo zbliżone podejście do tego, które zostało zaprezentowane w tabeli powyżej.
Dobrą zasadą, którą staram się kierować przy opisywaniu wymagań, a w szczególności na etapie tworzenia kryteriów akceptacji, jest zastanowienie się czy nie należałoby podzielić zadanie na mniejsze, gdy liczba kryteriów akceptacyjnych zaczyna przekraczać 4 punkty. Oczywiście nie jest to żelazna reguła, ale bardzo często się sprawdza. Pamiętajmy również, że opis zadania musi być dostosowany do naszych czytelników. Niektórzy lubią opisy bardzo szczegółowe, a inni wolą wysokopoziomowe opisy, tak aby mieli dużą swobodę działania. Niemniej jednak, niezależnie od opisu zadania należy sprawdzić jego jakość.
Error becomes error when it is born as truth.
Każdy kto zajmuje się utrzymywaniem jakości zna zasadę, że wcześniej wykryty błąd powoduje mniejsze koszty naprawy. Dlatego też należy utrzymywać wysoką jakość od samego początku projektu oraz powstawania dokumentacji. W tym celu istnieje parę metod sprawdzających czy spisane wymagania spełniają nasze kryteria jakościowe.
Pierwszym krokiem jaki możemy wykonać to walidacja wymagań. Jest to bardzo istotny element procesu zbierania wymagań. Polega ona na evaluating the business analysis information to ensure that it accurately reflects the stakeholder’s intent. Innymi słowy, prezentujemy to co usłyszeliśmy i pytamy się, czy dobrze zrozumieliśmy naszych interesariuszy. Pamiętajmy jednak, że nawet najlepsi interesariusze mogą pominąć pewne elementy, które mogą mieć istotny wpływ na implementację późniejszego rozwiązania.
Aby uniknąć tego typu sytuacji warto samemu prześledzić cały proces jaki ma realizować nasze tworzone wymaganie. Do przeprowadzenia tego typu analizy warto wykorzystać pisanie przypadków testowych już w fazie tworzenia opisu naszego wymagania. Osobiście wykorzystuje w tym celu język Gherkin, który wykorzystując język opisowy prowadzi nas przez kolejne kroki jakie w przyszłości będzie wykonywał nasz użytkownik lub sam system.
Jest to bardzo prosta forma, która niejednokrotnie pozwoli mi odnaleźć pewne nieścisłości lub brakujące informacje, które należało uzupełnić. Gherkin wywodzi się z tzw. Behavior-Driven Development i zawiera pewne stałe elementy, takie jak:
Feature - opis funkcjonalności jaką będziemy implementować/testować;
Scenario - opis co dany przypadek będzie sprawdzał, jaką ścieżkę chcemy przejść;
Given - warunek początkowy jaki należy spełnić aby można by było wykonać przypadek testowy;
When - opis akcji jaka wywołuje reakcję naszego systemu;
Then - opis reakcji naszego systemu na wcześniej wywołaną akcję
And - wykorzystywany do opisu większej liczby elementu, które muszą zostać spełnione w warunkach początkowych lub reakcji jakie nastąpią po wywołaniu akcji [5].
Are you ready?
Jak już wspomniałem wcześniej, QA powinien być włączany od samego początku trwania projektu i brać udział również przy tworzeniu dokumentacji projektowej, aby dbać o wysoką jakość dostarczanego produktu. Wyłapanie nieścisłości lub luk na wczesnym etapie tworzenia wymagań w bardzo istotny sposób zmniejszy nam koszty naprawy systemu w jego późniejszych fazach developmentu.
Niemniej jednak nie tylko QA powinien być odpowiedzialny za jakość dostarczanego produktu, ale również wszyscy interesariusze zaangażowani w ten proces. Każdy kto bierze udział w tworzeniu wymagań powinien zadać sobie pewne pytania, zaprezentowane przez Karolinę Zmitrowicz i Radosława Smilgina:
Czy wymaganie jest prawidłowe?
Czy wymaganie jest wykonalne?
Czy wymaganie jest mierzalne?
Czy wymaganie jest testowalne?
Czy wymaganie jest pojedyncze?
Czy wymaganie jest zrozumiałe?
Czy wymaganie posiada priorytet?
Czy wymaganie jest jednoznaczne? [4]
Gdy na wszystkie pytania odpowiemy sobie twierdząco, wtedy możemy przeprowadzić walidację z interesariuszami, czy dobrze zrozumieliśmy ich potrzebę, a następnie przejść do implementacji. Pilnując procesu tworzenia wymagań będziemy mieli większą pewność, że to co zostanie dostarczone jest dobrze zrobione i spełni oczekiwania naszych użytkowników ale co równie istotne ograniczy ryzyko wystąpienia komplikacji lub innych negatywnych skutków źle spisanego wymagania.
Bibliografia:
Mastering Business Analysis Standard Practices; Kelley Bruns, Billie Johnson
https://xbsoftware.com/qa-software-testing/full-qa-cycle/requirements-testing/
https://testuj.pl/blog/gherkin-techniczno-poetycki-jezyk/
Komentarze
Prześlij komentarz