PLAN TESTÓW - TESTOWANIE OPROGRAMOWANIA

Plan testów to szczegółowy dokument opisujący obszary i czynności związane z testowaniem oprogramowania. Przedstawia strategię testów, cele, harmonogram testów, wymagane zasoby (zasoby ludzkie, oprogramowanie i sprzęt), oszacowanie testów i produkty testowe.

Plan testów jest podstawą testowania każdego oprogramowania. Jest to najważniejsza czynność, która zapewnia dostępność wszystkich list planowanych działań w odpowiedniej kolejności.

Plan testów to szablon do przeprowadzenia działań związanych z testowaniem oprogramowania jako zdefiniowany proces, który jest w pełni monitorowany i kontrolowany przez kierownika testów. Plan testów przygotowuje Lider Testów (60%), Kierownik Testów (20%) i inżynier testów (20%).

Rodzaje planu testów

Istnieją trzy typy planu testów

Główny plan testów
Plan testów fazowych
Plany testów specyficzne dla typu testowania

Główny plan testów

Główny plan testów to rodzaj planu testów, który obejmuje wiele poziomów testowania. Zawiera pełną strategię testową.

Plan testów fazowych

Plan testów fazowych to rodzaj planu testów, który dotyczy dowolnej fazy strategii testowania. Na przykład lista narzędzi, lista przypadków testowych itp.

Konkretne plany testów

Specjalny plan testów przeznaczony dla głównych typów testów, takich jak testy bezpieczeństwa, testy obciążenia, testy wydajności itp. Innymi słowy, konkretny plan testów przeznaczony dla testów niefunkcjonalnych.

Jak napisać plan testów

Sporządzenie planu testów jest najważniejszym zadaniem procesu zarządzania testami. Zgodnie z IEEE 829, aby przygotować plan testów, wykonaj siedem następujących kroków.

Najpierw przeanalizuj strukturę i architekturę produktu.
Teraz zaprojektuj strategię testową.
Zdefiniuj wszystkie cele testu.
Zdefiniuj obszar testowy.
Zdefiniuj wszystkie możliwe do wykorzystania zasoby.
Zaplanuj wszystkie działania w odpowiedni sposób.
Określ wszystkie produkty testowe.

Komponenty lub atrybuty planu testowania

Plan testów składa się z różnych części, które pomagają nam wyprowadzić całe działanie testowe.

Cele: Zawiera informacje o modułach, funkcjach, danych testowych itp., które wskazują, że cel aplikacji oznacza zachowanie aplikacji, cel itp.

Zakres: Zawiera informacje, które należy przetestować z odpowiednią aplikacją. Zakres można dalej podzielić na dwie części:

W ramach
Poza zasięgiem

W ramach: Są to moduły, które należy rygorystycznie (szczegółowo przetestować).

Nasz zakres: Są to moduły, których nie trzeba rygorystycznie testować.

Na przykład Załóżmy, że mamy aplikację Gmail do przetestowania. Gdzie funkcje do przetestowania Jak na przykład Utwórz pocztę, Elementy wysłane, Skrzynka odbiorcza, Wersje robocze i funkcje, które nie są testowane Jak na przykład Pomoc , i tak dalej, co oznacza, że już na etapie planowania, na podstawie podanego w produkcie limitu czasowego, zadecydujemy, która funkcjonalność ma zostać sprawdzona, a która nie.

Teraz w jaki sposób decydujemy, które funkcje nie będą testowane?

Mamy następujące aspekty, w których możemy zdecydować, która funkcja nie będzie testowana:

Jak widzimy powyżej Pomoc funkcje nie będą testowane, ponieważ zostały napisane i opracowane przez autora tekstów technicznych, a sprawdzone przez innego zawodowego autora.
Załóżmy, że mamy jedną aplikację, która je posiada P, Q, R i S funkcje, które należy opracować w oparciu o wymagania. Ale tutaj funkcja S została już zaprojektowana i wykorzystana przez inną firmę. Dlatego zespół programistów kupi S od tej firmy i zintegruje go z dodatkowymi funkcjami, takimi jak P, Q i R.

Teraz nie będziemy przeprowadzać testów funkcjonalnych funkcji S, ponieważ została ona już wykorzystana w czasie rzeczywistym. Przeprowadzimy jednak testy integracji i testy systemu między funkcjami P, Q, R i S, ponieważ nowe funkcje mogą nie działać poprawnie z funkcją S, jak widać na poniższym obrazku:

