Dokumentacja testowa w testowaniu oprogramowania (przykład)

Co to jest dokumentacja testowa?

Dokumentacja testów to dokumentacja artefaktów utworzonych przed lub w trakcie testowania oprogramowania. Pomaga zespołowi testującemu oszacować wymagany nakład pracy, śledzić zasoby i postępy oraz zapewnić odpowiednie pokrycie testami. Zapis i raporty z testów to kompletny zestaw dokumentów, które pozwalają opisać i udokumentować planowanie testów, projektowanie testów, ich wykonywanie oraz wyniki testów uzyskane w trakcie testów.

👉 Zapisz się na bezpłatny projekt testowania oprogramowania na żywo

Dlaczego potrzebna jest formalność testów?

Dla nowicjusza łatwo założyć, że testowanie polega na wykonywaniu poszczególnych sekcji kodu ad hoc i weryfikowaniu wyników. Jednak w praktyce testowanie jest bardzo formalną czynnością i jest szczegółowo dokumentowane. Dokumentacja testów ułatwia planowanie, przeglądanie i wykonywanie testów, a także umożliwia ich weryfikację.

Stopień formalności testu zależy od:

• Typ testowanej aplikacji (AUT).
• Standardy przestrzegane przez Twoją organizację.
• Dojrzałość procesu rozwoju.

Czynności testowe zazwyczaj zajmują od 30% i 50% całkowitego nakładu pracy w zakresie rozwoju oprogramowania. Dokumentacja pomaga zidentyfikować usprawnienia procesu testowania, które można zastosować w przyszłych projektach.

Jakie są rodzaje dokumentacji testowej?

Oto ważne typy dokumentacji testowej:

„W praktyce dokumenty te powstają na różnych etapach — od wczesnego planowania (polityka testów, strategia) po realizację i zamknięcie (raporty dotyczące usterek i raporty podsumowujące)”.

Rodzaje dokumentów testowych	OPIS
Polityka testowa	Jest to dokument wysokiego szczebla opisujący zasady, metody i wszystkie ważne cele testowania organizacji.
Strategia testowa	Dokument wysokiego poziomu identyfikujący poziomy (typy) testów, które mają zostać wykonane w ramach projektu.
Plan testowy	Plan testów to kompletny dokument planistyczny zawierający zakres, podejście, zasoby, harmonogram itp. działań testowych.
Macierz śledzenia wymagań	Jest to dokument łączący wymagania z przypadkami testowymi.
Scenariusz testowy	Scenariusz testowy jest elementem lub zdarzeniem systemu oprogramowania, które można zweryfikować za pomocą jednego lub większej liczby przypadków testowych.
Przypadek testowy	Jest to grupa wartości wejściowych, warunków wstępnych wykonania, oczekiwanych warunków końcowych wykonania oraz wyników. Jest ona tworzona na potrzeby scenariusza testowego.
Dane testowe	Dane testowe to dane istniejące przed wykonaniem testu. Służą one do wykonania przypadku testowego.
Zgłoszenie usterki	Raport o usterce to udokumentowany raport o wszelkich wadach systemu oprogramowania, które nie spełniają oczekiwanych funkcji.
Raport podsumowujący test	Raport podsumowujący testy to dokument wysokiego poziomu, który podsumowuje przeprowadzone czynności testowe, a także ich wyniki.

Jakie są najlepsze praktyki w zakresie tworzenia dokumentacji testów?

W tej sekcji poznamy najlepsze praktyki, które pomagają w tworzeniu dokumentacji testów, wraz z przykładami, które pomogą Ci ją lepiej zrozumieć:

• Zaangażuj dział zapewnienia jakości na wczesnym etapie projektu: Zaangażuj zespół ds. zapewnienia jakości już na początku projektu, aby dokumentacja testów rozwijała się równolegle z projektem i wymaganiami produktu.
  Przykład: Dział zapewnienia jakości współpracuje podczas planowania sprintu w celu opracowania wstępnych przypadków testowych w oparciu o historie użytkowników.
• Aktualizuj dokumenty: Nie twórz dokumentów testowych i nie zapominaj o nich — aktualizuj je za każdym razem, gdy wymagania lub funkcje ulegną zmianie.
  Przykład: Gdy interfejs API logowania ulegnie zmianie, należy natychmiast zaktualizować powiązane przypadki testowe i wyniki.
• Użyj kontroli wersji: Zarządzaj wszystkimi zmianami w dokumentach testowych i śledź je za pomocą systemów kontroli wersji, aby uniknąć nieporozumień i utraty danych.
  Przykład: Przechowuj plany testów w GitHub, aby zachować przejrzystą historię wersji i opcje wycofywania poprzednich wersji.
• Dokument dla przejrzystości i celu: Rejestruj tylko to, co pomaga Tobie i Twoim interesariuszom zrozumieć postęp testów i ich wyniki.
  Przykład: Dołącz raporty podsumowujące testy, w których wyróżniono przypadki testowe zaliczone, niezaliczone i zablokowane, do wglądu dla kierownictwa.
• Użyj standardowych szablonów: Stosuj spójny format — na przykład szablony w programie Excel lub Word — aby ułatwić tworzenie i przeglądanie dokumentacji.
  Przykład: Użyj standardowego „szablonu przypadku testowego” z polami na identyfikator, opis, warunki wstępne i oczekiwane wyniki.
