Jak analizować wymagania z perspektywy testera? Część I

Dobre testowanie zaczyna się na długo przed napisaniem pierwszego testu. Wszystko zaczyna się od analizy wymagań i to właśnie ona w dużej mierze decyduje o tym, czy proces testowy będzie miał ręce i nogi. Tester, który potrafi skutecznie analizować wymagania, może wychwycić błędy, zanim jeszcze staną się problemem w kodzie.

Jakość testów jest tak dobra, jak jakość wymagań, na których się opierają. Precyzyjne, kompletne i jednoznaczne wymagania pozwalają tworzyć trafne przypadki testowe, czyli takie, które faktycznie sprawdzają zgodność systemu z tym, czego oczekuje biznes. Jeśli wymagania są niejasne, sprzeczne albo po prostu dziurawe, to nawet najlepszy tester nie uratuje sytuacji. Dlatego tak ważne jest, by tester był obecny już na etapie formułowania wymagań. 

Przygotowanie do analizy wymagań

Dobra (i skuteczna) analiza wymagań nie zaczyna się od czytania dokumentów, tylko od porządnych przygotowań. Tester musi wiedzieć, co chce znaleźć, gdzie tego szukać i z kim warto porozmawiać, żeby zrozumieć, o co w tym projekcie naprawdę chodzi.

Gromadzenie niezbędnej dokumentacji

Na dobrą dokumentację składają się:

1. Specyfikacja wymagań, która jest absolutną podstawą. To z niej wyciągamy warunki testowe i szacujemy pracę. Dobre wymagania zawierają i funkcjonalności („co system ma robić”), i niefunkcjonalności („jak ma to robić” – wydajnie, bezpiecznie, intuicyjnie).
2. Modele i diagramy, czyli rysunki, które mówią więcej niż opisy. Warto sięgnąć po:
   1. diagramy przypadków użycia, z których można od razu budować ścieżki testowe,
   2. diagramy przepływu danych, które pokazują, jak przetwarzane są informacje,
   3. diagramy stanów, dzięki którym łatwiej wyłapać przejścia warte przetestowania.
3. User stories i kryteria akceptacji, które często zawierają w sobie niezbędnik testowy w postaci konkretnych oczekiwań biznesowych.
4. Model koncepcyjny systemu, pozwalający zobaczyć ogólną logikę, która czasem umyka w szczegółach.

Warto też zerknąć na standardy dokumentacyjne w firmie: szablony, checklisty, narzędzia do śledzenia wymagań. Dzięki nim łatwiej wychwycić braki i zależności, które mogą mieć wpływ na testy.

Identyfikacja interesariuszy i źródeł wymagań

Za każdym wymaganiem stoi jakaś potrzeba, a za nią człowiek. Tester musi ustalić, kto ma wpływ na system i kto z niego korzysta. Nie chodzi tylko o oficjalnych decydentów. Często najważniejsze potrzeby mają ci, o których nikt formalnie nie pyta.

Warto rozmawiać z różnymi grupami – od klienta końcowego po użytkowników wewnętrznych. Skąd brać informacje?

• z wywiadów i rozmów z interesariuszami,
• z obserwacji istniejących procesów,
• z analizy wcześniejszych systemów (tzw. „archeologia projektowa”),
• z warsztatów i burz mózgów z użytkownikami.

Czasem największym odkryciem są potrzeby, których nikt nie umie nazwać wprost. Techniki takie jak prototypowanie czy obserwacja „w terenie” pomagają wyłapać właśnie te ciche oczekiwania. Tester powinien też być aktywnym uczestnikiem spotkań projektowych – nie tylko słuchać, ale zadawać pytania. To często właśnie jego dociekliwość pomaga zauważyć nieścisłości, które umykają analitykom czy deweloperom skupionym na implementacji.

Na koniec – wspólny język. Warto od razu na początku zbudować słownik projektowy. Nawet najprostsze słowo potrafi mieć dwa znaczenia. „Klient” to dla jednego użytkownik, dla drugiego zleceniodawca. Precyzja w terminologii to mniej nieporozumień w przyszłości.

