TESTA PLĀNS: Kas ir, kā izveidot (ar piemēru)

Testa plāns

Testa plāns ir detalizēts dokuments, kas raksturo testa stratēģijas, mērķi, grafiks, novērtēšana, rezultāti, un resursus, kas nepieciešami, lai veiktu pārbaudes par programmatūras produktu. Testa plāns palīdz mums noteikt nepieciešamos pasākumus, lai pārbaudītu pārbaudāmās lietojumprogrammas kvalitāti. Pārbaudes plāns kalpo kā programmatūras testēšanas darbību kā definēta procesa plāns, kuru testa vadītājs rūpīgi pārrauga un kontrolē.

Saskaņā ar ISTQB definīciju: “Testa plāns ir dokuments, kurā aprakstīta paredzēto testa darbību joma, pieeja, resursi un grafiks.”

Sāksim ar šādu testa plāna piemēru / scenāriju: Sapulcē vēlaties apspriest testa plānu ar komandas locekļiem, bet viņi tos neinteresē.

Šādā gadījumā ko jūs darīsit? Atlasiet savu atbildi kā attēlā

A) Es esmu vadītājs daru visu, kā es teicu
B) Labi, paskaidrošu, kāpēc mums ir vajadzīgs
nepareizs
testa plāns Kā testa vadītājam jums jāpaskaidro viņiem testa plāna nozīme, nevis jāpiespiež komandu darīt to, ko vēlaties. Pareizi
Kā testa vadītājam jums jāpaskaidro viņiem testa plāna nozīme, nevis jāpiespiež komandu darīt to, ko vēlaties.

Kāda ir testa plāna nozīme?

Pārbaudes plāna dokumenta izgatavošanai ir vairākas priekšrocības

• Palīdziet cilvēkiem, kas nav testa komanda, piemēram, izstrādātājiem, biznesa vadītājiem, klientiem izprast testēšanas detaļas.
• Pārbaudes plāns vada mūsu domāšanu. Tā ir kā noteikumu grāmata, kas jāievēro.
• Svarīgi aspekti, piemēram, testa novērtēšana, testa apjoms, testēšanas stratēģija, ir dokumentēti testa plānā, tāpēc vadības komanda var tos pārskatīt un atkārtoti izmantot citiem projektiem.

Kā uzrakstīt testa plānu

Jūs jau zināt, ka testa plāna sastādīšana ir vissvarīgākais testa pārvaldības procesa uzdevums. Lai izveidotu testa plānu atbilstoši IEEE 829, veiciet tālāk norādītās septiņas darbības

1. Analizējiet produktu
2. Izstrādājiet testa stratēģiju
3. Definējiet testa mērķus
4. Definējiet testa kritērijus
5. Resursu plānošana
6. Plāna testa vide
7. Grafiks un aprēķins
8. Nosakiet testējamos rezultātus

1. solis. Analizējiet produktu

Kā jūs varat pārbaudīt produktu bez jebkādas informācijas par to? Atbilde ir neiespējama. Pirms produkta testēšanas jums tas ir rūpīgi jāapgūst .

Pārbaudāmais produkts ir Guru99 banku vietne. Jums vajadzētu izpētīt klientus un galalietotājus, lai uzzinātu viņu vajadzības un cerības no lietojumprogrammas

• Kas izmantos vietni?
• Kāpēc to lieto?
• Kā tas darbosies?
• Kas ir programmatūra / aparatūra, ko produkts izmanto?

Lai analizētu vietni, varat izmantot šādu pieeju

Tagad izmantosim iepriekš minētās zināšanas reālam produktam: analizējiet banku vietni http://demo.guru99.com/V4.

Jums vajadzētu apskatīt šo vietni un pārskatīt arī produkta dokumentāciju. Produkta dokumentācijas pārskatīšana palīdz izprast visas vietnes funkcijas, kā arī to, kā to izmantot. Ja jums nav skaidrības par kādiem priekšmetiem, varat intervēt klientu, izstrādātāju, dizaineru, lai iegūtu vairāk informācijas.

