Przywództwo w testowaniu: dokumentacja

Uwaga redakcji: Witamy w serii „Leadership In Test”, której autorem jest guru testowania oprogramowania i konsultant Paul Gerrard. Seria ma pomóc testerom z kilkuletnim doświadczeniem — zwłaszcza pracującym w zespołach zwinnych — doskonalić się w rolach liderów testów i menedżerów.

W poprzednim artykule przedstawiliśmy manifest ryzyka, który ma pomóc menedżerom. W tym artykule zadamy odwieczne pytanie: „Ile testów wystarczy?”. Zdradzimy odpowiedź: zależy to od interesariuszy.

Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Leadership In Test Paula, który gorąco polecamy wszystkim, którzy chcą zgłębić ten i inne tematy. Jeśli się zdecydujesz, użyj naszego wyjątkowego kodu kuponu QALEADOFFER, aby otrzymać 60 USD zniżki od pełnej ceny kursu!

Niezależnie od projektu, organizacji czy podejścia zawsze znajdzie się miejsce na dokumentację. Dobra dokumentacja jest nieoceniona — zapewnia użyteczny zapis podejścia, zakresu, planów, projektów oraz wyników działań analitycznych, programistycznych i testowych.

W tym artykule omówię:

Wartość dokumentacji
Pułapki szablonów i kopiowania/wklejania
Rodzaje dokumentacji testów
Wskazówki dotyczące projektowania dokumentacji

Zaczynajmy.

Wartość dokumentacji

W projektach ustrukturyzowanych dokumenty są zwykle uznawane za produkty dostarczane same w sobie. W środowiskach zwinnych lub ciągłych dokumentacja może powstawać jako produkt uboczny działań o większej lub mniejszej wartości.

Pisanie dokumentów może być głównym zajęciem profesjonalnych autorów dokumentacji technicznej, ale dla większości praktyków jest to obowiązek — niezależnie od tego, jak bardzo może być użyteczny. Choć dla niektórych osób pisanie dokumentów może być nudne, prawdziwy problem z dokumentacją polega na tym, że w wielu kontekstach większość dokumentacji jest po prostu stratą czasu. Ma niewielką wartość, jest nieaktualna, niedokładna — albo wszystkie te określenia są prawdziwe.

Każdy menedżer testów pisał strategie testów, których ludzie nie czytali lub których nie popierali. Testerzy tworzą całe tomy planów testów, skryptów i raportów, a jedyną wartościową dla interesariuszy treścią są jednostronicowe podsumowania na początku lub na końcu.

Wszyscy pisaliśmy dokumenty, o których wiemy, że mają niewielką wartość i że nikt ich nie przeczyta.

Wynika to z typowych problemów z dokumentacją, które napotykamy w projektach — zarówno dużych, jak i małych. W przypadku każdego pisanego przez nas dokumentu musimy odpowiedzieć na kilka pytań:

Jaki to rodzaj dokumentu? Polityka lub strategia, podejście lub plan, projekt lub implementacja, czy wynik i jego interpretacja?
Jaki jest cel dokumentu?
Jaka treść jest potrzebna do osiągnięcia tego celu?
Jakie źródła wiedzy są potrzebne do utworzenia tej treści?
Jeśli dokument musi zmieniać się w czasie, w jaki sposób będzie utrzymywany?
Jaki poziom szczegółowości jest wymagany?

Jako menedżer testów lub zespół musicie ustalić, jakie rodzaje i formaty dokumentacji są odpowiednie oraz — jeśli mają stanowić dokładne zapisy lub tak zwane żywe dokumenty — w jaki sposób będą utrzymywane.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Have an account? Log In

Pułapki szablonów i kopiowania/wklejania

Jeśli w ramach projektu ustalono, że potrzebny jest określony dokument, na przykład plan testów systemu lub rejestr ryzyka, kuszące może być znalezienie w internecie gotowego szablonu takiego dokumentu (lub wielu innych rodzajów dokumentów).

Niektóre szablony mogą twierdzić, że są zgodne z określonym standardem lub konwencją oraz że zostały pobrane i wykorzystane tysiące razy. Czasami szablon może wydawać się idealnie dopasowany do Twojego celu. Jak jednak zobaczymy, nawet jeśli spis treści wygląda kompleksowo, może wpędzić Cię w kłopoty.