Załóżmy, że w pierwszej wersji produktu zostały opracowane elementy, takie jak P, Q, R, S, T, U, V, W…..X, Y, Z . Teraz klient określi wymagania dotyczące nowych funkcji, które ulepszą produkt w drugiej wersji i nowe funkcje A1, B2, C3, D4 i E5.

Następnie zapiszemy zakres podczas planu testów jako

Zakres

Funkcje do przetestowania

A1, B2, C3, D4, E5 (nowe funkcje)

P, Q, R, S, T

Funkcje nie do testowania

różnica tygrysa i lwa

W…..X, Y, Z

Dlatego najpierw sprawdzimy nowe funkcje, a następnie będziemy kontynuować stare funkcje, ponieważ dodanie nowych funkcji może na nie wpłynąć, co oznacza, że będzie to miało również wpływ na obszary wpływu, dlatego przeprowadzimy jedną rundę testów regresyjnych dla P, Q , R…, funkcje T.

Metodologia testu:

Zawiera informacje na temat wykonywania różnego rodzaju testów, takich jak testy funkcjonalne, testy integracyjne, testy systemowe itp. w aplikacji. W tym przypadku zdecydujemy, jaki rodzaj testów; wykonamy różne funkcje w zależności od wymagań aplikacji. W tym miejscu powinniśmy również zdefiniować, jakiego rodzaju testy zastosujemy w metodologiach testowania, aby wszyscy, na przykład kierownictwo, zespół programistów i zespół testujący, mogli łatwo zrozumieć, ponieważ warunki testowania nie są standardowe.

Na przykład, do samodzielnej aplikacji, np Adobe Photoshopie , przeprowadzimy następujące rodzaje testów:

Testy dymne → Testy funkcjonalne → Testy integracyjne →Testy systemowe →Testy adhoc → Testy zgodności → Testy regresyjne → Testy globalizacyjne → Testy dostępności → Testy użyteczności → Testy niezawodności → Testy odzyskiwania → Testy instalacji lub dezinstalacji

I załóżmy, że musimy przetestować https://www.jeevansathi.com/ aplikacji, dlatego przeprowadzimy następujące rodzaje testów:

Testowanie dymu	Testy funkcjonalności	Testy integracyjne
Testowanie systemu	Testowanie adhoc	Testowanie kompatybilności
Testowanie regresyjne	Testowanie globalizacji	Testowanie dostępności
Test użyteczności	Test wydajności

Zbliżać się

Ten atrybut służy do opisu przepływu aplikacji podczas testowania i do wykorzystania w przyszłości.

Możemy zrozumieć przepływ aplikacji za pomocą poniższych aspektów:

Pisząc scenariusze wysokiego poziomu Pisząc wykres przepływu

Pisząc scenariusze wysokiego poziomu

Na przykład , załóżmy, że testujemy Gmaila aplikacja:

Zaloguj się do Gmaila – wysyła wiadomość e-mail i sprawdza, czy znajduje się ona na stronie Elementy wysłane
Zaloguj się do …….
……
…....

Piszemy to, aby opisać podejścia, które należy zastosować podczas testowania produktu i tylko w przypadku krytycznych funkcji, w przypadku których napiszemy scenariusze wysokiego poziomu. Nie będziemy się tutaj skupiać na omówieniu wszystkich scenariuszy, ponieważ konkretny inżynier testowy może zdecydować, które funkcje należy przetestować, a które nie.

Pisząc wykres przepływu

Wykres przepływu został napisany, ponieważ pisanie scenariuszy wysokiego poziomu jest procesem czasochłonnym, jak widać na poniższym obrazku:

Tworzymy wykresy przepływu, aby uzyskać następujące korzyści, takie jak:

Zasięg jest łatwy
Łączenie jest łatwe

Podejście to można podzielić na dwie części, które są następujące:

Podejście od góry do dołu
Podejście od dołu do góry

Założenie

Zawiera informacje o problemie lub problemie, który mógł wystąpić podczas procesu testowania, a kiedy piszemy plany testów, przyjmujemy pewne założenia, takie jak zasoby i technologie itp.

Ryzyko

Oto wyzwania, którym musimy stawić czoła, aby przetestować aplikację w bieżącej wersji i jeśli założenia zawiodą, wiąże się to z ryzykiem.

Na przykład, wpływ na aplikację, data wydania zostaje przesunięta.

Plan łagodzenia lub plan awaryjny

Jest to plan awaryjny przygotowany w celu przezwyciężenia zagrożeń lub problemów.

Przyjrzyjmy się jednemu przykładowi założenia, ryzyka i planu awaryjnego łącznie, ponieważ są one ze sobą powiązane.

W każdym produkcie założenie zrobimy, że wszyscy trzej inżynierowie testowi będą tam pracować aż do ukończenia produktu, a każdemu z nich zostaną przypisane różne moduły, takie jak P, Q i R. W tym konkretnym scenariuszu ryzyko mogłoby się tak zdarzyć, gdyby inżynier testowy opuścił projekt w jego trakcie.

Dlatego też plan awaryjny do każdej funkcji zostanie przypisany właściciel główny i podrzędny. Jeśli więc jeden inżynier testowy odejdzie, podległy właściciel przejmuje tę konkretną funkcję, a także pomaga nowemu inżynierowi testującemu, aby mógł on/ona zrozumieć przypisane mu moduły.

Założenia, ryzyko i plan łagodzenia lub plan awaryjny są zawsze dokładne w odniesieniu do samego produktu. Wyróżnia się następujące rodzaje ryzyka:

Perspektywa klienta
Podejście zasobowe
Opinia techniczna

Rola i odpowiedzialność

Definiuje kompletne zadanie, które musi wykonać cały zespół testujący. Kiedy pojawia się duży projekt, to Menedżer testów to osoba, która pisze plan testów. Jeśli są 3-4 małe projekty, kierownik testów przydzieli każdy projekt każdemu Liderowi Testów. Następnie lider testów pisze plan testów dla projektu, który mu przydziela.

Zobaczmy jeden przykład, w którym zrozumiemy role i odpowiedzialność kierownika testów, kierownika testów i inżynierów testów.

dodanie do tablicy Java

Rola: Menedżer testów

Imię: Ryan

Odpowiedzialność:

Przygotuj (napisz i przejrzyj) plan testów
Przeprowadź spotkanie z zespołem programistów
Przeprowadź spotkanie z zespołem testującym
Przeprowadź spotkanie z klientem
Przeprowadź jedno miesięczne spotkanie stand-up
Podpisz informację o wydaniu
Postępowanie w przypadku eskalacji i problemów

Rola: Lider testów

Imię: Harvey

Odpowiedzialność:

Przygotuj (napisz i przejrzyj) plan testów
Przeprowadzaj codzienne spotkania na stojąco
Przejrzyj i zatwierdź przypadek testowy
Przygotuj RTM i raporty
Przypisz moduły
Harmonogram obsługi

Rola: Inżynier Testów 1, Inżynier Testów 2 i Inżynier Testów 3

Imię: Louis, Jessica, Donna

Przypisz moduły: M1, M2 i M3

Odpowiedzialność:

Napisz, przejrzyj i wykonaj dokumenty testowe, które składają się z przypadku testowego i scenariuszy testowych
Przeczytaj, przejrzyj, zrozum i przeanalizuj wymagania
Napisz przebieg aplikacji
Wykonaj przypadek testowy
RTM dla odpowiednich modułów
Śledzenie usterek
Przygotuj raport z wykonania testu i przekaż go Liderowi Testów.

Harmonogram

Służy do wyjaśnienia czasu wykonania pracy, co należy wykonać, lub ten atrybut określa, kiedy dokładnie powinno rozpocząć się i zakończyć każde działanie testowe? Dokładne dane są również podane dla każdego działania testowego w danym dniu.

Dlatego, jak widzimy na poniższym obrazku, dla konkretnego działania będzie data początkowa i data końcowa; dla każdego testowania konkretnej kompilacji będzie określona data.

Na przykład

Pisanie przypadków testowych
Proces wykonania

Śledzenie usterek

Zwykle robi się to za pomocą narzędzi, ponieważ nie możemy ręcznie śledzić statusu każdego błędu. Komentujemy także sposób, w jaki informujemy o błędach wykrytych w procesie testowania i odsyłamy je do zespołu programistów oraz w jaki sposób zespół programistów zareaguje. Wspominamy tutaj również o priorytecie błędów, takim jak wysoki, średni i niski.

Poniżej przedstawiono różne aspekty śledzenia defektów:

Bloker lub showstopper

Na przykład

Krytyczny

Główny

Drobny

Wysoki-P1

Średni-P2

Niski P3

Dlatego w oparciu o priorytet błędów, taki jak wysoki, średni i niski, sklasyfikowamy je jako P1, P2, P3 i P4.

Środowiska Testowe

Są to środowiska, w których będziemy testować aplikację i tutaj mamy dwa rodzaje środowisk, do których zaliczamy się oprogramowanie I sprzęt komputerowy konfiguracja.

The konfiguracja oprogramowania oznacza szczegóły dotyczące różnych System operacyjny Jak na przykład Windows, Linux, UNIX i Mac i różne Przeglądarki tak jak Google Chrome, Firefox, Opera, Internet Explorer , i tak dalej.

I Konfiguracja sprzętu oznacza informację o różnych rozmiarach RAM, ROM i procesory .

Na przykład

The Oprogramowanie obejmuje:

serwer

System operacyjny	Linuksa
Serwer internetowy	Apache Tomcat
Serwer aplikacji	Websfera
Serwer bazy danych	Serwer Oracle lub MS-SQL

Uwaga: Powyższe serwery są serwerami, na których zespół testujący testuje aplikację.

Klient

System operacyjny	Windows XP, Vista7
Przeglądarki	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 i Internet Explorer 8

Uwaga: Powyższe szczegóły przedstawiają różne systemy operacyjne i przeglądarki, w których zespół testujący będzie testował aplikację.

The Sprzęt komputerowy obejmuje:

serwer : Słońce StarCat 1500

Ten konkretny serwer może być używany przez zespół testujący do testowania aplikacji.

Klient:

Ma następującą konfigurację, która wygląda następująco:

Edytor	Całkowite 2 GHz
Baran	2 GB
….	….

Uwaga: zapewni konfigurację systemów inżynierów testowych, czyli zespołu testującego.

Zespół programistów zapewni konfigurację sposobu instalacji oprogramowania. Jeśli zespół programistów nie zapewni jeszcze procesu, zapiszemy go w planie testów jako Rozwój oparty na zadaniach (TBD).

Kryteria wejścia i wyjścia

Jest to warunek konieczny, który należy spełnić przed rozpoczęciem i zakończeniem procesu testowania.

Kryteria wejścia

Kryteria wejścia zawierają następujące warunki:

Testy białej skrzynki powinny zostać zakończone.
Zrozum i przeanalizuj wymagania oraz przygotuj dokumenty testowe lub kiedy dokumenty testowe będą gotowe.
Dane testowe powinny być gotowe.
Należy przygotować kompilację lub aplikację
Moduły lub funkcje muszą być przypisane różnym inżynierom testującym.
Niezbędny zasób musi być gotowy.

Kryteria wyjścia

Kryteria wyjścia zawierają następujące warunki:

Kiedy wszystkie przypadki testowe zostaną wykonane.
Większość przypadków testowych musi tak być przeszedł .
Zależy od wagi błędów, co oznacza, że nie może być żadnego blokującego ani większego błędu, chociaż mogą występować drobne błędy.

Zanim zaczniemy przeprowadzać testy funkcjonalne, wszystkie powyższe Kryteria wejścia należy przestrzegać. Po przeprowadzeniu testów funkcjonalnych i przed wykonaniem testów integracyjnych, następnie Kryteria wyjścia należy przeprowadzić testy funkcjonalne, ponieważ procent kryteriów wyjścia jest ustalany na spotkaniu zarówno z kierownikiem ds. rozwoju, jak i testami, ponieważ ich współpraca może osiągnąć ten procent. Jeśli jednak nie zostaną spełnione kryteria wyjścia testów funkcjonalnych, nie możemy przejść dalej do testów integracyjnych.

Tutaj w zależności od ciężkości błędu oznacza, że zespół testowy zdecydowałby się przejść dalej w kolejnych fazach.

Automatyzacja testów

W tym przypadku zdecydujemy o następujących kwestiach:

Która funkcja musi być zautomatyzowana, a która nie?
Którego narzędzia do automatyzacji testów będziemy używać w którym frameworku automatyzacji?

Automatyzujemy przypadek testowy dopiero po pierwszym wydaniu.

Tutaj pojawia się pytanie, na jakiej podstawie My będzie zdecydować, które funkcje należy przetestować?

Na powyższym obrazku widzimy, że najczęściej używane funkcje wymagają ciągłego testowania. Załóżmy, że musimy sprawdzić aplikację Gmail, w której znajdują się podstawowe funkcje Utwórz pocztę, Elementy wysłane i Skrzynka odbiorcza . Będziemy więc testować te funkcje, ponieważ przeprowadzanie testów ręcznych zajmuje więcej czasu, a także staje się monotonną pracą.

Teraz, w jaki sposób decydujemy, które funkcje nie będą testowane?

algorytm „bankiera”

Przypuszczać pomoc funkcja aplikacji Gmail nie jest wielokrotnie testowana, ponieważ nie jest regularnie używana, więc nie musimy jej często sprawdzać.

Ale jeśli niektóre funkcje są niestabilne i zawierają wiele błędów , co oznacza, że nie będziemy testować tych funkcji, ponieważ trzeba je wielokrotnie testować podczas testów ręcznych.

Jeśli istnieje funkcja, którą należy często testować , ale spodziewamy się zmiany wymagań dla tej funkcji, więc tego nie sprawdzamy, ponieważ zmiana ręcznych przypadków testowych jest wygodniejsza w porównaniu ze zmianą w skrypcie testu automatycznego.

Oszacowanie wysiłku

W ten sposób zaplanujemy wysiłek, jaki musi włożyć każdy członek zespołu.

Możliwość dostarczenia testu

Są to dokumenty będące efektem pracy zespołu testującego, które przekazaliśmy klientowi wraz z produktem. Obejmuje to:

Plan testów Przypadki testowe Skrypty testowe RTM (macierz identyfikowalności wymagań) Raport o usterce Raport z wykonania testu Wykresy i metryki Informacje o wydaniu

Wykresy i metryki

Wykres

W tym artykule omówimy rodzaje wykresy wyślemy, a także udostępnimy próbkę każdego wykresu.

Jak widzimy, mamy pięć różnych wykresów, które pokazują różne aspekty procesu testowania.

Wykres 1: W ten sposób pokażemy, ile usterek zostało zidentyfikowanych i ile usterek zostało naprawionych w każdym module.

Wykres 2: Rysunek pierwszy pokazuje, ile krytycznych, głównych i mniejszych defektów zostało zidentyfikowanych w każdym module i ile zostało naprawionych w poszczególnych modułach.

Wykres 3: Na tym konkretnym wykresie przedstawiamy zbuduj mądry wykres , co oznacza, że w każdej kompilacji ile defektów zostało zidentyfikowanych i naprawionych dla każdego modułu. Na podstawie modułu ustaliliśmy błędy. Dodamy R aby pokazać liczbę defektów w P i Q, a także dodajemy S aby pokazać defekty w P, Q i R.

Wykres 4: Lider testowy zaprojektuje Analiza trendów błędów wykres tworzony co miesiąc i przesyłany również do Zarządu. To jest tak, jak przewidywanie, które odbywa się na końcu produktu. I tutaj też możemy oceń poprawki błędów jak możemy to zaobserwować łuk ma tendencja wzrostowa na poniższym obrazku.

Wykres 5: The Menedżer testów zaprojektował tego typu wykres. Ten wykres ma na celu zrozumienie luki w ocenie błędów i faktycznych błędów, które wystąpiły, a także pomaga w ulepszaniu oceny błędów w przyszłości.

Metryka

Podobnie jak powyżej tworzymy wykres rozkładu błędów pokazany na rysunku 1 i przy pomocy powyższych danych projektujemy również metryki.

Na przykład

Na powyższym rysunku przechowujemy zapisy wszystkich inżynierów testujących w danym projekcie oraz liczbę zidentyfikowanych i naprawionych defektów. Możemy również wykorzystać te dane do przyszłych analiz. Kiedy pojawia się nowy wymóg, możemy zdecydować, komu udostępnić wymagającą funkcję do testów, na podstawie liczby defektów wykrytych wcześniej zgodnie z powyższymi metrykami. Będziemy w lepszej sytuacji, wiedząc, kto bardzo dobrze poradzi sobie z problematycznymi cechami i znajdzie maksymalną liczbę defektów.

Informacje o wersji: Jest to dokument przygotowywany podczas wypuszczenia produktu i podpisywany przez Kierownika Testów.

Na poniższym obrazku widać, że produkt końcowy jest opracowywany i wdrażany u klienta, a nazwa najnowszej wersji to Beta .

The Informacje o wersji składa się z następujących elementów:

Instrukcja obsługi.
Lista oczekujących i otwartych defektów.
Lista dodanych, zmodyfikowanych i usuniętych funkcji.
Lista platformy (system operacyjny, sprzęt, przeglądarki), na której testowany jest produkt.
Platforma, na której produkt nie jest testowany.
Lista błędów naprawionych w bieżącej wersji i lista naprawionych błędów w poprzedniej wersji.
Proces instalacji
Wersje oprogramowania

Na przykład

Przypuszczam, że Beta to drugie wydanie aplikacji po wydaniu pierwszym Alfa zostaje zwolniony. Część usterek zidentyfikowanych w pierwszej wersji została naprawiona w wersji późniejszej. W tym miejscu przedstawimy także listę nowo dodanych, zmodyfikowanych i usuniętych funkcji od wersji alfa do wersji beta.

Szablon

Ta część zawiera wszystkie szablony dokumentów, które zostaną wykorzystane w produkcie, a wszyscy inżynierowie testujący będą używać w projekcie tylko tych szablonów, aby zachować spójność produktu. Tutaj mamy różne typy szablonów, które są używane podczas całego procesu testowania, takie jak:

Szablon przypadku testowego
Szablon przeglądu przypadku testowego
Szablon RTM
Szablon raportu o błędzie
Raport z wykonania testu

Zobaczmy jeden przykładowy dokument planu testów

Strona 1

Strona 3-strona 18

Strona-20

Na stronie 1 wypełniamy przede wszystkim tylko Wersje, autor, komentarze i recenzje: pola, a po zatwierdzeniu przez menadżera, o szczegółach poinformujemy w rozwinięciu Zatwierdzony przez i data zatwierdzenia pola.

W większości przypadków plan testów jest zatwierdzany przez Kierownika Testów, a inżynierowie testujący jedynie go przeglądają. A kiedy pojawią się nowe funkcje, zmodyfikujemy plan testów i dokonamy niezbędnych modyfikacji Wersja pole, a następnie zostanie ono przesłane ponownie do dalszego sprawdzenia, aktualizacji i zatwierdzenia przez menedżera. Plan testów należy aktualizować za każdym razem, gdy zajdą jakiekolwiek zmiany. Na stronie 20, Bibliografia określ szczegóły wszystkich dokumentów, których będziemy używać do pisania dokumentu planu testów.

Notatka:

Kto pisze plan testów?

Przewód testowy → 60%
Kierownik Testów →20%
Inżynier ds. testów →20%

Zatem jak widać z powyższego, w 60% produktu plan testów pisany jest przez Lidera Testów.

Kto dokonuje przeglądu planu testów?

Przewód
Menedżer testów
Inżynier testów
Klient
Zespół deweloperski

Inżynier Testów przegląda plan testów z perspektywy swojego modułu, a kierownik testów przegląda plan testów w oparciu o opinię klienta.

Kto zatwierdza plan testów?

Klient
Menedżer testów

Kto pisze przypadek testowy?

Przewód
Inżynier Testów

Kto sprawdza przypadek testowy?

Inżynier Testów
Przewód
Klient
Zespół Rozwoju

Kto zatwierdza przypadki testowe?

Menedżer testów
Przewód
Klient

Wytyczne dotyczące planu testów

Zwiń plan testów.
Unikaj nakładania się i redundancji.
Jeśli uważasz, że nie potrzebujesz sekcji, o której wspomniano powyżej, usuń ją i kontynuuj.
Być specyficznym. Na przykład, jeśli określasz system oprogramowania jako część środowiska testowego, podaj wersję oprogramowania, a nie samą nazwę.
Unikaj długich akapitów.
Jeśli to możliwe, korzystaj z list i tabel.
Aktualizuj plan w razie potrzeby.
Nie używaj przestarzałego i nieużywanego dokumentu.

Znaczenie planu testów

Plan testów nadaje kierunek naszemu myśleniu. To jest jak zbiór zasad, których należy przestrzegać.
Plan testów pomaga w określeniu niezbędnych wysiłków w celu sprawdzenia jakości aplikacji objętej testem.
Plan testów pomaga tym osobom zrozumieć szczegóły testu powiązane z czynnikami zewnętrznymi, takimi jak programiści, menedżerowie biznesowi, klienci itp.
Ważne aspekty, takie jak harmonogram testów, strategia testów, zakres testów itp., są udokumentowane w planie testów, aby zespół zarządzający mógł je przejrzeć i ponownie wykorzystać w innych podobnych projektach.