Test Plan - KatPow88/TestowanieAplikacjiWebowej GitHub Wiki

  1. Wstęp Celem dokumentu jest opisanie podejścia do testów strony http://demo.nopcommerce.com/. Dokument zawiera główne aspekty związane z testowaniem: zakres testów (co jest i co nie jest w zakresie), podejście testowe, zarządzanie defektami, ryzyka, kryteria wejścia/wyjścia.

Misją procesu testowego dla strony nopcommerce jest: • wykrycie błędów przed fazą przekazania oprogramowania do klienta, • przekazanie informacji osobom zainteresowanym, które umożliwią podjęcie decyzji o wdrożeniu, • potwierdzenie, że dostarczone oprogramowanie zostało zaimplementowane zgodnie z wymaganiami, • przekazanie informacji na temat jakości oprogramowania.

  1. Zakres testów
  • testy API
  • testy funkcjonalne
  • testy kompatybilności: • przeglądarki: Chrome, Firefox, Opera • urządzenia mobilne z: Chrome
  • testy regresywne
  • testy użyteczności
  • testy bezpieczeństwa
  1. Podejście do testów
  • Testy API – będą wykonane manualnie za pomocą programu POSTMAN
  • Testy funkcjonalne będą przeprowadzone w ramach sprintów. Każda historyjka będzie przetestowana poprzez wykonanie przypadków testowych
  • Testy kompatybilności zostaną przeprowadzone na najbardziej popularnych przeglądarkach (Chrome, Firefox, Opera) w celu potwierdzenia poprawności działania strony

  1. Kryteria wejścia, wyjścia a) kryteria wejścia – elementy, które muszą zostać spełnione, aby rozpocząć testowanie: - dostępne środowisko testowe - zainstalowane odpowiednie wersje aplikacji - dostępne dane testowe b) kryteria wyjścia – elementy, które muszą być spełnione, aby zakończyć testy - zaplanowane testy wykonane i pozytywnie zakończone - brak błędów na poziomie: krytycznym lub błędy zaakceptowane przez klienta - przygotowany raport z testów, przekazany klientowi.

  2. Metryki W trakcie testów przygotowane zostaną metryki:

    • przypadki testowe
    • błędy wg priorytetu

  3. Rezultaty testów W ramach testów dostarczone zostaną:

    • lista przypadków testowych
    • lista błędów
    • raport z testów

  4. Narzędzia: • Zarządzanie testami: Jira • Zarządzanie defektami: TestRail • Testy API – Postman

  5. Zarządzanie defektami a) zgłoszenie błędu Każde zgłoszenie błędu będzie zawierać następujące informacje potrzebne do jego zreprodukowania oraz poprawienia:

  • opis
  • kroki reprodukcji
  • priorytet
  • rezultat aktualny
  • rezultat oczekiwany
  • załączniki
  • tagi b) zasady retestowania błędów W pierwszej kolejności będą realizowane zadania związane z retestowaniem błędów o najwyższym priorytecie niż testowanie nowych funkcjonalności. Wszystkie błędy zgłoszone w ramach User Story powinny być przetestowane w tym samym sprincie.
  1. Role i odpowiedzialności
    • Test Manager:
    • Quality Engineer:
  2. Ryzyka

• Projektowe:

  • brak czasu i budżetu na przeprowadzenie testów niefunkcjonalnych np. wydajnościowych, przeciążeniowych

• Produktowe: