Specyfikacja wymagań podstawą testowania

Niemalże wszystko w projekcie IT zależy jakości wymagań. To stwierdzenie wydaje się oczywiste, jednak w wielu organizacjach ta banalna prawda wciąż nie została odkryta. Wpływ wymagań na jakość i przewidywalność całości projektu, widać na podstawie ich wpływu na jakość testowania oraz precyzję planowania tej fazy projektu.

Niezależnie od tego czy pracujemy w metodykach zwinnych, iteracyjnych, czy też w tradycyjnym podejściu kaskadowym (ang. Waterfall), w jakimś momencie musimy określić wysiłek niezbędny do przetestowania tworzonego systemu.

Planowanie testowania

Podejście do planowania testów bywa mniej lub bardziej skrupulatne. W zależności od posiadanego czasu, liczby testerów zaangażowanych w fazę testów (ang. test phase), godzin poświęconych na omawianie wymagań (ang. refinement’y) oraz posiadanej dokumentacji, szacujemy taski z należytą dokładnością i rozpisujemy wcześniej wszystkie możliwe przypadki testowe (ang. test case’y). Staramy się. Czasem jednak, pomimo, że wydaje nam się, że przecież planowaliśmy co i kiedy przetestujemy, okazuje się, że czasu do końca testów jest zbyt mało. Ba! Niekiedy tuż przed samym wydaniem (ang. release) strach zagląda nam w oczy, bo orientujemy się, że w sumie to dopiero zaczęliśmy testy, a tak naprawdę, one już powinny się kończyć. Czasem w takim momencie robimy nadgodziny, pomagają koledzy i koleżanki z zespołu, robimy szybkie testy eksploracyjne i staramy się dopiąć wszystko na ostatni guzik tak, aby klient otrzymał produkt bez błędów. Ale czy taki produkt dostaje? No niestety nie zawsze. 

Rola dokumentacji w planowaniu testów

Z czego wynika zatem niedoszacowanie czasu na testy i jak jemu zapobiegać? W tym artykule chciałabym zwrócić uwagę na to, jaką rolę w testowaniu oprogramowania odgrywa dokumentacja tworzona przez analityków biznesowych. Mają oni do dyspozycji różne notacje i języki modelowania (np. BPMN, UML), z których warto korzystać. Nie jest prawdą, ze testerzy nie lubią diagramów. Gdy są one poprawnie przygotowane, a co za tym idzie spójne i czytelne, wprost za nimi przepadają 🙂

Na wczesnym etapie analizy biznesowej dobrze jest rozważyć stworzenie modelu koncepcyjnego, który pozwoli na logiczne powiązanie często wielu elementów, a w konsekwencji ujawni ewentualne sprzeczności lub braki informacyjne. Model koncepcyjny skupia się na perspektywie biznesowej, a zatem możemy dzięki niemu zrozumieć logiczne powiązania poszczególnych elementów domeny biznesowej, znajdujących później swoje odzwierciedlenie w tworzonym systemie. 

Zrozumienie wymagań funkcjonalnych jest kluczem do przeprowadzenia testów funkcjonalnych. Podstawą przeprowadzenia tego rodzaju testów powinna być dobrze opracowana specyfikacja. Zapewnia ona zarówno warunki wstępne do testowania jak i podstawę do oszacowania wysiłku niezbędnego do przetestowania systemu. Niestety, zdarza się również, że dokumentacja produktu nie zawiera wymagań oczywistych. Bywa, że jest to z winy Klienta, który uznając je za oczywiste, po prostu ich nie podaje, a czasami analitycy biznesowi uznają, że wymagania są na tyle oczywiste, że nie warto ich opisywać.  

Podsumowując – niska jakość wymagań niestety zwykle przekłada się na niską jakość testów. Warto zatem korzystać z technik opisywania wymagań, które zostały szczegółowo przedstawione w BABOK Guide. Techniki takie jak słownik (ang. Glossary), przypadki użycia i scenariusze (ang. Use Cases and Scenarios), historyjki użytkowników (User stories), mapy myśli (ang. Mind Mapping) czy też wspomnianej modele opisujące procesy biznesowe i strukturę testowanego systemu. Z pewnością pomogą one w stworzeniu jednoznacznych, spójnych, zrozumiałych i weryfikowalnych wymagań dla systemu, które będą solidną podstawą jego budowania oraz testowania.

Moje rekomendacje

• Dbaj o jakość wymagań – pamiętaj, że jakość wymagań bezpośrednio przekłada się na jakość testów systemu.
• Stosuj modele (np. diagramy w UML i BPMN) w celu podniesienia jakości wymagań – wychwycenia błędów i niespójności.
• Upewnij się, że testerzy poprawnie rozumieją wymagania – stosuj techniki osiągania wspólnego zrozumienia.
• Angażuj testerów w weryfikację wymagań – pozwoli to na podniesienie ich jakości oraz przyczyni się do tego, że będą one poprawnie przetestowane.

Źródła

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. 2015.

Paulina Grębska

Business Analyst and QA expert