2. solis) Izstrādājiet testa stratēģiju

Testa stratēģija ir kritisks solis , lai izveidotu testēšanas plānu programmatūras testēšanā. Testa stratēģijas dokuments ir augsta līmeņa dokuments, kuru parasti izstrādā Test Manager. Šis dokuments nosaka:

• Projekta testēšanas mērķi un līdzekļi to sasniegšanai
• Nosaka testēšanas piepūli un izmaksas

Atgriežoties pie sava projekta, jums jāizstrādā testa stratēģija, lai pārbaudītu šo bankas vietni. Jums vajadzētu veikt tālāk norādītās darbības

2.1. Solis) Definējiet testēšanas apjomu

Pirms jebkuras testa darbības sākuma būtu jāzina testa apjoms. Jums par to ir nopietni jādomā.

• Pārbaudāmās sistēmas sastāvdaļas (aparatūra, programmatūra, starpprogrammatūra utt.) Ir definētas kā " darbības jomā "
• Sistēmas komponenti, kas netiks pārbaudīti, arī ir skaidri jādefinē kā " ārpus darbības jomas ".

Pārbaudes projekta darbības jomas noteikšana ir ļoti svarīga visām ieinteresētajām personām. Jums palīdz precīza darbības joma

• Dodiet visiem pārliecību un precīzu informāciju par jūsu veikto testēšanu
• Visiem projekta dalībniekiem būs skaidra izpratne par to, kas ir pārbaudīts un kas nav

Kā jūs nosakāt sava projekta darbības jomu?

Lai noteiktu darbības jomu, jums ir:

• Precīza klienta prasība
• Projekta budžets
• Produkta specifikācija
• Jūsu testa komandas prasmes un talants

Tagad skaidri jādefinē testēšanas darbības joma un darbības joma.

• Kā programmatūras prasību specifikācijas, projekts Guru99 Bank koncentrējas tikai uz visu vietņu Guru99 Bank funkciju un ārējās saskarnes testēšanu ( darbības jomas pārbaudē)
• Pašlaik netiks testētas tādas nederīgas pārbaudes kā stresa , veiktspēja vai loģiskā datu bāze . ( ārpus darbības jomas)

Problēmas scenārijs

Klients vēlas, lai jūs pārbaudītu viņa API. Bet projekta budžets to neļauj darīt. Ko tādā gadījumā darīsit?

Nu, šādā gadījumā jums jāpārliecina klients, ka Api testēšana ir papildu darbs un patērēs ievērojamus resursus. Sniedziet viņam datus, kas pamato jūsu faktus. Pastāstiet viņam, vai Api testēšana ir iekļauta darbības jomā, budžets palielināsies par XYZ summu.

Klients piekrīt, un attiecīgi ir arī jaunās darbības jomas, kas ir ārpus darbības jomas

• Darbības joma: Funkcionālā testēšana, Api testēšana
• Ārpus sfēras esošie vienumi: datu bāzes pārbaude, aparatūra un citas ārējās saskarnes

2.2. Solis) Nosakiet testa veidu

Testēšana veids ir standarta testa procedūru, kas dod gaidīto testa rezultātu.

Katrs testēšanas veids ir formulēts, lai identificētu konkrētu produktu kļūdu veidu. Bet visu testēšanas veidu mērķis ir sasniegt vienu kopīgu mērķi “ Visu defektu agrīna atklāšana pirms produkta nodošanas klientam”

Par ko parasti izmanto testēšanas veidi tiek raksturoti kā attēlā

Programmatūras produkta testēšanai ir daudz testēšanas veidu . Jūsu komandai nevar būt pietiekami daudz pūļu, lai veiktu visu veidu testēšanu. Kā testa pārvaldniekam jums jāiestata testēšanas veidu prioritāte

