Zarządzanie przypadkami testowymi

Zarządzanie przypadkami testowymi
Jednym z celów testowania jest znajdywanie defektów, różnica między aktualnym i oczekiwanym wynikiem muszą zostać zakwalifikowane jako przypadki. Przypadek powinien być śledzony od momentu jego odkrycia aż po przedstawienie dla niego rozwiązania. W celu zarządzania przypadkami organizacja powinna ustanowić proces i zasady klasyfikacji przypadków.

Przypadek może zostać dostrzeżony podczas czynności programistycznych, przeglądów, testowania lub użycia oprogramowania. Może być odniesiony do kodu lub do systemu ale również do dokumentacji programistycznej, dokumentów testowych lub informacji dla użytkownika jak np. "Pomoc".

 

Cele raportów o przypadkach:
  • dostarczyć programistom i innym uczestnikom informację zwrotną o problemach aby wspomóc identyfikacją, izolacją i korekcją gdy jest to konieczne
  • dostarczyć liderom testów narzędzi do śledzenia jakości systemu będącego testowanym i postępu w testowaniu
  • dostarczać pomysły dla poprawy procesu testowego.

 

Tester lub osoba dokonująca przeglądu zazwyczaj zapisują następujące informacje o przypadkach:
  • data wykrycia, część organizacji gdzie został znaleziony przypadek, autor, potwierdzenie i status
  • zakres, negatywne konsekwencje i priorytet przypadku
  • referencje, zawierające jaki przypadek testowy pozwolił wykryć problem.

 

Szczegóły raportu o przypadku zawiera:
  • oczekiwany i aktualny rezultat
  • data kiedy przypadek został wykryty
  • identyfikacja i konfiguracja oprogramowania lub systemu
  • cykl życia oprogramowania, w którym przypadek został zaobserwowany
  • opis anomalii, dla wsparcia znalezienia rozwiązania
  • poziom wpływu na zainteresowanych udziałowców
  • negatywny wpływ na system
  • pilność/priorytet naprawy
  • status przypadku (np. otwarty, duplikat, czeka na naprawę, naprawiony - oczekujący na potwierdzenie, zamknięty)
  • konkluzje i rekomendacje
  • czynniki zewnętrzne, jak inne obszary mogące być zainfekowane zmianą wprowadzoną dla naprawy przypadku
  • historia zmian, jako sekwencja działań podjętych, przez członków zespołu projektowego, dla wyizolowania i naprawienia przypadku.