test plan tutorial guide write software test plan document from scratch
Un ghid final pentru documentul planului de testare a software-ului:
cum se adaugă valori la o matrice
Acest tutorial vă va explica totul despre documentul planului de testare a software-ului și vă va ghida cu modalitățile de scriere / creare a unui plan detaliat de testare software de la zero, împreună cu diferențele dintre planificarea testului și executarea testului.
Ziua 3 de pregătire pentru proiectul QA în direct - După introducerea cititorilor noștri în aplicația noastră live Instruire gratuită online pentru testarea software-ului , am ajuns să știm cum să revizuiți SRS și să scrieți scenarii de testare . Și acum este momentul potrivit pentru a vă adânci în cea mai importantă parte a ciclului de viață al testării software - adică Planificarea testelor .
Lista tuturor tutorialelor din această serie:
Document de planificare a testului:
Tutorial nr. 1: Cum se scrie un document de plan de testare (Acest tutorial)
Tutorial nr. 2: Conținutul șablonului planului de testare simplu
Tutorial # 3: Exemplu de plan de testare software
Tutorial # 4: Diferența dintre planul de testare și strategia de testare
Tutorial # 5: Cum se scrie un document de strategie de testare
Sfaturi de planificare a testelor:
Tutorial nr. 6: Managementul riscului în timpul planificării testelor
Tutorial nr. 7: Ce să faceți când nu este suficient timp pentru testare
Tutorial # 8: Cum să planificați și să gestionați proiectele de testare în mod eficient
Planificarea testelor în diferite etape ale STLC:
Tutorial # 9: Planificarea testului de regresie
Tutorial # 10: UAT Test Plan
Tutorial # 11: Planul de testare a acceptării
Planificarea automatizării testelor:
Tutorial # 12: Planul de testare a automatizării
Tutorial # 13: Planificarea testului aplicației ERP
Tutorial # 14: Planificarea testului HP ALM
Tutorial # 15: Planificarea testului Mindmap
Tutorial # 16: Planul de testare JMeter și WorkBench
Ce veți învăța:
- Crearea planului de testare - cea mai importantă fază a testării
- Planificarea testului Vs Executarea testului
Crearea planului de testare - cea mai importantă fază a testării
Acest tutorial informativ vă va explica modalitățile și procedurile implicate în scrierea unui document de plan de testare.
La sfârșitul acestui tutorial, am distribuit un Document cuprinzător de 19 pagini privind Planul de testare care a fost creat special pentru proiectul live OrangeHRM, pe care îl folosim gratuit Seria de instruire QA
Ce este un plan de testare?
Test Plan este un document dinamic . Succesul unui proiect de testare depinde de un document bine scris al Planului de testare, care este actual în orice moment. Planul de testare este mai mult sau mai puțin similar un plan al evoluției activității de testare să aibă loc într-un proiect.
Mai jos sunt prezentate câteva indicații privind un plan de testare:
# 1) Planul de testare este un document care acționează ca un punct de referință și se bazează doar pe testarea respectivă în cadrul echipei QA.
#Două) Este, de asemenea, un document pe care îl împărtășim cu analistii de afaceri, managerii de proiect, echipa de dezvoltare și celelalte echipe. Acest lucru ajută la îmbunătățirea nivelului de transparență a activității echipei de asigurare a calității față de echipele externe.
# 3) Este documentat de managerul QA / conducătorul QA pe baza contribuțiilor de la membrii echipei QA.
# 4) Planificarea testului este de obicei alocată cu 1/3rddin timpul necesar întregului angajament QA. Celălalt 1/3rdeste pentru proiectarea testelor, iar restul este pentru executarea testelor.
# 5) Acest plan nu este static și este actualizat la cerere.
# 6) Cu cât planul este mai detaliat și mai cuprinzător, cu atât va fi mai reușită activitatea de testare.
Proces STLC
Acum suntem la jumătatea drumului în seria noastră de proiecte live. Prin urmare, să facem un pas înapoi de la aplicație și să aruncăm o privire la procesul de testare a ciclului de viață software (STLC).
STLC poate fi împărțit aproximativ în 3 părți:
- Planificarea testelor
- Proiectarea testului
- Executarea testului
În tutorialul nostru anterior, am aflat că, într-un proiect practic de QA, am început cu revizuirea SRS și scrierea scenariului de testare - care este de fapt al 2-lea pas în procesul STLC. Proiectarea testului implică detalii despre ce să testați și cum să testați.
De ce nu am început cu planificarea testelor?
Planificarea este într-adevăr prima și cea mai importantă activitate care se întâmplă în orice proiect de testare.
Planificarea testelor la fazele SDLC
| Faza SDLC | Activitatea de planificare a testelor |
|---|---|
| Programări => | Pregătirea scenariului de testare |
| Iniţia | În mod ideal, echipa de asigurare a calității ar trebui să se implice în timp ce scopul proiectului este colectat de la client / client sub forma unor cerințe de afaceri. Dar în lumea reală, nu este cazul. Din punct de vedere practic, implicarea echipei QA este NIL. La sfârșitul acestei etape, BRD este finalizată și se creează un Plan de bază de proiect. |
| Defini | SRS este creat din BRD. Proiectul inițial al planului de testare este creat. În acest moment, deoarece echipa QA nu a terminat cu revizuirea SRS, scopul testării nu este clar. Deci, TP în această fază va conține doar informații despre momentul în care se va întâmpla testarea, informații despre proiect și informații despre echipă (dacă le avem). |
| Proiecta | Revizuirea SRS este efectuată și scopul testării este identificat. Avem mult mai multe informații despre ceea ce trebuie testat și o estimare bună a numărului de cazuri de testare pe care le-am putea obține, etc. A fost creată o a doua versiune a planului de testare care include toate aceste informații. |
Din tabelul de mai sus, este foarte clar că un plan de testare nu este doar un document pe care îl puteți crea dintr-o dată și îl puteți utiliza de atunci înainte.
Componentele unui document de plan
| Elemente dintr-un șablon de plan de testare | Ce conțin? |
|---|---|
| Domeniu de aplicare => | Scenarii de testare / Obiectivele de testare care vor fi validate. |
| În afara domeniului de aplicare => | Claritate sporită asupra a ceea ce nu vom acoperi |
| Ipoteze => | Toate condițiile care trebuie să fie valabile pentru ca noi să putem continua cu succes |
| Documentație de testare - cazuri de testare / date de testare / mediu de configurare | |
| Executarea testului | |
| Ciclu de testare - câte cicluri | |
| Data de începere și de încheiere pentru cicluri | |
| Roluri și responsabilități => | Membrii echipei sunt enumerați |
| Cine trebuie să facă ce | |
| sunt enumerați proprietarii de module și informațiile de contact ale acestora | |
| Livrabile => | Ce documente (artefacte de testare) vor produce în ce perioade de timp? |
| Ce se poate aștepta de la fiecare document? | |
| Mediu => | Ce fel de cerințe de mediu există? |
| Cine va fi responsabil? | |
| Ce trebuie făcut în caz de probleme? | |
| Instrumente => | De exemplu, JIRA pentru urmărirea erorilor |
| Autentificare | |
| Cum se utilizează JIRA? | |
| Gestionarea defectelor => | Cui vom raporta defectele? |
| Cum vom raporta? | |
| Ce este de așteptat - oferim o captură de ecran? | |
| Riscuri și gestionarea riscurilor => | Sunt enumerate riscurile |
| Sunt analizate riscurile - probabilitatea și impactul sunt documentate | |
| Sunt elaborate planuri de reducere a riscurilor | |
| Criterii de ieșire => | Când să oprești testarea? |
Deoarece toate informațiile menționate mai sus sunt cele mai critice pentru munca de zi cu zi a unui proiect QA , este important să mențineți documentul planului actualizat din când în când.
Exemplu de document de plan de testare pentru un proiect live
Este creat un exemplu de șablon de plan de testare pentru „ ORANGEHRM VERSION 3.0 - MODULUL MEU INFO ” Proiect și atașat mai jos. Vă rog să aruncați o privire. Au fost adăugate comentarii suplimentare la documentul în roșu pentru a explica secțiunile.
Acest plan de testare este atât pentru fazele funcționale, cât și pentru fazele UAT. De asemenea, explică procesul de gestionare a testelor utilizând instrumentul HP ALM.
Descarcă eșantionul planului de testare:
Doc Format => Faceți clic aici pentru a descărca planul de testare în format Doc acesta este cel pe care l-am creat pentru proiectul OragngeHRM live și îl folosim și pentru cursul nostru de testare software.
Format PDF => Faceți clic aici pentru a descărca Planul de testare în format de fișier pdf .
Fișierele de foaie de lucru (.xls) menționate în versiunile de mai sus doc / pdf => Descărcați fișierul Fișierele XLS menționate în Planul de testare de mai sus
Șablonul de mai sus este foarte cuprinzător și unul detaliat. Prin urmare, vă rugăm să-i citiți detaliat pentru cele mai bune rezultate.
Pe măsură ce planul este creat și explicat bine, să trecem la faza următoare atât în SDLC, cât și în STLC.
Codul SDLC:
În timp ce restul proiectului își petrecea timpul pe crearea TDD, noi autoritățile de asigurare a calității am identificat domeniul de testare (scenarii de testare) și am creat primul proiect de plan de testare de încredere. Următoarea fază a SDLC este de a verifica când are loc codarea.
Dezvoltatorii sunt punctul principal de concentrare pentru întreaga echipă în această fază. Echipa QA se complace și în cea mai importantă sarcină care nu este altceva decât „Crearea cazului de testare” .
Dacă scenariile de testare erau „Ce să testăm”, atunci cazurile de testare se referă la „Cum să testăm”. Crearea cazurilor de testare este o parte predominantă a fazei de proiectare a testului STLC. Intrarea pentru activitatea de creare a cazului de testare este Scenariile de testare și documentul SRS.
Pentru testeri ca noi, Cazuri de testare sunt adevărata afacere - este chestia în care ne petrecem cea mai mare parte a timpului. Le creăm, le examinăm, le executăm, le întreținem, le automatizăm - și bine, veți obține imaginea. Indiferent cât de experimentați suntem și ce rol jucăm într-un proiect - am lucra în continuare cu cazurile de testare.
Planificarea testului Vs Executarea testului
Planificarea testelor software își rezervă un domeniu mult mai bun comparativ în Faza STLC . Livrarea de software de calitate este asigurată de echipa de testare. Și ce trebuie făcut în testare este decis de fapt în faza de planificare a testului.
Această secțiune va oferi o imagine de ansamblu completă și va include ilustrații despre importanța planificării testelor și a faza de execuție . După ce citiți acest lucru, veți înțelege importanța semnificativă a fazei de planificare în comparație cu faza de execuție cu mai multe exemple vii și studii de caz pentru ilustrații .
Planificarea testelor
Date mai jos sunt anumite lucruri esențiale care trebuie remarcate în timpul planificării:
Planificarea unui test este secțiunea esențială a ciclului de testare. Rezultatul fazei de testare va fi determinat de calitatea și sfera planificării care a fost făcută pentru testare.
Planificarea testului are loc de obicei în faza de dezvoltare, pentru a economisi timpul de execuție al testului, de comun acord de la toate părțile implicate.
la ce se poate folosi c ++
Unele fapte importante care trebuie remarcate includ:
- Planificarea trebuie să înceapă în paralel cu dezvoltarea, cu condiția ca cerințele să fie înghețate.
- Toate părțile interesate, cum ar fi proiectanții, dezvoltatorii, clienții și testerii, trebuie să fie implicați în finalizarea planului.
- Planificarea nu poate fi elaborată pentru o afacere neconfirmată sau pentru nevoi neaprobate.
- Planuri de testare similare vor fi aplicate noilor cerințe de care va avea nevoie compania.
Exemplul nr. 1
Echipa de dezvoltare lucrează la un software XYZ după ce a primit câteva cerințe de la clienți. Echipa de testare a început aproape pregătirea pentru faza de definire sau planificare a testului. Planificarea testelor trebuie să fie concepută pentru a răspunde cerințelor inițiale menționate de clienți. Acest lucru a fost făcut de echipa de testare.
Niciunul dintre ceilalți actori nu a fost implicat în această fază, iar planificarea a fost înghețată.
Echipa de dezvoltare a făcut acum unele modificări în fluxul de afaceri pentru a aborda câteva probleme în activitatea lor cu aprobarea clientului. Acum software-ul a venit la echipa de testare pentru un test. Cu planul de testare conform vechiului flux de afaceri, echipa de testare și-a început runda de testare. Acest lucru a afectat livrabilele de testare cu multe întârzieri, deoarece fluxul de afaceri modificat nu a fost împărțit echipei de testare.
Observație din exemplul 1:
Există anumite observații din exemplul de mai sus.
Sunt:
- Înțelegerea noului flux de afaceri a consumat mult timp.
- Întârzieri în livrabilele proiectului.
- Reelaborarea planificării și a celorlalte sarcini din fază.
Toate aceste observații trebuie transformate în nevoi esențiale pentru un test de livrare eficient.
Componente majore în faza de planificare
Mai jos sunt prezentate componentele majore care sunt implicate în faza de planificare.
- Strategia de testare: Aceasta este una dintre cele mai importante secțiuni care pot explica strategia care va fi utilizată în timpul testării.
- Acoperirea testului: Acest lucru este în esență necesar și va face o cartografiere a conformității nevoilor afacerii și a cazurilor de testare, astfel încât să se poată asigura dacă întregul software a fost testat sau nu.
- Cicluri și durate de testare: Acest lucru poate deveni foarte critic în funcție de rundele de dezvoltare și de timpul lor pentru a finaliza fiecare rundă.
- Criterii de promovare / nereușită: Este foarte necesar unul în care sunt definite criteriile de promovare și nereușită. De câteva ori acest lucru va fi definit și de către clienți.
- Cerințe tehnice și de afaceri: Nevoia de a avea software-ul și scopurile pe care le servesc vor fi clar definite împreună cu explicațiile de nivel scăzut.
Limitări
Există puține lucruri care pot controla de fapt faza de testare a software-ului, în special faza de planificare.
Următoarele sunt câteva domenii:
- Caracteristici care trebuie și nu trebuie testate: Acest lucru va indica în mod clar ce trebuie testat și ce nu ar trebui să fie.
- Criterii de suspendare și cerințe de reluare: Acesta este factorul de decizie privind software-ul dezvoltat și criteriile definite pentru a suspenda testarea sau a relua testarea.
- Responsabilități: Un tester va avea multiple responsabilități în asigurarea problemelor, erorilor și defectelor din software-ul testat. În plus, erorile trebuie să fie validate de dezvoltatori pentru ca acestea să fie remediate.
- Riscuri și neprevăzute: Riscurile asociate în timpul testării ar trebui menționate în mod clar, iar contingențele adecvate în acest timp trebuie definite foarte clar.
Studiu de caz nr. 1
matrici și funcții c ++
Echipa de dezvoltare din Exemplul nr. 1 intenționează să lanseze software-ul XYZ în 2 faze. Faza 1 are multe caracteristici de testat și puține care nu trebuie testate. Din nou, software-ul a fost lansat pentru a testa fără a menține echipa de testare informată despre caracteristicile care încă nu au fost dezvoltate.
Acum echipa de testare își începe execuția pe baza planurilor de testare pe care le-au elaborat deja. Ei vin cu un număr mare de bug-uri. Și după validarea din partea echipei de dezvoltare, majoritatea dintre aceștia devin invalizi.
Observații din studiul de caz de mai sus:
- Echipa de dezvoltare va lansa software-ul echipei de testare cu note de lansare și note de acoperire a cerințelor (note de lansare).
- Funcțiile care trebuie testate și care nu trebuie testate trebuie luate în considerare pe baza software-ului lansat înainte de testare.
- Criteriile de suspendare și reluare pentru testare trebuie definite corect.
- Riscurile și planurile de urgență pentru indisponibilitatea software-ului trebuie să fie ilustrate perfect.
Citește și=> Cum să gestionați riscurile în timpul fazei de planificare a testelor
Planul de executare a testului
Executarea cazurilor de testare este unul dintre pașii din faza STLC. Acest lucru va trebui efectuat în conformitate cu planurile care au fost elaborate anterior. Prin urmare, planificarea continuă să domine întotdeauna întreaga fază de testare. Mai jos este un exemplu în care echipa de testare este afectată de modificările planurilor de testare.
Exemplul nr. 2
Testarea software-ului A a fost începută pe baza planului 1 elaborat de echipă. Ulterior, din cauza nevoilor afacerii și a modificărilor, planul de testare a trebuit să sufere unele modificări. Acest lucru, la rândul său, a forțat modificarea cazurilor de testare sau a execuției.
Observații:
- Planul de testare va determina execuția cazului de testare.
- Partea de execuție variază conform planului.
- Atâta timp cât planul și cerințele sunt valabile, cazurile de testare sunt valabile și ele.
Modalități de depășire a problemelor în timpul executării
Testerii vor întâlni mai des diferite scenarii în timp ce efectuează execuția testului. Acesta este momentul în care testerii vor trebui să înțeleagă și să cunoască modalitățile de a rezolva problema sau cel puțin să găsească o soluție pentru problema respectivă.
Exemplul nr. 3
În timpul executării cazului de testare a software-ului B, echipa de testare întâmpină mai multe probleme. Puțini dintre ei sunt dopuri de spectacol. Ei au nevoie de dezvoltatori pentru a-i ajuta să depășească problema. Acest lucru sa întâmplat de mai multe ori și rezultatul este o întârziere în testarea livrabilelor.
Observații:
- Există o dependență pentru depășirea problemelor și problemelor de mediu.
- Pentru testeri este necesară o înțelegere adecvată a mediului.
- Problemele frecvente și cunoscute trebuie documentate pentru a le depăși în viitor.
Controlul și gestionarea versiunilor
Controlul versiunilor și gestionarea planurilor de testare și a cazurilor de testare sunt cu adevărat importante pentru a prezenta rezultatele la timp. Acest lucru este mai semnificativ și se face adesea cu ajutorul unui instrument de control al versiunilor.
Un instrument de control al versiunilor nu numai că îi ajută să controleze planurile de testare, ci ajută și la gestionarea defectelor. Atunci când există proiecte de testare cu cicluri și versiuni multiple, aceste instrumente pot ajuta într-adevăr la reducerea valorilor pentru susținerea livrabilelor de testare.
De asemenea, citiți=> Managementul riscului în faza de execuție a testului
Diferența dintre planificarea testului și executarea testului
Următoarele sunt câteva domenii importante care vor evidenția modul în care planificarea va diferi de faza de executare a testului.
| Zona de comparație | Planificarea testelor | Executarea testului |
|---|---|---|
| Poziționare livrabilă | Planul de testare va fi considerat un produs important pentru activitatea de testare. Acest lucru se va face ca primul pas în procesul de testare. | Acesta va veni ca ultimul membru de bancă în faza de testare. După executare, starea defectelor / erorilor, împreună cu starea de execuție a cazului de testare, vor fi partajate ca unul dintre rezultatele testării |
| Persoană responsabilă | Managerul de testare va pregăti planul de testare și va împărtăși tuturor părților interesate pentru examinare. | Acest lucru se va face în mod normal de către tester, ținând cont de faptul că cazurile de testare pregătite au fost aprobate și semnate. |
| Concentrare principala | Domeniile de concentrare ale planului de testare sunt modul în care trebuie efectuate testele, ce trebuie luat în considerare și ce nu, mediul care poate fi utilizat, programele de testare etc. | Execuția testului se concentrează în principal pe execuția cazurilor de test furnizate pentru a fi testate pe software. |
| Mod recurent sau iterativ | Aceasta este o singură activitate. Acestea fiind spuse că poate sau nu să necesite modificări pentru versiunile viitoare ale software-ului. | Există 3 părți în acest domeniu când vorbim despre iterație. 1. Testarea funcțională. 2. Testarea regresiei. 3. Re-testare. |
| Intrări | Intrările pentru crearea unui plan de testare sunt într-adevăr necesare și trebuie furnizate de analiști de afaceri, arhitect, clienți etc., | Documentul de caz de testare este principalul element de intrare. |
| Perioada când poate fi început | Trebuie început împreună cu ciclul de dezvoltare pentru un rezultat eficient și pentru a economisi timp. Dar există puține modele precum modelul de cădere a apei în care în faza de testare va începe doar după ce faza de dezvoltare a fost finalizată. | Executarea trebuie să înceapă strict după realizarea dezvoltării software-ului. |
| Perioada de închidere | Planul de testare nu va avea o astfel de perioadă de închidere. În general, va fi furnizată o semnare de la toate părțile interesate pentru software. | Execuția pentru o anumită versiune sau ciclu va fi considerată a fi închisă atunci când toate cazurile de testare au fost executate împotriva software-ului. |
| Utilizarea instrumentelor | Nu vor fi multe instrumente utilizate, deoarece activitatea de planificare va fi mai multă discuție și documentare. Pentru a urmări orice modificare a planului, managerii de testare vor utiliza în mod normal orice instrument de control al versiunii, cum ar fi VSS sau altceva. | Va depinde de modul de execuție. În cazul manualului, nu va fi utilizat niciun instrument pentru execuție. Dar pentru înregistrarea defectelor și gestionarea, vor fi utilizate unele instrumente. În cazul testării automatizării, execuția se va face cu ajutorul unor instrumente precum QTP, SELENIUM etc. |
| Impacturi asupra rezultatelor | Acest lucru va avea impact asupra tuturor fazelor de testare într-un mod mai larg | Acest lucru va avea impact asupra ciclului sau eliberării următoare care urmează să fie testată. |
Ilustrațiile de mai sus s-ar fi putut explica într-o formă mai bună asupra importanței activităților de planificare a testelor decât cea a execuției testului. Prin unele mijloace, faza de execuție este un fel de subset al planului de testare.
Pe baza strategiei de testare, abordare și a celorlalte lucruri, planul de testare are o probabilitate mai mare de a fi modificat pentru a da loc schimbărilor. Este un lucru clar că execuția testului depinde de cazurile de testare. Cazurile de testare se bazează pe planuri. Prin urmare, modificările planurilor vor asigura modificări în cazurile de testare.
Dar invers, schimbările în cazurile de test nu trebuie să caute în mod obligatoriu modificări. Acesta este unul dintre principalele motive pentru care planificarea se menține în comparație cu faza de execuție a testului.
Următorul nostru tutorial vă va explica mai multe despre cum să creați cazuri de testare? Ce sunt ei? Și cum le putem face să funcționeze pentru noi împreună cu diferitele alte aspecte legate de cazurile de testare.
NEXT Tutorial=> QA Training Day-4: Scrierea cazurilor de testare din documentul SRS
Sunteți un expert în redactarea unui document de plan de testare? Atunci acesta este locul potrivit pentru a vă împărtăși sfaturile valoroase de îmbunătățire pentru testerii viitori. Simțiți-vă liber să vă exprimați gândurile cu noi în secțiunea de comentarii de mai jos !!
Lectură recomandată
- Exemplu de șablon de plan de testare software cu format și conținut
- Ghid de documentare pentru testarea software-ului (de ce este important)
- Resurse și descărcări de testare software QA
- Exemplu de document de plan de testare (exemplu de plan de testare cu detalii despre fiecare câmp)
- Executarea testului în testarea software-ului: proces și plan exact cu exemplul
- Cum se scrie un document de strategie de testare (cu un șablon de strategie de testare)
- Scrierea cazurilor de testare din documentul SRS (DESCĂRCARE Exemple de testare a proiectelor live)
- Programul de testare a software-ului - Plan de instruire detaliat al cursului online