• Kuriem testēšanas veidiem jābūt vērstiem uz tīmekļa lietojumprogrammu testēšanu?
• Kurus testēšanas veidus vajadzētu ignorēt, lai ietaupītu izmaksas?

Tagad praktizēsimies ar jūsu projektu. Produkts, kuru vēlaties pārbaudīt, ir banku vietne.
Kuriem testēšanas veidiem jums vajadzētu koncentrēties šajā gadījumā?
Atlasiet Visas lietojamās A) Vienības pārbaude B) API testēšana C) Integrācijas pārbaude D) Sistēmas testēšana E) Instalējiet / atinstalējiet testēšanu F) Agile testēšana Mēs Guru99 projektam atlasām tikai B) API testēšanu C) Integrācijas testēšanu D) Sistēmas testēšanu

2.3. Solis) Dokumentējiet risku un problēmas

Risks ir Future nenoteikts notikums ar varbūtību rašanās un potenciālu , lai zaudējumus. Kad risks faktiski notiek, tas kļūst par “ jautājumu”.

Rakstā Riska analīze un risinājums jūs jau esat detalizēti uzzinājis par riska analīzi un identificējis iespējamos riskus projektā.

QA testa plānā jūs dokumentēsit šos riskus

Risks	Mīkstināšana
Komandas dalībniekam trūkst vajadzīgo prasmju, lai pārbaudītu vietni.	Plānojiet apmācības kursu, lai apgūtu savus dalībniekus
Projekta grafiks ir pārāk saspringts; ir grūti pabeigt šo projektu laikā	Katrai testa darbībai iestatiet testa prioritāti .
Testu vadītājam ir sliktas vadības prasmes	Plānojiet vadītāja apmācību vadītājam
Sadarbības trūkums negatīvi ietekmē jūsu darbinieku produktivitāti	Mudiniet katru komandas locekli veikt uzdevumu un iedvesmojiet viņus lielākiem centieniem.
Nepareiza budžeta tāme un izmaksu pārsniegšana	Pirms darba uzsākšanas nosakiet darbības jomu , pievērsiet lielu uzmanību projekta plānošanai un pastāvīgi izsekojiet un novērtējiet progresu

2.4. Solis) Izveidojiet testa loģistiku

Testa loģistikā testa vadītājam jāatbild uz šādiem jautājumiem:

• Kurš pārbaudīs?
• Kad notiks pārbaude?

Kurš pārbaudīs?

Jūs, iespējams, nezināt precīzus testētāja vārdus, kas testēs, bet testētāja veidu var noteikt.

Lai izvēlētos pareizo dalībnieku norādītajam uzdevumam, jums jāapsver, vai viņa prasme ir kvalificēta uzdevumam, vai nav, kā arī jānovērtē projekta budžets. Nepareiza dalībnieka izvēle uzdevumam var izraisīt projekta izgāšanos vai aizkavēšanos .

Persona, kurai ir šādas prasmes, ir vispiemērotākā programmatūras testēšanai:

• Spēja izprast klientu viedokli
• Spēcīga vēlme pēc kvalitātes
• Uzmanība detaļām
• Laba sadarbība

Jūsu projektā dalībnieks, kurš uzņemsies atbildību par testa izpildi, ir testētājs. Pamatojoties uz projekta budžetu, kā testētāju varat izvēlēties dalībnieku avotā vai ārpakalpojumā.

Kad notiks pārbaude?

Pārbaudes darbības jāsaskaņo ar saistītajām izstrādes darbībām.

Jūs sāksiet pārbaudīt, kad jums būs visi nepieciešamie priekšmeti, kas parādīti nākamajā attēlā

3. solis. Definējiet testa mērķi

Testa mērķis ir testa izpildes vispārējais mērķis un sasniegums. Testēšanas mērķis ir atrast pēc iespējas vairāk programmatūras defektu; pirms izlaišanas pārliecinieties, ka pārbaudāmajā programmatūrā nav kļūdu .

