Wyrocznia w miarę... czyli testowanie dokumentacji

Zaczynając naszą pracę machinalnie rzucamy się na dostępną dokumentację. W moim przypadku najczęściej są to wymagania i wysokopoziomowy opis architektury, rzadziej dokumenty funkcjonalne lub dokumentacja niskopoziomowa... gdyż ona z reguły (złej) jest tworzona post factum.



Ale skąd wiemy, że ta dokumentacja jest poprawna? Dlaczego - my testerzy – zakładamy, że w tym wypadku wszystko zostało zrobione bezbłędnie? Przecież dokumentacja:

• tak jak testowana aplikacja, jest tworzona przez wielu ludzi
• tak jak testowana aplikacja, musi mieć problemy z interfejsami
• inaczej niż testowana aplikacja, nie podlega formalnej weryfikacji merytorycznej (kompilacji), ponieważ nie ma kompilatorów rozumiejących ludzki język
• jest tworzona z konieczności , nie wnosząc niczego do merytoryki rozwiązania, a więc zbędna (?)

Dlaczego w związku z tym traktujemy ten byt projektu jako wyrocznię? Odpowiedzi jest wiele, ale wszystkie one sprowadzają się do podstawowego problemu: jest to jedyne, w miarę pełne, źródło naszej wiedzy o systemie (drugim takim źródłem są oczywiście rozmowy z zainteresowanymi uczestnikami projektu).
 

Skoro jest ono "w miarę" to dlaczego by tego źródła nie przetestować aby określić tę „miarę”? Wielu testerów testuje ją automatycznie, czytając i sporządzając notatki, które następnie wyjaśniają z programistami. Moje doświadczenie pokazuje, że, w znacznej mierze, dokumentacja traktowana jest jak pismo objawione. Jeśli nawet testerzy próbują testować dokumentację to, tak naprawdę, większość standardowych procesów realizacji projektu kompletnie nie wie co zrobić z raportowanymi incydentami.



Główny problem z testowaniem dokumentacji polega na tym, że weryfikujemy stronę merytoryczną, a nie logiczną, jak to zazwyczaj ma miejsce w przypadku testowania samego oprogramowania. W tym miejscu bardzo często podnosi się argumenty, że testerzy nie są architektami, nie znają się na programowaniu, itd., itp. Nie ma znaczenia czy jest to prawda czy nie! Faktem jest, że dokumentację można przetestować przyjmując "na wejściu" konkretne kryteria jakości dokumentacji.



Według mnie lista 5 kryteriów jest zupełnie wystarczająca do osiągnięcia celu testowania dokumentacji:

• spójność
• mierzalność
• jednoznaczność
• łatwość implementacji
• testowalność
   

Spójność:
Jest to kryterium, które ma nam udzielić odpowiedzi na pytanie, czy tester czytając tę dokumentację nie natrafił na oczywiste niespójności na poziomie interfejsów (np. przekazywanie zmiennej bool do wskaźnika typu integer), na poziomie logiki (np. tworzenie dodatkowego indeksu sztucznie dla jednej transakcji) lub na poziomie interfejsu użytkownika (np. przetwarzanie danej, która nie jest wymagana przez GUI).
Chodzi tutaj o badanie spójności pomiędzy wymaganiami biznesowymi, a ich konkretyzacją na poziomie specyfikacji technicznej.

Mierzalność:
To kryterium ma odpowiedzieć na pytanie czy w trakcie wykonywania testów będziemy w stanie weryfikować otrzymane wyniki? Przykładem defektów w tej kategorii będą zdania typu "system ma działać niezawodnie" lub "system ma obsługiwać wielu użytkowników".

Jednoznaczność:
To kryterium pozwoli na "przefiltrowanie" treści dokumentacji pod względem wszelkich opisów mogących generować jedno lub więcej rozwiązań, lub takich, które pozostawiają opracowanie rozwiązania na barkach programisty, np. "akceptacja danych następuje po wypełnieniu pól na formatce".

Łatwość implementacji:
To kryterium identyfikuje potencjalnie niebezpieczne i ryzykowne obszary. "Wyłapuje" wszelkie opisy, które są zagmatwane, napisane skomplikowanym językiem lub po prostu niezrozumiałe dla testera.

Testowalność:
Ostatnie kryterium odnosi się do tzw. "pozostałych". Jego celem jest zgrupowanie wszelkich "dziwnych", "podejrzanych", "pokręconych" fragmentów, w stosunku do których odpowiedź na pytanie "jak to przetestować" nie jest oczywista i prosta.