Może się również zdarzyć, że Ty lub inne osoby w Twojej firmie przygotowałyście podobny dokument na potrzeby wcześniejszych projektów. Możesz ulec pokusie skopiowania i zmiany nazwy tego dokumentu, zmiany odwołań do starego projektu oraz edycji treści tak, aby pasowała do obecnych potrzeb.

Ostrzeżenie: Z mojego doświadczenia jako niezależnego recenzenta wynika, że jest to bardzo częste i często stanowi prawdziwy problem.

Po pierwsze, zwykle od razu widać, że wykonano kopiowanie lub edycję. Język użyty w tekście często wydaje się oderwany od projektu, a wszędzie występują luki i zbędny tekst. Dlaczego tak się dzieje?

Korzystanie z gotowego szablonu lub istniejącego dokumentu jako źródła wiąże się z kilkoma zagrożeniami:

Wygląda on kompleksowo, ale może obejmować tematy, które są nieodpowiednie, a pomijać inne, które są niezbędne.
Zawiera nagłówki dokumentu, ale absolutnie żadnych wskazówek dotyczących tego, jaka treść jest odpowiednia dla poszczególnych nagłówków.
Może zawierać tekst, który wygląda na możliwy do ponownego wykorzystania i został skopiowany bez zmian z wcześniejszego, niezwiązanego projektu, ale może on wywoływać błędne wrażenie albo być niedokładny lub niekompletny.

Korzystanie z szablonów w celu uzyskania nagłówków i podstawowego układu formatowania może być pomocne, ale główny problem z szablonami jest następujący:

*Skorzystanie z szablonu może zaoszczędzić trochę czasu; zagrożenie polega na tym, że poświęcisz zbyt mało uwagi pisaniu.*

Pokusa związana z szablonami polega na tym, by nadmiernie im ufać, a następnie lać wodę w poszczególnych sekcjach. W końcu możesz pomyśleć, że dokument służy jedynie do „odhaczenia pola” i i tak nikt go nie przeczyta. Zagrożenie związane z szablonami polega na tym, że przestajesz myśleć i tworzysz dokument, który ma niewielką wartość.

Rodzaje dokumentacji testów

W tej sekcji przyjrzymy się różnym formom dokumentacji testów i omówimy wybrane kwestie dotyczące projektów ustrukturyzowanych lub zwinnych/ciągłych w porównaniu z tradycyjnym modelem kaskadowym.

Podstawowy zestaw dokumentów testowych zwykle obejmuje następujące kategorie:

Zasady i strategia (czasami nazywane głównym planem testów)
Definicja testów (nazywana też, co może wprowadzać w błąd, specyfikacją lub planami testów)
Projektowanie testów
Przypadki testowe
Procedury testowe lub skrypty
Wykonanie testów
Harmonogram
Dziennik
Raport z testów

Powyższy zakres rodzajów dokumentów obejmuje definicję procesu testowania, kluczowe działania związane z definiowaniem i wykonywaniem testów oraz raportowanie.

Istnieje kilka innych dokumentów związanych z testami, które w bardziej biurokratycznych środowiskach obejmowałyby definicje środowisk testowych i procesy zarządzania nimi, procedury akceptacji, procesy zarządzania incydentami i tak dalej (w jednym z przyszłych artykułów omówimy zarządzanie incydentami).

Innym oczywistym pominięciem w powyższym zestawieniu byłby ogólny plan lub harmonogram działań testowych. Harmonogram nie jest właściwie dokumentem testowym, lecz częścią ogólnego planu projektu dla projektu ustrukturyzowanego (w jednym z przyszłych artykułów omówimy również planowanie harmonogramu, więc zaglądaj tu na bieżąco!).

Zasady, strategia, główny plan testów