Lai definētu testa mērķus, jums jāveic 2 šādas darbības

1. Uzskaitiet visas programmatūras funkcijas (funkcionalitāte, veiktspēja, GUI ...), kuras, iespējams, būs jāpārbauda.
2. Definējiet testa mērķi vai mērķi , pamatojoties uz iepriekš minētajām funkcijām

Izmantosim šīs darbības, lai atrastu sava Guru99 Bank testēšanas projekta testa mērķi

Lai atrastu vietnes funkcijas, kuras, iespējams, būs jāpārbauda, varat izvēlēties metodi “ Augšup-lejup” . Šajā metodē jūs sadalāt testējamo lietojumprogrammu pēc komponentiem un apakškomponentiem .

Iepriekšējā tēmā jūs jau esat analizējis prasību specifikācijas un apmeklējis vietni, tāpēc varat izveidot domāšanas karti, lai atrastu vietnes funkcijas šādi

Šajā attēlā ir parādītas visas Guru99 vietnes iespējas.

Pamatojoties uz iepriekš minētajām funkcijām, projekta Guru99 testa mērķi varat definēt šādi

• Pārbaudiet, vai vietnes Guru99 funkcionalitāte (konts, depozīts ...) darbojas kā paredzēts, bez kļūdām un kļūdām reālā biznesa vidē
• Pārbaudiet, vai vietnes ārējā saskarne, piemēram, lietotāja saskarne, darbojas, kā paredzēts, un atbilst klienta vajadzībām
• Pārbaudiet vietnes lietojamību . Vai šīs funkcijas ir ērtas lietotājam vai nē?

4. solis. Definējiet testa kritērijus

Pārbaudes kritēriji ir standarts vai noteikums, uz kuru var balstīt testa procedūru vai spriedumu. Ir divu veidu pārbaudes kritēriji

Apturēšanas kritēriji

Norādiet testa kritiskos apturēšanas kritērijus. Ja testēšanas laikā tiek ievēroti apturēšanas kritēriji, aktīvais testa cikls tiks apturēts līdz kritēriju atrisināšanai .

Pārbaudes plāna piemērs: ja jūsu komandas locekļi ziņo, ka 40% testu gadījumu nav izdevies, jums jāpārtrauc testēšana, līdz izstrādes komanda novērš visus neizdevušos gadījumus.

Izejas kritēriji

Tajā ir noteikti kritēriji, kas apzīmē testa posma sekmīgu pabeigšanu. Izstāšanās kritēriji ir mērķtiecīgi testa rezultāti, un tie ir nepieciešami, pirms pāriet uz nākamo attīstības fāzi. Piemērs: 95% no visiem kritiskajiem testa gadījumiem jāiztur.

Dažas izejas kritēriju noteikšanas metodes ir norādītas mērķētas izpildes ātrums un izturēšanas ātrums .

• Izpildes ātrums ir attiecība starp izpildīto testu skaitu / testa specifikācijas kopējo testu skaitu . Piemēram, testa specifikācijā kopā ir 120 TC, bet testeris izpildīja tikai 100 TC, tāpēc izpildes ātrums ir 100/120 = 0,83 (83%)
• Pass likme ir attiecība starp skaitu nokārtojuši testpiemēru / testpiemēru izpildīts . Piemēram, ja izpildīti vairāk nekā 100 TC, ir izturējuši 80 TC, tātad caurlaides ātrums ir 80/100 = 0,8 (80%)

Šos datus var iegūt testa metrikas dokumentos.

• Izpildes ātrumam obligāti jābūt 100%, ja vien nav norādīts skaidrs iemesls.
• Ieejas ātrums ir atkarīgs no projekta apjoma, bet mērķis ir sasniegt augstu caurlaidības līmeni .

Testa plāna piemērs: Tava komanda jau ir izpildījusi testa izpildes. Viņi ziņo jums par testa rezultātu un vēlas, lai jūs apstiprinātu izejas kritērijus.