Ważne aspekty analizy wymagań

Analiza wymagań to konkretna praca, która ma pomóc stworzyć dobre testy. Żeby miało to sens, tester powinien skupić się na trzech istotnych aspektach: kompletności i spójności, rozróżnieniu typów wymagań oraz wykrywaniu niejasności i luk.

Kompletność i spójność

Brakujące lub niespójne wymagania to jak puzzle z brakującymi kawałkami – nic z tego nie wyjdzie. Dlatego tester powinien zadbać o to, by wszystkie elementy układanki do siebie pasowały.

Model koncepcyjny pomaga zobaczyć całość – zależności, logikę i elementy, które znikają, gdy patrzymy tylko na pojedyncze wymagania. Z kolei techniki wizualizacji (takie jak macierze śledzenia, diagramy kontekstowe, grafy zależności) pomagają zrozumieć, co się stanie, jeśli zmienimy jedno wymaganie – i jak ta zmiana odbije się na innych. Spójność warto sprawdzać „parami” – czasem dwa wymagania na pierwszy rzut oka są OK, ale razem się wykluczają. Klasyczny przykład? System ma być superbezpieczny i maksymalnie prosty w obsłudze. A wiadomo, że więcej zabezpieczeń to często mniej wygody.

Dobrze sprawdzają się też checklisty z pytaniami kontrolnymi typu:

1. Czy opisano wszystkie interfejsy zewnętrzne?
2. Czy są scenariusze wyjątkowe?
3. Czy coś ważnego nie zniknęło między wersjami dokumentu?

Wymagania funkcjonalne vs. niefunkcjonalne

Dobry tester rozróżnia co system ma robić, a jak dobrze ma to robić i wie, że każde z tych podejść wymaga innego rodzaju testów. Funkcjonalne mówią: „System powinien umożliwiać zmianę hasła”. OK, to testujemy, czy działa. Niefunkcjonalne mówią: „System powinien działać szybko, bezpiecznie i niezawodnie”. Trzeba zadać pytanie: jak szybko? jak bezpiecznie? jak bardzo niezawodnie? I tu pojawia się rola testera jako doprecyzowującego pytacza: „System powinien być szybki”. Brzmi fajnie, ale co to znaczy? Dużo lepiej, gdy wiemy: „90% zapytań ma być obsłużonych w <1s przy 100 użytkownikach”.

Wykrywanie niejasności i luk

Niejasności są wrogiem projektu. Na etapie kodowania może być już za późno, żeby je wyłapać, dlatego tester musi wchodzić w tryb „sceptyka” i zadawać pytania, które wyciągną na światło dzienne wszystkie niedopowiedzenia.

Stworzony wcześniej słownik projektowy może więc okazać się bardzo przydatny. Słowa typu „klient”, „moduł”, „transakcja” potrafią znaczyć różne rzeczy dla różnych osób – dopóki ich nie zdefiniujemy. Kolejną rzeczą jest kwestionowanie ogólników. „Szybko”, „intuicyjnie”, „odpowiednio” to nie są wymagania. Tester powinien je zamieniać na liczby, wartości graniczne, scenariusze.

Scenariusze graniczne to świetna metoda wykrywania braków. Pytania w stylu „Co się stanie, gdy…?”, „A co jeśli użytkownik zrobi to odwrotnie?”, „A jeśli dane będą nietypowe?” często prowadzą do ważnych odkryć. Mapy myśli pomagają eksplorować wszystkie kąty wymagania i odkrywać, gdzie brakuje konkretu. Korzystając z techniki 5x „dlaczego” zadawaj pytania aż do sedna, dopóki nie rozbijesz wymagania na czynniki pierwsze i nie zrozumiesz jego prawdziwego celu.

Techniki analizy wymagań