Ta lista kryteriów w sposób oczywisty nie nadaje się do testowania podręczników użytkownika czy innych materiałów wchodzących w zakres końcowego produktu.

Jaki jest cel testowania dokumentacji? Taki jak zwykle..., celem jest zidentyfikowanie ryzykownych obszarów i wyeliminowanie ich zanim jeszcze projekt przejdzie do fazy implementacji. Oznacza to, że praca testerów w tym zakresie powinna zacząć się jak tylko powstanie finalna wersja wymagań i powinna obejmować przynajmniej wymagania i dokumentację wysokiego poziomu.
Nie jest to najbardziej optymalny moment angażowania testerów, jednak zdaje się on jedyny możliwy w warunkach braku mechanizmów zapewniania jakości (QA).

Ze względu na wspomnianą powyżej „bezradność” projektu względem tego typu defektów, taka analiza staje się głównym źródłem wiedzy o tym, gdzie trochę bardziej „przycisnąć” rozwiązanie, bo tutaj stada defektów mogą być nadzwyczaj dorodne.



No dobrze..., ale co zyskamy inwestując czas i zasoby w takie przedsięwzięcie? Do głowy przychodzi mi poniższa lista:

• testerzy uzyskują przekrojową wiedzę nt. projektu i produktu oraz natury tych dwóch bytów
• testerzy poznają z góry o wiele więcej tak zwanych "ryzykownych" obszarów
• architekci uzyskują pierwszą opinię i defekty, których naprawa kosztuje jedynie czas poświęcony na przeredagowanie kilku paragrafów (czasami kilkuset)
• programiści po prostu dostają lepszą dokumentację
• zarząd minimalizuje koszty, bo zmiany są bardzo tanie (no dobra, tu się można kłócić) oraz sam produkt ma szansę na znaczenie lepszą jakość już na samym starcie
• kierownictwo projektu posiada wiedzę pozwalającą lepiej szacować kolejne etapy projektu oraz identyfikować wąskie gardła już teraz, gdy daty w projekcie zdają się być jeszcze odległe
• utrzymanie, gdyż projekt posiada mniej defektów związanych z architekturą
   

Dodam dla równowagi, że wady to:

• konieczność zatrudnienia zespołu testerów znacznie wcześniej niż standardowo
• konieczność wypracowania sposobu obsługiwania incydentów tego typu
   

W jaki sposób testować dokumentację? Jednym z najbardziej przydatnych, znanych mi sposobów jest lektura dokumentacji i spisywanie uwag. Następnie należy te uwagi przedyskutować wewnętrznie w zespole testów, ale najlepiej, z autorem dokumentu. Jednak ten proces zazwyczaj nie znajduje odzwierciedlenia w formalnym procesie. Dlatego trzeba pamiętać aby zaplanować sobie czas oraz umówić się z autorem zawczasu.

Osobiście testy dokumentacji wykonywałem, gdy oprogramowanie znajdowało się już w fazie implementacji. Robiłem to we własnym zakresie, gdyż nikt nie był zainteresowany tym zagadnieniem. 90% defektów zgłoszonych do dokumentacji zostało zamkniętych bez konkretnego komentarza (chyba, że za komentarz uznamy "brak czasu"). Ale z drugiej strony, gdy przeszedłem do testowania samego oprogramowania, lista obszarów określonych przeze mnie jako "ryzykowne" w większości wypadków okazywała się wielką pomocą w znajdowaniu siedlisk defektów. Szczerze mówiąc, szkoda, że wcześniej nikt nie pomyślał, że mogłyby być taniej.

Deweloperzy zazwyczaj niechętnie patrzą na zadania związane z dokumentacją. Postrzegają je jako dodatkową pracę, którą ktoś na nich wymusza, a która nie ma bezpośredniego przełożenia na ich dzieło. Biznes też niechętnie powraca do raz zamkniętych kwestii, dlatego, że w czasie kiedy programiści przystępują do realizacji ich wymagań, oni z reguły pochłonięci są czymś innym (np. formułowaniem wymagań do nowego projektu). Z tych względów proces testowania dokumentacji pozostanie raczej wewnętrznym procesem zespołu testów. Tutaj jednak namawiałbym do formalnych dyskusji i konsultacji.


Autor: Tomasz Zdanowicz © 2007 – 2013, twórca kultowego http://termometr.blogspot.com/
Artykuł pojawił się oryginalnie na blogu termometr.blogspot.com w 2007 roku