Testavimo planas yra išsamus dokumentas, kuriame aprašomos programinės įrangos testavimo sritys ir veikla. Jame aprašoma testavimo strategija, tikslai, bandymų tvarkaraštis, reikalingi ištekliai (žmogiškieji ištekliai, programinė įranga ir techninė įranga), testo įvertinimas ir bandymo rezultatai.

Testavimo planas yra kiekvienos programinės įrangos testavimo pagrindas. Tai pati svarbiausia veikla, užtikrinanti visų planuojamų veiklų sąrašų prieinamumą atitinkama seka.

Testavimo planas yra šablonas, skirtas programinės įrangos testavimo veiklai atlikti kaip apibrėžtam procesui, kurį visiškai stebi ir kontroliuoja testavimo vadovas. Bandymo planą parengia bandymo vadovas (60 %), bandymų vadovas (20 %) ir bandymų inžinierius (20 %).

Bandymų plano tipai

Yra trys bandymų plano tipai

• Pagrindinis bandymų planas
• Fazinio bandymo planas
• Tikrinimo tipo specifiniai bandymų planai

Pagrindinis bandymų planas

Pagrindinis bandymų planas yra bandymų plano tipas, kuriame yra keli bandymų lygiai. Tai apima visą bandymo strategiją.

Fazinio bandymo planas

Fazinio bandymo planas yra bandymo plano tipas, apimantis bet kurį vieną testavimo strategijos etapą. Pavyzdžiui, įrankių sąrašas, bandomųjų atvejų sąrašas ir kt.

Specialūs bandymų planai

Konkretus bandymų planas, skirtas pagrindiniams testavimo tipams, pvz., saugumo testavimui, apkrovos testavimui, našumo testavimui ir kt. Kitaip tariant, konkretus testavimo planas, skirtas nefunkciniam testavimui.

Kaip parašyti testo planą

Testavimo plano sudarymas yra pati svarbiausia bandymo valdymo proceso užduotis. Pagal IEEE 829, atlikite toliau nurodytus septynis veiksmus, kad parengtumėte bandymo planą.

• Pirmiausia išanalizuokite produkto struktūrą ir architektūrą.
• Dabar sukurkite bandymo strategiją.
• Apibrėžkite visus testo tikslus.
• Apibrėžkite bandymo sritį.
• Apibrėžkite visus naudojamus išteklius.
• Suplanuokite visą veiklą tinkamu būdu.
• Nustatykite visus bandymo rezultatus.

Bandymo plano komponentai arba atributai

Testavimo planas susideda iš įvairių dalių, kurios padeda mums išvesti visą testavimo veiklą.

Tikslai: Jį sudaro informacija apie modulius, funkcijas, testavimo duomenis ir tt, nurodanti programos tikslą, tai reiškia programos elgesį, tikslą ir pan.

Taikymo sritis: Jame yra informacijos, kurią reikia išbandyti su atitinkama programa. Apimtį dar galima suskirstyti į dvi dalis:

• Apimtyje
• Iš jo ribų

Taikymo sritis: Tai yra moduliai, kuriuos reikia griežtai išbandyti (išsamiai).

Iš jo ribų: Tai yra moduliai, kurių nereikia griežtai tikrinti.

Pavyzdžiui , Tarkime, kad turime „Gmail“ programą, kurią galime išbandyti, kur funkcijas, kurias reikia išbandyti toks kaip Rašyti laiškus, išsiųstas prekes, gautuosius, juodraščius ir funkcijos, kurios nebus išbandytos toks kaip Pagalba , ir taip toliau, o tai reiškia, kad planavimo etape pagal gaminyje nurodytą terminą nuspręsime, kuris funkcionalumas turi būti tikrinamas ar ne.

Dabar kaip nusprendžiame, kurių funkcijų nebandyti?

Turime šiuos aspektus, pagal kuriuos galime nuspręsti, kurios funkcijos nebandyti:

• Kaip matome aukščiau Pagalba funkcijos nebus išbandytos, nes ją parašė ir sukūrė techninis rašytojas, o peržiūri kitas profesionalus rašytojas.
• Tarkime, kad turime vieną programą P, Q, R ir S ypatybes, kurias reikia plėtoti atsižvelgiant į reikalavimus. Tačiau čia S funkcija jau buvo sukurta ir naudojama kai kurios kitos įmonės. Taigi kūrimo komanda pirks S iš tos įmonės ir integruos su papildomomis funkcijomis, tokiomis kaip P, Q ir R.

Dabar neatliksime S funkcijos funkcinio testavimo, nes ji jau buvo naudojama realiuoju laiku. Bet mes atliksime integracijos testavimą ir sistemos testavimą tarp P, Q, R ir S funkcijų, nes naujos funkcijos gali tinkamai neveikti su S funkcija, kaip matome toliau pateiktame paveikslėlyje:

• Tarkime, pirmajame gaminio leidime sukurti elementai, pvz P, Q, R, S, T, U, V, W…..X, Y, Z . Dabar klientas pateiks reikalavimus naujoms funkcijoms, kurios pagerins produktą antroje laidoje, o naujos funkcijos yra A1, B2, C3, D4 ir E5.

Po to bandymo plano metu apimtį parašysime kaip

Taikymo sritis

Savybės, kurias reikia išbandyti

A1, B2, C3, D4, E5 (naujos funkcijos)

P, Q, R, S, T

Savybės, kurių nereikia tikrinti

W…..X, Y, Z

Todėl pirmiausia patikrinsime naujas funkcijas, o tada tęsime senąsias, nes tai gali turėti įtakos pridėjus naujas funkcijas, o tai reiškia, kad tai turės įtakos ir poveikio sritims, todėl atliksime vieną regresinio P, Q testavimo raundą. , R…, T funkcijos.

Bandymo metodika:

Jame pateikiama informacija apie kitokio tipo programos testavimą, pvz., funkcinį testavimą, integravimo testavimą, sistemos testavimą ir kt. Čia mes nuspręsime, kokio tipo testavimas; vykdysime įvairias funkcijas, atsižvelgdami į programos reikalavimus. Ir čia taip pat turėtume apibrėžti, kokį testavimą naudosime testavimo metodikose, kad visi, kaip ir vadovybė, ir kūrimo komanda, ir testavimo komanda, galėtų lengvai suprasti, nes testavimo sąlygos nėra standartinės.

Pavyzdžiui, atskiroms programoms, tokioms kaip Adobe Photoshop , atliksime šių tipų bandymus:

Dūmų testavimas → Funkcinis testavimas → Integracijos testavimas → Sistemos testavimas → Adhoc testavimas → Suderinamumo testavimas → Regresijos testavimas → Globalizacijos testavimas → Prieinamumo testavimas → Naudojimo testavimas → Patikimumo testavimas → Atkūrimo testavimas → Diegimo arba pašalinimo testavimas

Ir tarkime, kad turime išbandyti https://www.jeevansathi.com/ programą, todėl atliksime šių tipų testus:

metodas

Šis atributas naudojamas aprašyti programos eigą atliekant testavimą ir ateičiai.

Mes galime suprasti programos eigą naudodamiesi šiais aspektais:

Rašydami aukšto lygio scenarijus Rašydami srauto grafiką

Rašydami aukšto lygio scenarijus

Pavyzdžiui , tarkime, kad bandome Gmail taikymas:

• Prisijungimas prie Gmail – išsiunčia el. laišką ir patikrina, ar jis yra puslapyje Išsiųstos prekės
• Prisijungti …….
• ……
• ......

Rašome tai norėdami apibūdinti metodus, kurių reikia laikytis bandant gaminį ir tik dėl svarbiausių savybių, kuriose rašysime aukšto lygio scenarijus. Čia mes nesikoncentruosime į visų scenarijų aprėptį, nes konkretus bandymų inžinierius gali nuspręsti, kurias funkcijas reikia išbandyti, ar ne.

Rašydami srauto grafiką

Srauto grafikas parašyta, nes aukšto lygio scenarijų rašymas užtrunka šiek tiek laiko, kaip matome toliau pateiktame paveikslėlyje:

Kuriame srauto diagramas, kad gautume tokius privalumus, kaip:

• Aprėptis lengva
• Sujungti lengva

Metodas gali būti suskirstytas į dvi dalis, kurios yra šios:

• Iš viršaus į apačią požiūris
• Priėjimas iš apačios į viršų

Prielaida

Jame pateikiama informacija apie problemą ar problemą, kuri galėjo įvykti testavimo proceso metu, o kai rašome testavimo planus, bus daromos užtikrintos prielaidos, pvz., ištekliai, technologijos ir pan.

oracle sql nelygu

Rizika

Tai yra iššūkiai, su kuriais turime susidurti norėdami išbandyti programą dabartinėje laidoje, o jei prielaidos nepavyks, kyla rizika.

Pavyzdžiui, paraiškos galiojimas, išleidimo data nukeliama.

Sušvelninimo planas arba nenumatytų atvejų planas

Tai atsarginis planas, parengtas norint įveikti riziką ar problemas.

Pažiūrėkime vieną prielaidos, rizikos ir nenumatytų atvejų plano pavyzdį kartu, nes jie yra susiję vienas su kitu.

Bet kuriame gaminyje, prielaida mes padarysime, kad visi 3 bandymų inžinieriai bus ten iki gaminio užbaigimo ir kiekvienam iš jų bus priskirti skirtingi moduliai, pvz., P, Q ir R. Pagal šį konkretų scenarijų rizika gali būti, kad bandymų inžinierius paliktų projektą jo viduryje.

Todėl, Nenumatytų atvejų planas kiekvienai funkcijai bus priskirtas pagrindinis ir antrasis savininkas. Taigi, jei vienas bandytojas išeis, pavaldus savininkas perima tą specifinę funkciją ir taip pat padeda naujajam testuotojui, kad jis suprastų jam priskirtus modulius.

Prielaidos, rizika ir mažinimo arba nenumatytų atvejų planas visada yra tikslūs pačiame gaminyje. Įvairios rizikos rūšys yra šios:

• Kliento perspektyva
• Išteklių požiūris
• Techninė nuomonė

Vaidmuo ir atsakomybė

Jis apibrėžia visą užduotį, kurią turi atlikti visa testavimo komanda. Kai ateina didelis projektas, tada Testo vadovas yra asmuo, kuris rašo testo planą. Jei yra 3-4 maži projektai, testavimo vadovas priskirs kiekvieną projektą kiekvienam testavimo vadovui. Tada testavimo vadovas parašo projekto testavimo planą, kuris jam yra priskirtas.

Pažiūrėkime vieną pavyzdį, kuriame suprasime testavimo vadovo, bandomojo vadovo ir bandymų inžinierių vaidmenis ir atsakomybę.

Vaidmuo: testavimo vadovas

Vardas: Ryanas

Atsakomybė:

• Paruoškite (parašykite ir peržiūrėkite) testo planą
• Surengti susitikimą su kūrimo komanda
• Surengti susitikimą su testavimo komanda
• Vykdykite susitikimą su klientu
• Surengti vieną mėnesinį stand-up susirinkimą
• Pasirašyti išleidimo pranešimą
• Eskalacijų ir problemų tvarkymas

Vaidmuo: bandomasis vadovas

Vardas: Harvey

Atsakomybė:

• Paruoškite (parašykite ir peržiūrėkite) testo planą
• Kasdien veskite „stand up“ susitikimą
• Peržiūrėkite ir patvirtinkite bandomąjį atvejį
• Paruoškite RTM ir ataskaitas
• Priskirkite modulius
• Tvarkymo grafikas

Vaidmuo: 1 bandymų inžinierius, 2 bandymų inžinierius ir 3 bandymų inžinierius

Vardas: Louis, Jessica, Donna

Priskirkite modulius: M1, M2 ir M3

Atsakomybė:

• Parašykite, peržiūrėkite ir vykdykite bandymo dokumentus, kuriuos sudaro bandomasis atvejis ir bandymo scenarijai
• Perskaitykite, peržiūrėkite, supraskite ir išanalizuokite reikalavimą
• Parašykite programos eigą
• Atlikite bandomąjį atvejį
• RTM atitinkamiems moduliams
• Defektų sekimas
• Paruoškite bandymo vykdymo ataskaitą ir perduokite ją bandymo vadovui.