Iepriekš minētajā gadījumā izpildes ātrums ir obligāts, un tas ir 100%, bet testa grupa ir izpildījusi tikai 90% testa gadījumu. Tas nozīmē, ka izpildes ātrums nav apmierināts, tāpēc NEVIS apstipriniet izejas kritērijus

5. solis) Resursu plānošana

Resursu plāns ir detalizēts visu veidu resursu kopsavilkums , kas nepieciešams projekta uzdevuma izpildei. Resursi varētu būt cilvēki, aprīkojums un materiāli, kas nepieciešami projekta pabeigšanai

Resurss plānošana ir svarīgs faktors testa plānošanā, jo palīdz nosakot to skaitu, resursu (darbinieku, iekārtu, ...), ko izmanto projektam. Tāpēc Testa pārvaldnieks var izveidot pareizu projekta grafiku un aprēķinu.

Šajā sadaļā ir norādīti ieteicamie resursi jūsu projektam.

Cilvēkresursi

Šī tabula atspoguļo dažādus dalībniekus jūsu projekta komandā

Nē.	Biedrs	Uzdevumi
1.	Testa vadītājs	Pārvaldiet visu projektu Definējiet projekta virzienus Iegūstiet atbilstošus resursus
2.	Testeris	Atbilstošu pārbaudes metožu / rīku / automatizācijas arhitektūras identificēšana un aprakstīšana Pārbaudiet un novērtējiet testa pieeju Izpildīt testus, Log rezultātus, ziņojums defektu. Testeris varētu būt gan no avota, gan no ārpuses, pamatojoties uz projekta budžetu Par uzdevumu, kas nepieciešami zema iemaņas, es ieteiktu jums izvēlēties ārpakalpojumu locekļus saglabātu projekta izmaksas.
3.	Izstrādātājs testā	Ieviesiet testa gadījumus, testa programmu, testu komplektu utt.
4.	Pārbaudes administrators	Veido un nodrošina testa vides un aktīvu pārvaldību un uzturēšanu Atbalstiet testētāju, lai testa izpildei izmantotu testa vidi
5.	SQA biedri	Uzņemieties atbildību par kvalitātes nodrošināšanu Pārbaudiet, vai pārbaudes process atbilst noteiktajām prasībām

Sistēmas resurss

Lai pārbaudītu tīmekļa lietojumprogrammu, resursi jāplāno šādi:

Nē.	Resursi	Apraksti
1.	Serveris	Instalējiet pārbaudāmo tīmekļa lietojumprogrammu Tas ietver atsevišķu tīmekļa serveri, datu bāzes serveri un lietojumprogrammu serveri, ja nepieciešams
2.	Pārbaudes rīks	Testēšanas rīks ir automatizēt testēšanu, simulēt lietotāja darbību, ģenerēt testa rezultātus Šajā projektā varat izmantot daudz testa rīku, piemēram, Selēns, QTP utt.
3.	Tīkls	Jums ir nepieciešams tīkls, kas ietver LAN un internetu, lai imitētu reālo biznesa un lietotāja vidi
4.	Dators	Dators, kuru lietotāji bieži izmanto, lai izveidotu savienojumu ar tīmekļa serveri

6. solis. Plānojiet testa vidi

Kas ir testa vide

Testēšanas vide ir programmatūras un aparatūras iestatīšana, kurā testēšanas grupa veiks testu gadījumus. Pārbaudes vide sastāv no reālas biznesa un lietotāju vides, kā arī no fiziskās vides, piemēram, servera, priekšējās darbības vides.

Kā iestatīt testa vidi

Atgriežoties pie sava projekta, kā jūs izveidojat testa vidi šai banku vietnei?

Lai pabeigtu šo uzdevumu, jums ir nepieciešama cieša sadarbība starp testa komandu un attīstības komandu