*Cel*	Polityka zwykle obejmuje całą organizację i zawiera podzbiór tematów dotyczących wszystkich projektów. Strategia zwykle obejmuje pojedynczy projekt (lub aplikację) Ogólnie rzecz biorąc, strategia określa decyzje dotyczące logistycznych kwestii podejścia, przekazywania zadań, odpowiedzialności, środowisk itp. Niektóre z tych decyzji można podjąć z wyprzedzeniem i udokumentować w strategii Niektórych decyzji nie można podjąć obecnie, ale strategia może dokumentować proces, metodę lub informacje, które umożliwią ich podjęcie (w projekcie) W przypadku niepewnych sytuacji lub nieplanowanych zdarzeń, w których konieczne jest podjęcie decyzji, strategia będzie określać ogólne zasady (lub proces), których należy przestrzegać.
*Treść*	Interesariusze, cele, kluczowe ryzyka budzące obawy Zasady/podejście testowe, które należy przyjąć, np. podejście oparte na testowaniu opartym na ryzyku Proces testowania (etapy testowania): cele i zakres kryteria akceptacji metody, techniki rezultaty (dokumenty) odpowiedzialność niefunkcjonalne/techniczne działania testowe polityka zarządzania dostawcami testów proces zarządzania incydentami źródła danych testowych środowiska testowe strategia narzędzi/automatyzacji Formaty/szablony dokumentacji
*Źródła*	Interesariusze, użytkownicy, analitycy biznesowi, deweloperzy, zespoły operacyjne
*Utrzymanie*	Zwykle jednorazowy dokument zdefiniowany dla projektu lub programu
*Uwagi dotyczące podejścia zwinnego/ciągłego* Strategia testów dla projektów zwinnych wykorzystujących na przykład Scrum będzie prawdopodobnie dość krótka i będzie obejmować zaledwie kilka stron (jeśli w ogóle zostanie udokumentowana). Proces testowania może nie mieć etapów, ale prawdopodobnie będzie zawierał definicję testowania na różnych poziomach. Na przykład: Testowanie w sprincie lub iteracji Testowanie na potrzeby wydania Testowanie integracji systemu (z innymi systemami lub interfejsami) Testowanie przez użytkowników (w sprincie i/lub akceptacja na poziomie wydania). Sposób wykorzystywania narzędzi podczas testowania przez deweloperów (oraz stosowania na przykład BDD lub TDD) prawdopodobnie nie będzie udokumentowany, ale oczekuje się, że zespoły deweloperskie wypracują podejście i będą współpracować z innymi członkami zespołu podczas wprowadzania nowego kodu. Rola testera może polegać na interaktywnym testowaniu funkcji w miarę ich udostępniania przez deweloperów lub na pełnieniu funkcji trenera testowania dla reszty zespołu. Podobnie jak w przypadku korzystania z narzędzi i/lub TDD, sposób pracy będzie ewoluował z czasem i może nigdy nie zostać formalnie udokumentowany.

Definicja testów (projektowanie, przypadki, procedury)