Tvarkaraštis

Jis naudojamas paaiškinti darbo laiką, ką reikia padaryti, ar šis požymis nurodo, kada tiksliai turi prasidėti ir baigtis kiekviena testavimo veikla? Taip pat nurodomi tikslūs kiekvienos konkrečios datos testavimo veiklos duomenys.

Todėl, kaip matome žemiau esančiame paveikslėlyje, tam tikros veiklos pradžia ir pabaigos data; Kiekvienam konkrečios versijos testavimui bus nurodyta data.

Pavyzdžiui

• Testinių atvejų rašymas
• Vykdymo procesas

Defektų sekimas

Paprastai tai daroma naudojant įrankius, nes negalime sekti kiekvienos klaidos būsenos rankiniu būdu. Taip pat komentuojame, kaip pranešame apie klaidas, kurios buvo nustatytos testavimo metu, ir siunčiame jas atgal kūrimo komandai ir kaip kūrimo komanda atsakys. Čia taip pat minime klaidų, tokių kaip didelė, vidutinė ir žema, prioritetą.

Toliau pateikiami įvairūs defektų stebėjimo aspektai:

Klaidos sekimo būdai
…..
……
……
……Klaidų sekimo įrankiai
Galime pakomentuoti įrankio pavadinimą, kurį naudosime klaidų sekimui. Kai kurie dažniausiai naudojami klaidų sekimo įrankiai yra „Jira“, „Bugzilla“, „Mantis“, „Trac“ ir kt.<Sunkumas
Sunkumas gali būti toks:
Blokatorius arba demonstravimo blokas
....
..... (Paaiškinkite tai pavyzdžiu bandymo plane)
Pavyzdžiui , bus modulio defektas; negalime toliau tikrinti kitų modulių, nes jei klaida užblokuota, galime pradėti tikrinti kitus modulius.
Kritinis
……
..... (Paaiškinkite tai pavyzdžiu bandymo plane)
Esant tokiai situacijai, defektai turės įtakos verslui.
majoras
….
…. (Paaiškinkite tai pavyzdžiu bandymo plane)
Nepilnametis
....
..... (Paaiškinkite tai pavyzdžiu bandymo plane)
Šie trūkumai turi įtakos programos išvaizdai ir pojūtiui.Pirmenybė
Aukštas P1
....
Vidutinis-P2
....
Žemas P3
....
....
P4

Todėl, atsižvelgdami į klaidų prioritetą liike high, medium ir low, skirsime jį į P1, P2, P3 ir P4 kategorijas.

pridedant prie masyvo java

Bandymo aplinkos

Tai yra aplinkos, kuriose išbandysime programą, o čia turime dviejų tipų aplinkas, kurios yra iš programinė įranga ir aparatūra konfigūracija.

The programinės įrangos konfigūracija reiškia informaciją apie skirtingus Operacinės sistemos toks kaip Windows, Linux, UNIX ir Mac ir įvairių Naršyklės Kaip Google Chrome, Firefox, Opera, Internet Explorer , ir taip toliau.

Ir aparatinės įrangos konfigūracija reiškia informaciją apie skirtingus dydžius RAM, ROM ir procesoriai .

Pavyzdžiui

• The Programinė įranga apima:

Serveris

Pastaba: pirmiau minėti serveriai yra serveriai, kuriuos testavimo komanda naudoja programai išbandyti.

Klientas

Pastaba: Aukščiau pateikta informacija nurodo įvairias operacines sistemas ir naršykles, kuriose testavimo komanda išbandys programą.

• The Aparatūra apima:

Serveris : Sun StarCat 1500

Šį konkretų serverį testavimo komanda gali naudoti savo programai išbandyti.

Klientas:

Jis turi tokią konfigūraciją, kuri yra tokia:

Pastaba: ji pateiks testavimo inžinierių, kurie yra testavimo komanda, sistemų konfigūraciją.

Programinės įrangos diegimo procesas
……
....
....

