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 zakładamy - my testerzy - że nie ma ona błędów. Przecież dokumentacja:
- tak jak testowana aplikacja tworzona jest 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
Ale skoro jest ono "w miarę" to dlaczego go nie przetestować aby określić tę miarę? Wielu testerów robi to automatycznie, czytając i sporządzając notatki, które następnie klarują z programistami. Jednak moje doświadczenie pokazuje, że w znacznej mierze dokumentacja traktowana jest jak pismo objawione. A 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 to jest prawda czy nie! Faktem jest, że dokumentację można przetestować przyjmując "na wejściu" konkretne kryteria.
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 boolina 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). |
| 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ązanie lub 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 nie zrozumiał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 gotowego produktu.
Jaki jest cel testowania dokumentacji? To co zwykle..., 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.
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 uwagi, których naprawa kosztuje 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ż od samego startu
- kierownictwo projektu 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ą
- konieczność zatrudnienia zespołu testerów znacznie wcześniej niż standardowo
- konieczność wypracowania sposobu obsługiwania incydentów tego typu
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 komentarzem uznamy "brak czasu"). Ale z drugiej strony gdy przeszedłem do testowania samego oprogramowania, lista obszary określonych przeze mnie jako "ryzykowne" w większości wypadków okazywała się wielką pomocą w znajdowaniu siedlisk defektów i szczerze mówiąc szkoda, że nikt nie pomyślał, że mogły być tańsze.
Brak komentarzy:
Prześlij komentarz