Skuteczna analiza wymagań nie polega wyłącznie na czytaniu dokumentacji. Dobry tester korzysta z różnych narzędzi i metod, które pomagają mu dokładnie zrozumieć, jak system powinien działać i gdzie mogą kryć się ryzyka. Poniżej opisane techniki to jedne z najczęściej stosowanych i najbardziej użytecznych w praktyce testowania.

Analiza CRUD

CRUD – czyli Create, Read, Update, Delete – to podejście, które pozwala sprawdzić, jak system zarządza danymi. Warto przyjrzeć się każdej z tych operacji z osobna:

1. Create – gdzie i jak tworzone są nowe dane? Czy dane wejściowe są walidowane?
2. Read – czy dane są poprawnie wyświetlane, filtrowane i sortowane? Czy użytkownik widzi to, co powinien?
3. Update – jakie zmiany można wprowadzać i kto ma do nich dostęp? Co z integralnością danych przy aktualizacji?
4. Delete – czy usuwanie danych jest bezpieczne i nie powoduje skutków ubocznych? Czy istnieją mechanizmy cofnięcia?

Tworząc prostą macierz CRUD, tester może szybko sprawdzić, które operacje są obsługiwane dla poszczególnych typów danych i wychwycić braki w wymaganiach.

Mapy myśli i diagramy

Techniki wizualne pomagają spojrzeć na system z szerszej perspektywy i łatwiej wychwycić powiązania między elementami.

1. Mapy myśli sprawdzają się przy eksploracji wymagań – można szybko zidentyfikować moduły, funkcje, zależności i potencjalne pytania.
2. Diagramy UML i BPMN dostarczają bardziej formalnego ujęcia:
   1. przypadki użycia – do analizy interakcji użytkowników z systemem,
   2. diagramy aktywności – do rozpoznania głównych i alternatywnych ścieżek działania,
   3. diagramy stanów – do analizy przejść między różnymi stanami obiektu lub systemu.

Dobrze opracowany diagram może ułatwić zidentyfikowanie scenariuszy, które nie zostały opisane w dokumentacji tekstowej.

Sesje zadawania pytań

Zadawanie właściwych pytań to jeden z najskuteczniejszych sposobów pogłębiania analizy. Takie sesje warto planować i prowadzić świadomie – nie tylko jako rozmowy, ale jako narzędzie do weryfikacji wymagań.

1. Przygotuj listę tematów, które wymagają wyjaśnienia.
2. Zaczynaj od pytań ogólnych, a potem schodź do szczegółów.
3. Zadawaj pytania otwarte, które prowokują do szerszej wypowiedzi.

Szczególnie ważne są pytania o znaczenie terminów („Co rozumiesz przez...?”) oraz pytania eksploracyjne („Co jeśli użytkownik zrobi...?”, „Jakie są wyjątki?”). Takie pytania często pozwalają dotrzeć do wymagań, które były domyślne, niedopowiedziane albo po prostu pominięte.

Na tym kończymy pierwszą część artykułu. W drugiej skupimy się na:

1. Przekształcaniu wymagań w przypadki testowe – powiemy, jak przekuć teoretyczną wiedzę o wymaganiach w praktyczne scenariusze testowe, jak identyfikować warunki testowe i ustalać priorytety testowania. Omówimy również techniki projektowania przypadków testowych, które zapewnią optymalne pokrycie.
2. Współpracy z zespołem projektowym, czyli jak efektywnie komunikować się z analitykami biznesowymi, aktywnie uczestniczyć w przeglądach wymagań i konstruktywnie przekazywać informację zwrotną. Dobra współpraca międzyzespołowa to często podstawa sukcesu projektu.
3. Dokumentacji i śledzeniu zmian, czyli o tym, jak zarządzać powiązaniami między wymaganiami a testami przy pomocy matryc śledzenia oraz jak radzić sobie ze zmianami wymagań, które są nieuniknioną częścią procesu wytwórczego.

Zbierzemy też najlepsze praktyki analizy wymagań i wskażemy, jak przekładają się one na jakość końcowego produktu.