Kūrimo komanda pateiks programinės įrangos diegimo konfigūraciją. Jei kūrimo komanda dar nepateiks proceso, testavimo plane jį įrašysime kaip užduotimis pagrįstą plėtrą (TBD).

Įėjimo ir išėjimo kriterijai

Tai būtina sąlyga, kurią reikia įvykdyti prieš pradedant ir sustabdant testavimo procesą.

Įėjimo kriterijai

Įėjimo kriterijai apima šias sąlygas:

• Baltos dėžutės bandymas turėtų būti baigtas.
• Suprasti ir analizuoti reikalavimą ir parengti testo dokumentus arba kai testo dokumentai yra paruošti.
• Bandymo duomenys turi būti paruošti.
• Sukurti arba paraiška turi būti parengta
• Moduliai arba funkcijos turi būti priskirti skirtingiems bandymų inžinieriams.
• Būtinas išteklius turi būti paruoštas.

Išėjimo kriterijai

Išėjimo kriterijai apima šias sąlygas:

• Kai visi bandomieji atvejai yra įvykdyti.
• Dauguma bandomųjų atvejų turi būti praėjo .
• Priklauso nuo klaidų sunkumo, o tai reiškia, kad neturi būti blokavimo ar didelių klaidų, o kai kurios nedidelės klaidos egzistuoja.

Prieš pradėdami atlikti funkcinį testavimą, visa tai, kas išdėstyta aukščiau Įėjimo kriterijai turėtų būti laikomasi. Atlikę funkcinį testavimą ir prieš atlikdami integracijos testavimą, tada Išėjimo kriterijai Funkcinis testavimas turėtų būti laikomasi, nes išėjimo kriterijų procentas nustatomas susitikus tiek su kūrimo, tiek su testavimo vadovu, nes jų bendradarbiavimas gali pasiekti procentą. Bet jei nesilaikoma funkcinio testavimo išėjimo kriterijų, negalime tęsti integracijos testavimo.

čia remiantis sunkumu klaida reiškia, kad testavimo komanda būtų nusprendusi tęsti kitus etapus.

Testavimo automatika

Šiuo atveju mes nuspręsime:

• Kuri funkcija turi būti automatizuota, o ne automatizuota?
• Kurį testavimo automatizavimo įrankį naudosime kurioje automatizavimo sistemoje?

Bandomąjį atvejį automatizuojame tik po pirmo leidimo.

Čia kyla klausimas, kuo remiantis mes valios nuspręsti, kurias funkcijas reikia išbandyti?

Kaip matome aukščiau esančiame paveikslėlyje, dažniausiai naudojamas funkcijas reikia išbandyti vėl ir vėl. Tarkime, kad turime patikrinti „Gmail“ programą, kurioje yra pagrindinės funkcijos Sukurkite laiškus, išsiųstus elementus ir gautuosius . Taigi išbandysime šias funkcijas, nes atliekant rankinį testavimą, tai užtrunka daugiau laiko, be to, tai tampa monotonišku darbu.

Dabar kaip nusprendžiame, kurios funkcijos nebus išbandytos?

Tarkime Pagalba „Gmail“ programos funkcija nėra išbandoma vėl ir vėl, nes šios funkcijos nėra reguliariai naudojamos, todėl nereikia jos dažnai tikrinti.

Bet jei kai kurios funkcijos yra nestabilios ir turi daug klaidų , o tai reiškia, kad mes tų funkcijų nebandysime, nes atliekant rankinį testavimą ją reikia išbandyti vėl ir vėl.

Jeigu yra funkcija, kurią reikia dažnai tikrinti , tačiau laukiame tos funkcijos reikalavimų pakeitimo, todėl netikriname, nes rankinio bandymo atvejus keisti patogiau, palyginti su automatizavimo testo scenarijaus pakeitimu.

Pastangų įvertinimas

Čia mes suplanuosime pastangas, kurias turės dėti kiekvienas komandos narys.

Testas Pristatomas

Tai dokumentai, kurie yra testavimo komandos išvestis, kuriuos kartu su produktu perdavėme klientui. Tai apima:

Bandymo planas Bandymo atvejai Bandomieji scenarijai RTM (reikalavimų atsekamumo matrica) Defektų ataskaita Bandymo vykdymo ataskaita Grafikai ir metrika Išleidimo pastabos

Grafikai ir metrika

Grafikas

Čia mes kalbėsime apie jų rūšis grafikai atsiųsime, taip pat pateiksime kiekvieno grafiko pavyzdį.

Kaip matome, turime penkis skirtingus grafikus, parodančius įvairius testavimo proceso aspektus.

1 grafikas: Čia parodysime, kiek defektų buvo nustatyta ir kiek defektų ištaisyta kiekviename modulyje.

2 diagrama: Pirmame paveikslėlyje parodyta, kiek kritinių, didelių ir smulkių defektų buvo nustatyta kiekvienam moduliui ir kiek jų buvo ištaisyta atitinkamuose moduliuose.

3 grafikas: Šiame konkrečiame grafike atstovaujame sukurti išmintingą grafiką , o tai reiškia, kad kiekvienoje versijoje kiek defektų buvo nustatyta ir ištaisyta kiekvienam moduliui. Remdamiesi moduliu, nustatėme klaidas. Pridėsime R parodyti defektų skaičių P ir Q, taip pat pridedame S parodyti P, Q ir R defektus.

4 diagrama: Bandymo laidas suprojektuos Klaidų tendencijų analizė grafiką, kuris sukuriamas kas mėnesį ir nusiunčia jį vadovybei. Ir tai yra kaip numatymas, kuris atliekamas produkto pabaigoje. Ir čia mes taip pat galime įvertinkite klaidų taisymus kaip galime tai pastebėti lankas turi an tendencija aukštyn žemiau esančiame paveikslėlyje.

5 diagrama: The Testo vadovas sukūrė tokio tipo grafiką. Ši diagrama skirta suprasti klaidų vertinimo spragas ir faktines klaidas, kurios buvo įvykusios. Ši diagrama taip pat padeda pagerinti klaidų įvertinimą ateityje.

Metrika

Kaip ir aukščiau, mes sukuriame klaidų pasiskirstymo grafiką, kuris yra 1 paveiksle, o aukščiau paminėtų duomenų pagalba suprojektuosime ir metrikas.

Pavyzdžiui

Aukščiau pateiktame paveikslėlyje išsaugome visų konkretaus projekto bandymų inžinierių įrašus ir tai, kiek defektų buvo nustatyta ir ištaisyta. Šiuos duomenis taip pat galime naudoti būsimai analizei. Kai atsiranda naujas reikalavimas, galime nuspręsti, kam suteikti sudėtingą testavimo funkciją, atsižvelgdami į anksčiau nustatytų defektų skaičių pagal aukščiau pateiktą metriką. Ir mes būsime geresnėje situacijoje, kad žinotume, kas gali puikiai susidoroti su probleminėmis savybėmis ir rasti maksimalų defektų skaičių.

Išleidimo pastaba: Tai dokumentas, kuris rengiamas gaminio išleidimo metu ir kurį pasirašo Testo vadovas.

Žemiau esančiame paveikslėlyje matome, kad galutinis produktas yra sukurtas ir įdiegtas klientui, o naujausio leidimo pavadinimas yra Beta .

The Išleidimo pastaba susideda iš šių dalių:

• Vartotojo vadovas.
• Laukiamų ir atvirų defektų sąrašas.
• Pridėtų, pakeistų ir ištrintų funkcijų sąrašas.
• Platformos (operacinė sistema, aparatinė įranga, naršyklės), kurioje gaminys bandomas, sąrašas.
• Platforma, kurioje produktas nėra išbandytas.
• Dabartiniame leidime ištaisytų klaidų sąrašas ir ankstesniame leidime ištaisytų klaidų sąrašas.
• Diegimo procesas
• Programinės įrangos versijos

Pavyzdžiui

Tarkime, kad Beta yra antrasis programos leidimas po pirmojo leidimo Alfa paleistas. Kai kurie defektai, nustatyti pirmajame leidime, ir kurie buvo ištaisyti vėliau išleistame. Čia taip pat nurodysime naujai pridėtų, pakeistų ir ištrintų funkcijų sąrašą nuo alfa leidimo iki beta versijos.