*Cel*	Zademonstrowanie przepływu lub identyfikowalności między źródłami wiedzy a testami, które mają zostać wykonane Udokumentowanie pokrycia (względem wielu modeli) aspektów wymagań, funkcji systemu lub zachowania użytkowników Umożliwienie interesariuszom przeglądu zakresu, podejścia, pokrycia i decyzji podjętych przy tworzeniu testów, które mają zostać zastosowane Zapewnienie instrukcji wykonywania testów na uzgodnionym poziomie szczegółowości.
*Treść*	Zakres testowania – zarówno na wysokim poziomie, np. funkcje, jak i na niższym poziomie, np. modele zachowania Pokrycie testów względem elementów objętych zakresem (np. macierz pokrycia wymagań lub inny model testowy) Przypadki testowe identyfikujące funkcje, warunki wstępne, dane wejściowe i warunki końcowe (w tym oczekiwane rezultaty) Procedury testowe wielokrotnego użytku do wykonywania wybranych przypadków testowych.
*Źródła*	Interesariusze, użytkownicy, wymagania, projekty i specyfikacje
*Utrzymanie*	Co do zasady, przy stałych wymaganiach powinna istnieć jedna uzgodniona wersja tych dokumentów W przypadku zmian wymagań lub zakresu testerzy będą musieli dostosować dokumenty, utrzymywać identyfikowalne aspekty dokumentacji oraz prowadzić dokumentację zarządzania konfiguracją lub rejestr zmian.
*Uwagi dotyczące podejścia zwinnego/ciągłego* Obszar definiowania testów to miejsce, w którym podejście zwinne najbardziej wyraźnie różni się od projektów o ustrukturyzowanym przebiegu. Potencjalnie testerzy koncentrujący się na dostarczanych funkcjach mogą w ogóle nie tworzyć dokumentacji. Jest to właściwe, jeśli na przykład istnieje ogólnosystemowa polityka lub karta testowania funkcji. Bardziej prawdopodobne jest utworzenie krótkiej karty testowania każdej funkcji podczas eksploracyjnej sesji testowej. Karta przypomina plan krótkiego okresu eksploracji. Zwykle określa ona: Zakres sesji testowej – funkcję lub funkcje, które należy objąć, i/lub określoną funkcjonalność lub zachowanie systemu Cel sesji – zbadanie określonych aspektów zachowania, skupienie się na pewnym ryzyku lub trybie awarii, zastosowanie wybranych scenariuszy Czas trwania sesji wynosi zazwyczaj 45-120 minut. Zakres sesji jest z konieczności ograniczony, ale testerzy mogą wyjść poza ten zakres, jeśli uznają to za wartościowe Karta może koncentrować się na eksploracji – poznaniu działania funkcji, zidentyfikowaniu konkretnych zachowań wartych przetestowania, ocenie zakresu testowania/liczby sesji wymaganych do przetestowania dużej lub złożonej funkcji, zrozumieniu, jakie dane testowe mogą być potrzebne do jej przetestowania itd. Karta może koncentrować się konkretnie na testowaniu funkcji, ale może wskazywać pewne obszary wymagające większej uwagi niż inne. Narzędzia BDD i historyjki w wybranym formacie, na przykład historyjki i scenariusze w formacie Cucumber lub Gherkin, mogą zapewniać identyfikowalność i treść, które zwykle zapewniają projekty i procedury testów. Każdy scenariusz z klauzulami „given/when/then” określa warunki wstępne, dane wejściowe i warunki końcowe. Odnoszą się one do pojedynczej funkcji, więc zapewniają minimalny przypadek/procedurę testową i są co najmniej identyfikowalne z funkcjami. Testy przygotowane w formie skryptów do uruchamiania przez narzędzia mogą mieć dokumentację pośrednią albo nie. Zespoły w większym stopniu polegają na obserwacji testów automatycznych i tabelach danych testowych wykorzystywanych przez skrypty automatyczne niż na udokumentowanych projektach testów.

Wykonanie testów (harmonogram, dziennik)