Jums vajadzētu uzdot izstrādātājam dažus jautājumus, lai skaidri saprastu pārbaudāmo tīmekļa lietojumprogrammu . Šeit ir daži ieteiktie jautājumi. Protams, jūs varat uzdot citus jautājumus, ja jums tas nepieciešams.

• Kāds ir maksimālais lietotāja savienojums, ko šī vietne var vienlaikus apstrādāt?
• Kādas ir aparatūras / programmatūras prasības, lai instalētu šo vietni?
• Vai lietotāja datoram ir nepieciešams kāds īpašs iestatījums, lai pārlūkotu vietni?

Nākamais attēls apraksta banku vietnes www.demo.guru99.com/V4 testa vidi

7. solis) Grafiks un aprēķins

Rakstā Testa novērtējums jūs jau izmantojāt dažas metodes, lai novērtētu centienus pabeigt projektu. Tagad jums jāiekļauj šis novērtējums, kā arī testa plānošanas grafiks

Testa novērtēšanas fāzē pieņemsim, ka jūs sadalāt visu projektu mazos uzdevumos un pievienojiet katra uzdevuma novērtējumu, kā norādīts zemāk

Uzdevums	Dalībnieki	Novērtējiet piepūli
Izveidojiet testa specifikāciju	Testa dizainers	170 cilvēka stunda
Veiciet testa izpildi	Testētājs, testa administrators	80 cilvēka stundas
Testa ziņojums	Testeris	10 cilvēka stunda
Pārbaudes piegāde		20 cilvēka stundas
Kopā		280 cilvēka stunda

Tad jūs izveidojat šo uzdevumu izpildes grafiku .

Grafika sastādīšana ir kopīgs termins projekta vadībā. Izveidojot stabilu grafiku Testa plānošanā, Testa pārvaldnieks to var izmantot kā instrumentu projekta progresa uzraudzībai, izmaksu pārsniegšanas kontrolei.

Lai izveidotu projekta grafiku, testa pārvaldniekam ir nepieciešami vairāki ievades veidi, kā norādīts zemāk:

• Darbinieks un projekta termiņš : darba dienas, projekta termiņš, resursu pieejamība ir faktori, kas ietekmēja grafiku
• Projekta novērtējums : pamatojoties uz novērtējumu, testa vadītājs zina, cik ilgs laiks nepieciešams projekta pabeigšanai. Lai viņš varētu sastādīt atbilstošu projekta grafiku
• Projekta risks : Riska izpratne palīdz Test Manager pievienot pietiekami daudz papildu laika projekta grafikam, lai tiktu galā ar riskiem

Trenēsimies ar piemēru:

Pieņemsim, ka boss vēlas pabeigt projektu Guru99 vienā mēnesī, jūs jau esat novērtējis katra uzdevuma piepūli testa novērtējumā. Jūs varat izveidot grafiku, kā norādīts zemāk

8. solis. Pārbaudiet piegādājamos materiālus

Testa rezultāti ir visu dokumentu, rīku un citu sastāvdaļu saraksts, kas jāizstrādā un jāuztur, lai atbalstītu testēšanas darbu.

Katrā programmatūras izstrādes dzīves cikla posmā ir dažādi testējamie rezultāti.

Testa rezultāti ir pieejami pirms testa posma.

• Testa plānu dokuments.
• Pārbaudes gadījumu dokumenti
• Testa projekta specifikācijas.

Testa dokumenti ir sniegta laikā testēšanas

• Pārbaudes skripti
• Simulatori.
• Testa dati
• Testa izsekojamības matrica
• Kļūdu žurnāli un izpildes žurnāli.

Testa rezultāti tiek sniegti pēc testēšanas ciklu beigām.

• Testa rezultāti / ziņojumi
• Defektu ziņojums
• Uzstādīšanas / pārbaudes procedūru vadlīnijas
• Izlaiduma piezīmes

Resursi

Lejupielādējiet testa plāna veidnes paraugu

Lejupielādējiet vietnes Guru99 bankas sistēmas testa paraugu