Šablonas

Šioje dalyje yra visi dokumentų, kurie bus naudojami gaminyje, šablonai, o visi bandymų inžinieriai projekte naudos tik šiuos šablonus, kad išlaikytų produkto nuoseklumą. Čia yra įvairių tipų šablonų, kurie naudojami viso testavimo proceso metu, pavyzdžiui:

• Bandymo atvejo šablonas
• Bandomojo atvejo peržiūros šablonas
• RTM šablonas
• Pranešimo apie klaidas šablonas
• Bandymo vykdymo ataskaita

Pažiūrėkime vieną bandymų plano dokumento pavyzdį

Puslapis 1

3 puslapis-18 puslapis

Puslapis-20

1 puslapyje pirmiausia užpildome tik Versijos, autorius, komentarai ir peržiūros laukuose, o vadovui patvirtinus detales paminėsime Patvirtinta iki ir patvirtinimo data laukai.

Dažniausiai bandymų planą patvirtina testavimo vadovas, o testavimo inžinieriai jį tik peržiūri. O kai pasirodys naujos funkcijos, mes pakeisime testavimo planą ir atliksime reikiamus pakeitimus Versija lauką, tada jis vėl bus išsiųstas tolesnei peržiūrai, atnaujinimui ir vadovui patvirtinti. Bandymo planas turi būti atnaujinamas kiekvieną kartą, kai įvyksta kokių nors pakeitimų. 20 puslapyje, Nuorodos nurodykite išsamią informaciją apie visus dokumentus, kuriuos naudosime rengdami bandymų plano dokumentą.

Pastaba:

Kas rašo testo planą?

• Bandymo laidas → 60 %
• Testo vadovas → 20 %
• Bandytojas → 20 %

Todėl, kaip matome iš viršaus, 60% produkto bandymo planą surašo testavimo vadovas.

Kas peržiūri bandymų planą?

• Bandymo laidas
• Testo vadovas
• Bandytojas inžinierius
• Klientas
• Kūrimo komanda

Testavimo inžinierius peržiūri savo modulio perspektyvos testavimo planą, o testavimo vadovas peržiūri testavimo planą, remdamasis kliento nuomone.

Kas patvirtina bandymo planą?

• Klientas
• Testo vadovas

Kas rašo bandomąjį atvejį?

• Bandymo laidas
• Bandymų inžinierius

Kas peržiūri bandomąjį atvejį?

• Bandymų inžinierius
• Bandymo laidas
• Klientas
• Vystymo komanda

Kas tvirtina bandomuosius atvejus?

• Testo vadovas
• Bandymo laidas
• Klientas

Bandymų plano gairės

• Sutraukite bandymo planą.
• Venkite persidengimo ir pertekliaus.
• Jei manote, kad jums nereikalingas jau minėtas skyrius, ištrinkite tą skyrių ir tęskite.
• Būk specifiškas. Pavyzdžiui, kai nurodote programinės įrangos sistemą kaip bandomosios aplinkos dalį, nurodykite programinės įrangos versiją, o ne tik pavadinimą.
• Venkite ilgų pastraipų.
• Jei įmanoma, naudokite sąrašus ir lenteles.
• Atnaujinkite planą, kai reikia.
• Nenaudokite pasenusio ir nenaudojamo dokumento.

Bandymų plano svarba

• Bandymų planas suteikia kryptį mūsų mąstymui. Tai tarsi taisyklių knyga, kurios reikia laikytis.
• Bandymo planas padeda nustatyti, kokių pastangų reikia bandomosios programinės įrangos kokybei patvirtinti.
• Bandymų planas padeda tiems žmonėms suprasti testo detales, kurios yra susijusios su išore, pavyzdžiui, kūrėjai, verslo vadovai, klientai ir kt.
• Svarbūs aspektai, tokie kaip bandymų grafikas, bandymų strategija, bandymo apimtis ir tt, yra dokumentuojami bandymų plane, kad valdymo komanda galėtų juos peržiūrėti ir pakartotinai panaudoti kitiems panašiems projektams.