• Centralizacja przechowywania dokumentów: Przechowuj wszystkie dokumenty związane z projektem w jednym, łatwo dostępnym miejscu, aby członkowie zespołu mogli łatwo do nich zaglądać i je aktualizować.
  Przykład: Przechowuj artefakty testowe w miejscu współdzielonym Google Drive folder dostępny dla całego zespołu ds. zapewnienia jakości i rozwoju.
• Uwzględnij wystarczającą ilość szczegółów: Unikaj niejasnych i niekompletnych informacji; szczegółowa dokumentacja ułatwia zrozumienie i zmniejsza liczbę błędów popełnianych podczas wykonywania testów.
  Przykład: Zamiast „Sprawdź logowanie” wpisz „Pomyślne sprawdzenie, czy logowanie użytkownika przy użyciu prawidłowych danych logowania przekierowuje do pulpitu nawigacyjnego”.

Kiedy należy tworzyć dokumentację testową dla testowania oprogramowania?

Oto kilka kluczowych punktów dotyczących tego, kiedy należy tworzyć dokumentację testową dla testowania oprogramowania:

• Faza planowania: Przed rozpoczęciem testów należy jasno określić zakres, cele i strategię testowania.
• Przygotowanie do testu: Podczas planowania testów należy skutecznie ustalić harmonogramy, zasoby i wymagania środowiskowe.
• Analiza wymagań: Po przeprowadzeniu analizy wymagań należy zagwarantować pełne uwzględnienie specyfikacji funkcjonalnych i niefunkcjonalnych.
• Standaryzacja projektowania: Przed zaprojektowaniem przypadków testowych należy ustandaryzować formaty i zachować możliwość śledzenia wszystkich dokumentów.
• Dokumentacja scenariusza: Podczas projektowania testów, w celu dokumentowania scenariuszy, danych wejściowych, oczekiwanych wyników i szczegółów danych testowych.
• Gotowość do realizacji: Przed wykonaniem testu należy sprawdzić gotowość środowiska testowego, narzędzi i dokładność dokumentacji.
• Ocena końcowa: Po przeprowadzeniu testów należy zarejestrować wyniki, błędy i wnioski na potrzeby udoskonalenia procesu.

Jakie typy szablonów są wymagane do dokumentacji testów?

Oto kilka szablonów, których potrzebujesz do dokumentacji testów w testowaniu oprogramowania:

Nazwa szablonu	Narzędzia
Szablon planu testów	Microsoft Word, Google Docs lub Confluence do wspólnej edycji i kontroli wersji
Szablon przypadku testowego	TestRail, Zephyr (w JIRA), Xray lub Excel/Arkusze Google do ustrukturyzowanego zarządzania testami
Szablon scenariusza testowego	JIRA, TestLink lub Arkusze Google do dokumentowania warunków testowania na wysokim poziomie
Szablon macierzy śledzenia wymagań (RTM)	Excel, Arkusze Google lub TestRail do mapowania wymagań na przypadki testowe
Szablon raportu o wadach	JIRA, Bugzilla lub Azure DevOps do rejestrowania i śledzenia defektów
Szablon raportu podsumowującego testy	Zbieg, Google Docs lub TestRail do kompilacji wyników testów i ich analizy

Zalety i wady dokumentacji testowej

ZALETY

• Głównym celem tworzenia dokumentacji testowej jest zmniejszenie lub usunięcie wszelkich wątpliwości dotyczących czynności testowych. Pomaga to wyeliminować niejasności, które często pojawiają się przy podziale zadań.
• Dokumentacja oferuje nie tylko systematyczne podejście do problemu Testowanie oprogramowaniaale może również służyć jako materiał szkoleniowy dla osób rozpoczynających przygodę z testowaniem oprogramowania.
• Prezentacja dokumentacji testowej jest dobrą strategią marketingową i sprzedażową, pokazującą dojrzały proces testowania.
• Dokumentacja testowa pomaga zaoferować klientowi produkt wysokiej jakości w określonym terminie.
• In Inżynieria oprogramowaniaDokumentacja testowa pomaga również skonfigurować lub ustawić program za pomocą dokumentu konfiguracyjnego i instrukcji obsługi.
• Dokumentacja testowa pomaga zwiększyć przejrzystość w relacjach z klientem.

Wady

• Koszt dokumentacji może przekroczyć jej wartość, gdyż jej przygotowanie jest bardzo czasochłonne.
• Często piszą je osoby, które nie potrafią dobrze pisać lub nie znają materiału.
• Śledzenie zmian żądanych przez klienta i aktualizacja odpowiednich dokumentów jest męcząca.
• Słaba dokumentacja bezpośrednio odbija się na jakości produktu, gdyż może dojść do nieporozumień między klientem a organizacją.

Typowe błędy, których należy unikać w dokumentacji testów

Oto najczęstsze błędy, których należy unikać w dokumentacji testów:

1. Unikaj pisania niejasnych lub niejednoznacznych opisów przypadków testowych.
2. Nie zaniedbuj dokumentowania warunków wstępnych i zależności testów.
3. Nigdy nie zapomnij o uwzględnieniu oczekiwanych wyników każdego testu.
4. Unikaj niespójnego formatowania w różnych dokumentach testowych.
5. Nie stosuj niejasnych i niemierzalnych celów testu.
6. Nigdy nie zaniedbuj kontroli wersji przy aktualizacji dokumentacji testowej.
7. Unikaj duplikowania informacji w wielu artefaktach testowych.
8. Nie zaniedbuj sprawdzania dokumentacji pod kątem dokładności i kompletności.

FAQ