TechCodeview

Plan testiranja je detaljan dokument koji opisuje područja i aktivnosti testiranja softvera. Ocrtava strategiju testiranja, ciljeve, raspored testiranja, potrebne resurse (ljudske resurse, softver i hardver), procjenu testa i rezultate testa.

Plan testiranja je osnova testiranja svakog softvera. To je najvažnija aktivnost koja osigurava dostupnost svih popisa planiranih aktivnosti u odgovarajućem redoslijedu.

Plan testiranja je predložak za provođenje aktivnosti testiranja softvera kao definiranog procesa koji u potpunosti nadzire i kontrolira voditelj testiranja. Testni plan pripremaju voditelj testiranja (60%), voditelj testiranja (20%) i inženjer ispitivanja (20%).

Vrste testnog plana

Postoje tri vrste plana testiranja

• Glavni testni plan
• Plan testiranja faze
• Planovi ispitivanja specifični za vrstu testiranja

Glavni testni plan

Glavni plan testiranja vrsta je plana testiranja koji ima više razina testiranja. Uključuje kompletnu testnu strategiju.

Plan testiranja faze

Plan testiranja faze vrsta je plana testiranja koji se bavi bilo kojom fazom strategije testiranja. Na primjer, popis alata, popis testnih slučajeva itd.

Specifični planovi testiranja

Specifični plan testiranja dizajniran za glavne vrste testiranja kao što su sigurnosno testiranje, testiranje opterećenja, testiranje performansi itd. Drugim riječima, specifični plan testiranja dizajniran za nefunkcionalno testiranje.

Kako napisati plan testiranja

Izrada plana testiranja najvažnija je zadaća procesa upravljanja testiranjem. Prema IEEE 829, slijedite sljedećih sedam koraka za pripremu plana testiranja.

• Najprije analizirajte strukturu i arhitekturu proizvoda.
• Sada osmislite strategiju testiranja.
• Definirajte sve ciljeve testa.
• Definirajte područje testiranja.
• Definirajte sve korisne resurse.
• Rasporedite sve aktivnosti na odgovarajući način.
• Odredite sve rezultate testa.

Komponente ili atributi plana testiranja

Plan testiranja sastoji se od različitih dijelova koji nam pomažu da izvedemo cjelokupnu aktivnost testiranja.

Ciljevi: Sastoji se od informacija o modulima, značajkama, testnim podacima itd., koji označavaju cilj aplikacije, znači ponašanje aplikacije, cilj itd.

Opseg: Sadrži informacije koje je potrebno testirati s odgovarajućom aplikacijom. Opseg se dalje može podijeliti u dva dijela:

• U opsegu
• Izvan opsega

U opsegu: Ovo su moduli koje je potrebno rigorozno (detaljno) testirati.

Vanjski opseg: Ovo su moduli koje nije potrebno rigorozno testirati.

Na primjer , Pretpostavimo da imamo Gmail aplikaciju za testiranje, gdje značajke koje treba testirati kao npr Nova pošta, poslane stavke, pristigla pošta, skice i značajke koje se ne testiraju kao npr Pomozite , i tako dalje, što znači da ćemo u fazi planiranja odlučiti koju funkcionalnost treba provjeriti ili ne na temelju vremenskog ograničenja navedenog u proizvodu.

Sada kako odlučujemo koje značajke nećemo testirati?

Imamo sljedeće aspekte u kojima možemo odlučiti koju značajku nećemo testirati:

umetanje python

• Kao što vidimo iznad toga Pomozite značajke se neće testirati jer ih je napisao i razvio tehnički pisac, a recenzirao drugi profesionalni pisac.
• Pretpostavimo da imamo jednu aplikaciju koja ima P, Q, R i S značajke, koje je potrebno razviti na temelju zahtjeva. Ali ovdje je značajku S već dizajnirala i koristi neka druga tvrtka. Stoga će razvojni tim kupiti S od te tvrtke i integrirati ga s dodatnim značajkama kao što su P, Q i R.

Sada nećemo provoditi funkcionalno testiranje značajke S jer je već korištena u stvarnom vremenu. No izvršit ćemo testiranje integracije i testiranje sustava između značajki P, Q, R i S jer nove značajke možda neće ispravno raditi sa značajkom S kao što možemo vidjeti na slici ispod:

• Pretpostavimo da u prvom izdanju proizvoda, elementi koji su razvijeni, kao što je P, Q, R, S, T, U, V, W…..X, Y, Z . Sada će klijent pružiti zahtjeve za nove značajke koje poboljšavaju proizvod u drugom izdanju, a nove značajke su A1, B2, C3, D4 i E5.

Nakon toga ćemo napisati opseg tijekom testnog plana kao

Opseg

Značajke koje treba testirati

A1, B2, C3, D4, E5 (nove značajke)

P, Q, R, S, T

Značajke koje se ne testiraju

W…..X, Y, Z

Stoga ćemo prvo provjeriti nove značajke, a zatim nastaviti sa starim značajkama jer bi to moglo utjecati nakon dodavanja novih značajki, što znači da će također utjecati na područja utjecaja, pa ćemo napraviti jedan krug regresijskog testiranja za P, Q , R…, T značajke.

Metodologija testiranja:

Sadrži informacije o izvođenju različitih vrsta testiranja kao što su funkcionalno testiranje, integracijsko testiranje i testiranje sustava itd. na aplikaciji. U ovom ćemo odlučiti koju vrstu testiranja; izvršit ćemo različite značajke na temelju zahtjeva za prijavu. I ovdje bismo također trebali definirati kakvu ćemo vrstu testiranja koristiti u metodologijama testiranja kako bi svi, poput uprave, razvojnog tima i tima za testiranje mogli lako razumjeti jer uvjeti testiranja nisu standardni.

Na primjer, za samostalnu primjenu kao što je Adobe Photoshop , vršit ćemo sljedeće vrste testiranja:

Testiranje dima→ Funkcionalno testiranje → Testiranje integracije → Testiranje sustava → Adhoc testiranje → Testiranje kompatibilnosti → Regresijsko testiranje → Globalizacijsko testiranje → Testiranje pristupačnosti → Testiranje upotrebljivosti → Testiranje pouzdanosti → Testiranje oporavka → Testiranje instalacije ili deinstalacije

vrijeme večere protiv večere

I pretpostavimo da moramo testirati https://www.jeevansathi.com/ aplikacije, pa ćemo izvršiti sljedeće vrste testiranja:

Pristup

Ovaj se atribut koristi za opisivanje tijeka aplikacije tijekom izvođenja testiranja i za buduću referencu.

Možemo razumjeti tijek aplikacije uz pomoć sljedećih aspekata:

Pisanjem scenarija visoke razine Pisanjem grafa toka

Pisanjem scenarija visoke razine

Na primjer , pretpostavimo da testiramo Gmail primjena:

• Prijavite se na Gmail - šalje e-poštu i provjeri je li na stranici Poslane stavke
• Prijavite se na …….
• ……
• …....

Ovo pišemo kako bismo opisali pristupe koji se moraju poduzeti za testiranje proizvoda i samo za kritične značajke gdje ćemo napisati scenarije visoke razine. Ovdje se nećemo usredotočiti na pokrivanje svih scenarija jer određeni testni inženjer može odlučiti koje značajke treba testirati ili ne.

Pisanjem grafa toka

Grafikon toka je napisan jer je pisanje scenarija visoke razine dugotrajan proces, kao što možemo vidjeti na slici ispod:

Izrađujemo dijagrame toka kako bismo ostvarili sljedeće prednosti kao što su:

• Prekrivanje je jednostavno
• Spajanje je jednostavno

Pristup se može klasificirati u dva dijela koji su sljedeći:

• Pristup odozgo prema dolje
• Pristup odozdo prema gore

Pretpostavka

Sadrži informacije o problemu ili problemu koji se možda pojavio tijekom procesa testiranja, a kada pišemo planove testiranja, osigurane pretpostavke bi se napravile kao što su resursi i tehnologije itd.

Rizik

Ovo su izazovi s kojima se trebamo suočiti kako bismo testirali aplikaciju u trenutnom izdanju i ako pretpostavke ne uspiju, tada su uključeni i rizici.

Na primjer, učinak za aplikaciju, datum objave postaje odgođen.

Plan ublažavanja ili Plan za nepredviđene situacije

To je rezervni plan koji je pripremljen za prevladavanje rizika ili problema.

Pogledajmo jedan primjer za pretpostavku, rizik i plan za nepredviđene situacije zajedno jer su međusobno međusobno povezani.

U svakom proizvodu, pretpostavka mi ćemo napraviti je da će sva 3 test inženjera biti tamo do završetka proizvoda i svakom od njih su dodijeljeni različiti moduli kao što su P, Q i R. U ovom scenariju, rizik to bi moglo biti ako je testni inženjer napustio projekt usred njega.

Stoga, rezervni plan svakoj će značajki biti dodijeljen primarni i podređeni vlasnik. Dakle, ako jedan inženjer za ispitivanje ode, podređeni vlasnik preuzima tu specifičnu značajku i također pomaže novom inženjeru za testiranje kako bi on/ona mogao razumjeti njihove dodijeljene module.

Pretpostavke, rizik i plan ublažavanja ili nepredviđenih situacija uvijek su precizni na samom proizvodu. Različite vrste rizika su sljedeće:

• Perspektiva kupca
• Resursni pristup
• Tehničko mišljenje

Uloga i odgovornost

Definira kompletan zadatak koji treba obaviti cijeli tim za testiranje. Kad dođe veliki projekt, onda se Voditelj testiranja je osoba koja piše plan testiranja. Ako postoje 3-4 mala projekta, tada će voditelj testiranja dodijeliti svaki projekt svakom voditelju testiranja. Zatim, voditelj testiranja piše plan testiranja za projekt koji mu je dodijeljen.

Pogledajmo jedan primjer u kojem ćemo razumjeti uloge i odgovornost voditelja testiranja, voditelja ispitivanja i inženjera za testiranje.

Uloga: voditelj testiranja

Ime: Ryan

Odgovornost:

• Pripremite (napišite i pregledajte) plan testiranja
• Održi sastanak s razvojnim timom
• Održi sastanak s timom za testiranje
• Vodite sastanak s kupcem
• Održati jedan mjesečni stand up sastanak
• Potpišite obavijest o izdanju
• Rješavanje eskalacija i problema

Uloga: Voditelj testiranja

Ime: Harvey

Odgovornost:

• Pripremite (napišite i pregledajte) plan testiranja
• Održavajte dnevne stand up sastanke
• Pregledajte i odobrite testni slučaj
• Pripremite RTM i izvješća
• Dodijelite module
• Raspored rukovanja

Uloga: Testni inženjer 1, Testni inženjer 2 i Testni inženjer 3

Ime: Louis, Jessica, Donna

Dodijelite module: M1, M2 i M3

Odgovornost:

• Napišite, pregledajte i izvršite testne dokumente koji se sastoje od testnih slučajeva i testnih scenarija
• Pročitajte, pregledajte, razumite i analizirajte zahtjev
• Napišite tijek aplikacije
• Izvršite test slučaj
• RTM za odgovarajuće module
• Praćenje kvarova
• Pripremite izvješće o izvršenju testa i prenesite ga voditelju testa.

Raspored

Koristi se za objašnjenje vremena za rad, što treba učiniti ili ovaj atribut pokriva kada točno svaka aktivnost testiranja treba započeti i završiti? Također se navode i točni podaci za svaku aktivnost testiranja za određeni datum.

Stoga, kao što možemo vidjeti na donjoj slici, za određenu aktivnost postojat će datum početka i datum završetka; za svako testiranje određene građevine postojat će određeni datum.

Na primjer

• Pisanje testnih slučajeva
• Proces izvršenja

Praćenje kvarova

To se općenito radi uz pomoć alata jer ne možemo ručno pratiti status svake pogreške. Također komentiramo kako priopćavamo greške koje su identificirane tijekom procesa testiranja i šaljemo ih nazad razvojnom timu te kako će razvojni tim odgovoriti. Ovdje također spominjemo prioritet grešaka kao što su visoki, srednji i niski.

Slijede različiti aspekti praćenja kvarova:

Tehnike za praćenje buga
…..
……
……
……Alati za praćenje bugova
Možemo komentirati naziv alata koji ćemo koristiti za praćenje grešaka. Neki od najčešće korištenih alata za praćenje bugova su Jira, Bugzilla, Mantis i Trac itd.<Ozbiljnost
Ozbiljnost bi mogla biti sljedeća:
Blokator ili showstopper
…..
….. (Objasnite to primjerom u planu testiranja)
Na primjer , doći će do kvara u modulu; ne možemo dalje testirati druge module jer ako je bug blokiran, možemo nastaviti s provjerom drugih modula.
Kritično
……
….. (Objasnite to primjerom u planu testiranja)
U ovoj situaciji nedostaci će utjecati na poslovanje.
Major
….
…. (Objasnite to primjerom u planu testiranja)
Minor
…..
….. (Objasnite to primjerom u planu testiranja)
To su nedostaci koji utječu na izgled i dojam aplikacije.Prioritet
Visoki P1
…..
Srednji-P2
…..
Niski P3
…..
…..
P4

Stoga, na temelju prioriteta grešaka poput visokog, srednjeg i niskog, kategorizirat ćemo ga kao P1, P2, P3 i P4.

Testna okruženja

Ovo su okruženja u kojima ćemo testirati aplikaciju, a ovdje imamo dvije vrste okruženja, koja su od softver i hardver konfiguracija.

The konfiguracija softvera znači pojedinosti o različitim Operacijski sustavi kao npr Windows, Linux, UNIX i Mac i razne Preglednici Kao Google Chrome, Firefox, Opera, Internet Explorer , i tako dalje.

i hardverska konfiguracija znači informacije o različitim veličinama RAM, ROM i procesori .

Na primjer

• The Softver uključuje sljedeće:

poslužitelj

Napomena: gore navedeni poslužitelji su servisi koje koristi tim za testiranje za testiranje aplikacije.

Klijent

selenium tutorial java

Napomena: Gore navedene pojedinosti daju različite operativne sustave i preglednike u kojima će tim za testiranje testirati aplikaciju.

• The Hardver uključuje sljedeće:

poslužitelj : Sun StarCat 1500

Tim za testiranje može koristiti ovaj poslužitelj za testiranje svoje aplikacije.

Klijent:

Ima sljedeću konfiguraciju, koja je sljedeća:

Napomena: Osigurat će konfiguraciju sustava inženjera za testiranje koji je tim za testiranje.

Postupak instaliranja softvera
……
…..
…..

Razvojni tim osigurat će konfiguraciju kako instalirati softver. Ako razvojni tim još ne pruži proces, tada ćemo ga napisati kao Razvoj temeljen na zadacima (TBD) u planu testiranja.

Ulazni i izlazni kriteriji

To je nužan uvjet koji treba biti zadovoljen prije pokretanja i zaustavljanja procesa testiranja.

Kriteriji za ulazak

Kriteriji za upis sadrže sljedeće uvjete:

• Testiranje bijele kutije trebalo bi biti završeno.
• Razumjeti i analizirati zahtjev i pripremiti ispitne dokumente ili kada ispitni dokumenti budu spremni.
• Podaci o ispitivanju trebaju biti spremni.
• Graditi ili aplikacija mora biti pripremljena
• Module ili značajke potrebno je dodijeliti različitim inženjerima za testiranje.
• Potreban resurs mora biti spreman.

Kriteriji za izlazak

Izlazni kriteriji sadrže sljedeće uvjete:

• Kada se izvrše svi testni slučajevi.
• Većina testnih slučajeva mora biti prošao .
• Ovisi o ozbiljnosti grešaka, što znači da ne smije postojati nikakav bloker ili veća greška, dok neke manje greške postoje.

Prije nego počnemo provoditi funkcionalna ispitivanja, sve gore navedeno Kriteriji za ulazak treba slijediti. Nakon što smo proveli funkcionalno testiranje i prije nego što ćemo napraviti integracijsko testiranje, onda je Izlazni kriteriji treba slijediti funkcionalno testiranje jer se postotak izlaznih kriterija odlučuje na sastanku s voditeljem razvoja i testa jer se njihovom suradnjom može postići postotak. Ali ako se ne poštuju izlazni kriteriji funkcionalnog testiranja, ne možemo nastaviti s integracijskim testiranjem.

Ovdje na temelju ozbiljnosti bugova znači da bi tim za testiranje odlučio da nastavi dalje za sljedeće faze.

git dodaj sve

Automatizacija testiranja

U ovom ćemo odlučiti sljedeće:

• Koja značajka mora biti automatizirana, a koja ne?
• Koji ćemo alat za automatizaciju testiranja koristiti na kojem okviru za automatizaciju?

Testni slučaj automatiziramo tek nakon prvog izdanja.

Ovdje se postavlja pitanje na temelju čega mi htjeti odlučiti koje značajke treba testirati?

Na gornjoj slici, kao što možemo vidjeti, najčešće korištene značajke treba uvijek iznova testirati. Pretpostavimo da moramo provjeriti aplikaciju Gmail gdje se nalaze bitne značajke Nova pošta, Poslane stavke i Pristigla pošta . Stoga ćemo testirati ove značajke jer ručno testiranje oduzima više vremena, a postaje i monoton posao.

Sada, kako odlučujemo koje značajke nećemo testirati?

Pretpostavimo pomoć značajka aplikacije Gmail ne testira se uvijek iznova jer se te značajke ne koriste redovito, pa je ne moramo često provjeravati.

Ali ako su neke značajke nestabilne i imaju puno grešaka , što znači da nećemo testirati te značajke jer se moraju testirati uvijek iznova tijekom ručnog testiranja.

Ako postoji značajka koja se mora često testirati , ali očekujemo promjenu zahtjeva za tu značajku, pa je ne provjeravamo jer je promjena ručnih testnih slučajeva ugodnija u usporedbi s promjenom u testnoj skripti automatizacije.

Procjena napora

Pri tome ćemo planirati napor koji treba uložiti svaki član tima.

Isporuka testa

Ovo su dokumenti koji su rezultat tima za testiranje, a koje smo zajedno s proizvodom predali kupcu. Uključuje sljedeće:

Plan testiranja Testni slučajevi Testne skripte RTM (Matrica sljedivosti zahtjeva) Izvješće o kvaru Izvješće o izvršenju testa Grafikoni i metrika Bilješke o izdanju

Grafikoni i metrike

Grafikon

U ovom ćemo govoriti o vrstama grafovi poslat ćemo, a također ćemo osigurati uzorak svakog grafikona.

Kao što vidimo, imamo pet različitih grafikona koji prikazuju različite aspekte procesa testiranja.

Grafikon 1: Ovdje ćemo pokazati koliko je grešaka identificirano i koliko je grešaka popravljeno u svakom modulu.

Grafikon 2: Slika jedan pokazuje koliko je kritičnih, većih i manjih nedostataka identificirano za svaki modul i koliko ih je popravljeno za odgovarajuće module.

Grafikon 3: U ovom konkretnom grafikonu predstavljamo izgraditi mudar grafikon , što znači da je u svakoj verziji koliko je nedostataka identificirano i popravljeno za svaki modul. Na temelju modula utvrdili smo bugove. Dodat ćemo R za prikaz broja nedostataka u P i Q, a mi također zbrajamo S da pokaže nedostatke u P, Q i R.

Grafikon 4: Voditelj ispitivanja će dizajnirati Analiza trenda grešaka graf koji se izrađuje svaki mjesec i šalje ga i Upravi. I to je kao predviđanje koje se radi na kraju proizvoda. A evo, možemo i mi ocijenite ispravke grešaka kako to možemo primijetiti luk ima tendencija prema gore na slici ispod.

Grafikon 5: The Voditelj testiranja dizajnirao je ovu vrstu grafikona. Ovaj grafikon je namijenjen razumijevanju jaza u procjeni grešaka i stvarnih grešaka koje su se pojavile, a ovaj grafikon također pomaže u poboljšanju procjene grešaka u budućnosti.

Metrika

Kao i gore, stvaramo graf distribucije bugova, koji je na slici 1, a uz pomoć gore navedenih podataka, dizajnirat ćemo i metriku.

Na primjer

Na gornjoj slici čuvamo evidenciju svih inženjera za ispitivanje u određenom projektu i koliko je nedostataka identificirano i popravljeno. Ove podatke također možemo koristiti za buduću analizu. Kada dođe novi zahtjev, možemo odlučiti kome pružiti izazovnu značajku za testiranje na temelju broja nedostataka koje su ranije pronašli prema gore navedenim metrikama. I bit ćemo u boljoj situaciji da znamo tko se može vrlo dobro nositi s problematičnim značajkama i pronaći najveći broj nedostataka.

Napomena o izdanju: To je dokument koji se priprema tijekom puštanja proizvoda u promet i potpisuje Test Manager.

Na donjoj slici možemo vidjeti da je konačni proizvod razvijen i implementiran kupcu, a naziv posljednjeg izdanja je Beta .

The Napomena o izdanju sastoji se od sljedećeg:

• Korisnički priručnik.
• Popis neriješenih i otvorenih nedostataka.
• Popis dodanih, izmijenjenih i izbrisanih značajki.
• Popis platformi (operativni sustav, hardver, preglednici) na kojima je proizvod testiran.
• Platforma na kojoj se proizvod ne testira.
• Popis grešaka ispravljenih u trenutnom izdanju i popis ispravljenih grešaka u prethodnom izdanju.
• Postupak instalacije
• Verzije softvera

Na primjer

Pretpostavljam da Beta je drugo izdanje aplikacije nakon prvog izdanja Alfa pušteno je. Neki od nedostataka koji su identificirani u prvom izdanju i koji su popravljeni u kasnijem izdanju. Ovdje ćemo također istaknuti popis novododanih, modificiranih i izbrisanih značajki od alfa izdanja do beta izdanja.

Predložak

Ovaj dio sadrži sve predloške za dokumente koji će se koristiti u proizvodu, a svi testni inženjeri koristit će samo te predloške u projektu kako bi održali dosljednost proizvoda. Ovdje imamo različite vrste predložaka koji se koriste tijekom cijelog procesa testiranja, kao što su:

• Predložak testnog slučaja
• Predložak pregleda testnog slučaja
• RTM predložak
• Predložak izvješća o pogrešci
• Izvješće o izvršenju testa

Pogledajmo jedan uzorak dokumenta plana testiranja

Stranica 1

Stranica3-stranica18

Stranica-20

Na stranici 1 primarno ispunjavamo samo Verzije, autor, komentari i recenzent polja, a nakon što upravitelj to odobri, detalje ćemo navesti u Odobreno do i datum odobrenja polja.

Uglavnom plan testiranja odobrava Test Manager, a test inženjeri ga samo pregledavaju. A kada dođu nove značajke, izmijenit ćemo plan testiranja i unijeti potrebne izmjene Verzija polje, a zatim će se ponovno poslati na daljnji pregled, ažuriranje i odobrenje upravitelju. Plan testiranja mora se ažurirati kad god dođe do bilo kakvih promjena. Na stranici 20, Reference navedite detalje o svim dokumentima koje ćemo koristiti za pisanje dokumenta plana testiranja.

Bilješka:

Tko piše plan testiranja?

• Testni vod → 60%
• Test Manager→20%
• Test inženjer → 20%

Stoga, kao što možemo vidjeti gore, u 60% proizvoda, testni plan piše Test Lead.

Tko pregledava plan testiranja?

• Test Lead
• Voditelj testiranja
• Test inženjer
• Kupac
• Razvojni tim

Inženjer za testiranje pregledava plan testiranja za svoju perspektivu modula, a voditelj testiranja pregledava plan testiranja na temelju mišljenja korisnika.

Tko odobrava plan testiranja?

• Kupac
• Voditelj testiranja

Tko piše test slučaj?

• Test Lead
• Inženjer ispitivanja

Tko pregledava test slučaj?

pretvorba java niza u int

• Inženjer ispitivanja
• Test Lead
• Kupac
• Razvojni tim

Tko odobrava testne slučajeve?

• Voditelj testiranja
• Test Lead
• Kupac

Smjernice za plan testiranja

• Sažmite svoj plan testiranja.
• Izbjegavajte preklapanje i redundantnost.
• Ako mislite da vam ne treba dio koji je već spomenut gore, onda izbrišite taj odjeljak i nastavite dalje.
• Budi precizan. Na primjer, kada navedete softverski sustav kao dio testnog okruženja, tada navedite verziju softvera umjesto samo naziva.
• Izbjegavajte duge paragrafe.
• Koristite popise i tablice gdje god je to moguće.
• Ažurirajte plan po potrebi.
• Nemojte koristiti zastarjeli i neiskorišteni dokument.

Važnost plana testiranja

• Plan testiranja daje smjer našim razmišljanjima. Ovo je kao pravilnik, koji se mora poštovati.
• Plan testiranja pomaže u određivanju potrebnih napora za provjeru kvalitete softverske aplikacije koja se testira.
• Testni plan pomaže tim ljudima da razumiju detalje testa koji su povezani s vanjskim razvojem, poslovnim menadžerima, kupcima itd.
• Važni aspekti poput rasporeda testiranja, strategije testiranja, opsega testiranja itd. dokumentirani su u planu testiranja kako bi ih upravljački tim mogao pregledati i ponovno upotrijebiti za druge slične projekte.