*Cel*	Określenie kolejności wykonywania testów Rejestrowanie stanu testów – wykonane/niewykonane oraz ich statusu Udostępnienie wyników wykonania testów na potrzeby raportowania
*Zawartość*	Identyfikator testu, tester, data/godzina wykonania, status W przypadku testów, które wydają się wykazywać anomalne zachowanie (opcjonalnie): Szczegóły wykonanego testu, w przypadku gdy szczegóły różnią się od skryptu Rzeczywiste a oczekiwane wyniki Inne obserwacje, interpretacja Status testu (defekt, anomalia konfiguracji lub środowiska itp.) Identyfikator obserwacji lub raportu defektu (w stosownych przypadkach)
*Źródła*	Inwentarz przypadków/procedur testowych, testerzy
*Utrzymanie*	Harmonogram powinien zmieniać się zgodnie z zakresem testów oraz procedurami zmienionymi, usuniętymi lub dodanymi do planu. Testy będą prawdopodobnie wykonywane wielokrotnie jako ponowne testy lub testy regresji. Dziennik powinien zawierać kompletną historię wszystkich testów objętych zakresem.
*Uwagi dotyczące podejścia zwinnego/ciągłego* Jeśli projekty zwinne/ciągłe nie opierają się na dokumentach definicji testów, częściowo kompensują to, zachęcając testerów do prowadzenia dokładniejszych dzienników wykonania testów. W przypadku przeprowadzania testów podczas sesji na podstawie kart, oczekuje się, że tester będzie prowadził dobre notatki dotyczące wykonywanych testów. Istnieje niewiele dedykowanych narzędzi do rejestrowania testów, które oferują więcej niż notesy, dlatego wielu testerów korzysta z prostych edytorów tekstu, aplikacji do sporządzania notatek lub papierowych notesów. Dzienniki zwykle służą do rejestrowania wszystkich istotnych działań i obserwacji podczas ich wykonywania w ramach sesji. Typowy dziennik testów eksploracyjnych zawierałby takie elementy jak: Struktura badanych funkcji (mapa obszaru) Obserwacje i pytania dotyczące funkcji badanych podczas sesji Modele, listy i tabele elementów testowych oraz pomysłów na testy Wykonane testy, opisane z wystarczającą szczegółowością, aby można było je odtworzyć Znalezione anomalie – błędy, wątpliwe zachowanie, powolne odpowiedzi, słabe doświadczenia użytkownika i tym podobne Czas poświęcony na eksplorację, konfigurację testów, testowanie, analizę, rejestrowanie błędów, ponowne testowanie, testy regresji i czas nieproduktywny Data/godzina wpisu Jeśli testerzy rejestrują aktywność podczas sesji w aplikacjach do sporządzania notatek lub innych narzędziach, używają pewnych znaczników lub innego języka specyficznego dla domeny do strukturyzowania notatek. Mogą one być analizowane przez proste narzędzia tworzone wewnętrznie w celu przedstawienia podsumowań aktywności do wykorzystania w raporcie z testów. Testy wykonywane przez narzędzia (niezależnie od tego, czy są własnościowe, czy mają otwarty kod źródłowy) automatycznie zapisują dzienniki. Zazwyczaj można je przeszukiwać za pomocą narzędzia lub procedur napisanych przez użytkownika.

Raport z testów

*Cel*	Przekazanie wyniku etapu testów, wybranych testów lub sesji testowej Może również dotyczyć wymagań technicznych lub niefunkcjonalnych działań testowych, w którym to przypadku treść byłaby dostosowana do celu testu Częściowe poinformowanie interesariuszy, umożliwiające im podjęcie decyzji w sprawie akceptacji lub wydania systemu albo podsystemu.
*Treść*	Czasy rozpoczęcia i zakończenia testów oraz ich czas trwania Środowisko testowe Wersja lub wersje testowanego oprogramowania i systemu Cele i zakres testów (zdefiniowane w strategii testów i definicji testów) Opisowe podsumowanie wyników Funkcje uznane za działające zgodnie z wymaganiami Ryzyka uznane za uwzględnione Pozostałe testy o istotnym znaczeniu (zakończone niepowodzeniem lub zablokowane) Funkcje częściowo przetestowane i nieprzetestowane Ryzyka częściowo uwzględnione lub nieuwzględnione. Szczegóły wyników testów wraz z danymi wyjściowymi z dzienników testów itp. Status obejść dla nierozwiązanych anomalii Analizy testów Postęp i status testów w czasie Statystyki incydentów
*Źródła*	Strategia testów, definicje testów, dziennik testów, raporty incydentów Znaczna część treści raportu z testów będzie pochodzić z narzędzi używanych do rejestrowania definicji testów, dziennika testów oraz dziennika incydentów lub defektów.
*Utrzymanie*	Jest to migawka stanu na dany moment dla fazy wykonywania testów i nie jest utrzymywana.
*Uwagi dotyczące podejścia zwinnego i ciągłego* Celem raportu z testów w projekcie zwinnym może być objęcie pojedynczej iteracji lub sprintu, testów wydania albo etapu testów wyższego poziomu, takiego jak integracja lub ogólna akceptacja systemu. Niezależnie od sytuacji cel pozostaje niezmienny. Znaczna część treści raportu z testów będzie pochodzić z narzędzi lub notatek testerów. Opisowe podsumowanie wyników jest tworzone przez lidera testów lub testera w przypadku mniejszego etapu testów. Jak zwykle raport będzie prawdopodobnie mniej formalny i najpewniej będzie zawierał mniej surowych danych, które mogłyby stanowić podstawę zaawansowanych analiz. Z pewnością w trakcie iteracji postęp prac — pod względem funkcji lub historyjek dostarczonych, przetestowanych i zatwierdzonych przez użytkowników — może być rejestrowany w narzędziu lub na publicznej tablicy kanban. W ten sposób interesariusze są informowani o postępach przez całą iterację i istnieje mniejsza potrzeba tworzenia formalnego raportu na koniec okresu testowania. Widoczność postępów jest kluczową kwestią dla zespołów zwinnych. Na przykład podczas regularnych, być może codziennych spotkań na stojąco wokół tablicy Scrum członkowie zespołu dzielą się swoim rozumieniem postępów, wzajemnie zadają sobie pytania i stale uzgadniają stanowisko (oraz kolejne kroki). W ten sposób formalny raport z testów może nigdy nie być potrzebny, ponieważ zespół jest na bieżąco poinformowany i ma aktualną wiedzę o sytuacji. Jeśli testerzy prowadzą pisemne notatki dotyczące swoich działań podczas sesji, nie ma dostępnych danych możliwych do analizy, które można byłoby przedstawić w zautomatyzowanych raportach, dlatego raportowanie sesji i postępów może być prezentowane publicznie i w sposób wizualny. Wymaga to od testerów wysokiego poziomu dyscypliny i dobrych umiejętności komunikacyjnych. Lider lub kierownik testów będzie musiał przygotować odpowiednio szczegółowy raport dla interesariuszy na podstawie ustnych sprawozdań.

Jak wykorzystywać metryki DevOps do skalowania firmy

Kilka porad

Temat dokumentacji w projektach jest delikatną kwestią zarówno dla testerów, jak i innych członków zespołu projektowego.

Większość ludzi uważa pisanie dokumentacji za uciążliwe zadanie.

Projektując dokumentację, warto pamiętać o kilku kwestiach.

Dokumentacja musi mieć jasno określony cel i odbiorców. Jeśli odbiorcy nie potrzebują dokumentacji, nie będą jej czytać. Jeśli nie będzie ona współgrać z ich własnymi celami, nie zaakceptują jej.
Zazwyczaj lepiej jest rejestrować przebieg działania przed jego wykonaniem lub w jego trakcie. Na przykład TDD rejestruje testy przed napisaniem kodu. Dzienniki sesji testowych powinny być tworzone podczas sesji, a nie później.
Zakres niezbędnych danych do zarejestrowania danego aspektu testowania może być minimalny. Na przykład test zapisany w notatniku może wystarczyć testerowi, ale nie da się go łatwo analizować. Być może prosty dziennik tekstowy z pewnym oznakowaniem można utworzyć równie szybko, a jednocześnie mógłby on być analizowany przez niestandardowe narzędzie.
Procedury testowe mogą w ogóle nie być konieczne, jeśli testerzy dobrze znają testowany system. Być może wystarczy określenie celu testu lub karta testu. Przygotowane przypadki testowe można udokumentować w minimalnym zakresie w arkuszu kalkulacyjnym.

Na koniec

Konieczność jest matką dokumentacji.

Jeśli przygotowujesz wyczerpującą dokumentację dla interesariuszy, a oni jej nie czytają, oznacza to, że nie dostrzegają w niej wartości.

Lepiej przedstawić interesariuszowi pustą kartkę, wspólnie dodać do niej tematy, które chce zobaczyć w dokumencie, i rozpocząć pracę od tego miejsca. Być może poprosi o ogromną ilość treści, ale w rzeczywistości potrzebuje czegoś całkiem prostego. Ciągle pytaj: „dlaczego tego chcą?”

Dziękujemy za lekturę. Dołącz do nas następnym razem, gdy zakaszemy rękawy i rozpoczniemy planowanie testów.

Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji kolejnych części serii. Te wpisy są fragmentami kursu Leadership In Test autorstwa Paula, który gorąco polecamy, jeśli chcesz dokładniej zgłębić ten i inne tematy. Jeśli się na to zdecydujesz, użyj naszego wyjątkowego kodu rabatowego QALEADOFFER, aby uzyskać 60 USD zniżki od pełnej ceny kursu!