PLANUL DE TESTARE - TESTARE SOFTWARE

Un plan de testare este un document detaliat care descrie zonele și activitățile de testare a software-ului. Acesta prezintă strategia de testare, obiectivele, programul de testare, resursele necesare (resurse umane, software și hardware), estimarea testului și livrabilele de testare.

Planul de testare este baza de testare a fiecărui software. Este cea mai importantă activitate care asigură disponibilitatea tuturor listelor de activități planificate într-o secvență adecvată.

Planul de testare este un șablon pentru desfășurarea activităților de testare a software-ului ca proces definit care este complet monitorizat și controlat de managerul de testare. Planul de testare este pregătit de Tester Lead (60%), Test Manager (20%) și de către inginerul de testare (20%).

Tipuri de plan de testare

Există trei tipuri de plan de testare

Master Test Plan
Planul de testare de fază
Planuri de testare specifice tipului de testare

Master Test Plan

Master Test Plan este un tip de plan de testare care are mai multe niveluri de testare. Include o strategie completă de testare.

Planul de testare de fază

Un plan de testare de fază este un tip de plan de testare care se adresează oricărei faze a strategiei de testare. De exemplu, o listă de instrumente, o listă de cazuri de testare etc.

Planuri specifice de testare

Plan de testare specific conceput pentru tipurile majore de testare, cum ar fi testarea de securitate, testarea de încărcare, testarea performanței etc. Cu alte cuvinte, un plan de testare specific conceput pentru testarea nefuncțională.

Cum se scrie un plan de testare

Realizarea unui plan de testare este cea mai importantă sarcină a procesului de management al testelor. Conform IEEE 829, urmați următorii șapte pași pentru a pregăti un plan de testare.

Mai întâi, analizați structura și arhitectura produsului.
Acum proiectați strategia de testare.
Definiți toate obiectivele testului.
Definiți zona de testare.
Definiți toate resursele utilizabile.
Programați toate activitățile într-un mod adecvat.
Determinați toate livrabilele de testare.

Componentele sau atributele planului de testare

Planul de testare constă din diverse părți, care ne ajută să deducem întreaga activitate de testare.

Obiective: Constă în informații despre module, caracteristici, date de testare etc., care indică scopul aplicației înseamnă comportamentul aplicației, scopul etc.

Domeniu de aplicare: Conține informații care trebuie testate cu respectiva aplicație. Domeniul de aplicare poate fi împărțit în două părți:

În vedere
În afara domeniului de aplicare

În vedere: Acestea sunt modulele care trebuie testate riguros (detaliat).

În afara domeniului de aplicare: Acestea sunt modulele, care nu trebuie testate riguros.

De exemplu , Să presupunem că avem de testat o aplicație Gmail, unde caracteristici de testat ca Compune e-mail, Articole trimise, Mesaje primite, Ciorne si caracteristici care nu pot fi testate ca Ajutor , și așa mai departe, ceea ce înseamnă că în faza de planificare, vom decide ce funcționalitate trebuie verificată sau nu în funcție de limita de timp dată în produs.

Acum cum decidem ce caracteristici nu trebuie testate?

Avem următoarele aspecte în care putem decide ce caracteristică nu trebuie testată:

După cum vedem mai sus Ajutor caracteristicile nu vor fi testate, deoarece este scris și dezvoltat de scriitorul tehnic și revizuit de un alt scriitor profesionist.
Să presupunem că avem o aplicație care are P, Q, R și S caracteristici, care trebuie dezvoltate pe baza cerințelor. Dar aici, caracteristica S a fost deja proiectată și utilizată de o altă companie. Deci, echipa de dezvoltare va achiziționa S de la acea companie și se va integra cu funcții suplimentare, cum ar fi P, Q și R.

Acum, nu vom efectua teste funcționale pe caracteristica S, deoarece a fost deja folosită în timp real. Dar vom face testarea de integrare și testarea sistemului între caracteristicile P, Q, R și S, deoarece noile caracteristici ar putea să nu funcționeze corect cu caracteristica S, așa cum putem vedea în imaginea de mai jos:

Să presupunem că în prima lansare a produsului, elementele care au fost dezvoltate, cum ar fi P, Q, R, S, T, U, V, W…..X, Y, Z . Acum clientul va oferi cerințele pentru noile caracteristici care îmbunătățesc produsul în a doua ediție și noile caracteristici sunt A1, B2, C3, D4 și E5.

După aceea, vom scrie domeniul de aplicare în timpul planului de testare ca

profunzimea algoritmului prima căutare

Domeniul de aplicare

Caracteristici de testat

A1, B2, C3, D4, E5 (funcții noi)

P, Q, R, S, T

Caracteristici care nu trebuie testate

W X Y Z

Prin urmare, vom verifica mai întâi noile caracteristici și apoi vom continua cu vechile caracteristici, deoarece acestea ar putea fi afectate după adăugarea noilor caracteristici, ceea ce înseamnă că va afecta și zonele de impact, așa că vom face o rundă de testare regresivă pentru P, Q , R…, T caracteristici.

Metodologia de testare:

Conține informații despre efectuarea unui alt tip de testare, cum ar fi testarea funcțională, testarea de integrare și testarea sistemului etc. în aplicație. În aceasta, vom decide ce tip de testare; vom efectua diverse funcții în funcție de cerințele aplicației. Și aici, ar trebui, de asemenea, să definim că ce fel de testare vom folosi în metodologiile de testare, astfel încât toată lumea, cum ar fi conducerea, echipa de dezvoltare și echipa de testare să poată înțelege cu ușurință, deoarece termenii de testare nu sunt standard.

De exemplu, pentru aplicații autonome, cum ar fi Adobe Photoshop , vom efectua următoarele tipuri de testare:

Testare de fum → Testare funcțională → Testare de integrare → Testare de sistem → Testare adhoc → Testare de compatibilitate → Testare de regresie → Testare de globalizare → Testare de accesibilitate → Testare de utilizare → Testare de fiabilitate → Testare de recuperare → Testare de instalare sau dezinstalare

Și să presupunem că trebuie să testăm https://www.jeevansathi.com/ aplicație, așa că vom efectua următoarele tipuri de testare:

Testarea fumului	Testare funcțională	Testarea integrării
Testarea sistemului	Testare ad-hoc	Testare de compatibilitate
Testarea regresiei	Testarea globalizării	Testare de accesibilitate
Testare de utilizare	Test de performanta

Abordare

Acest atribut este utilizat pentru a descrie fluxul aplicației în timpul efectuării testării și pentru referință viitoare.

Putem înțelege fluxul aplicației cu ajutorul aspectelor de mai jos:

Prin scrierea scenariilor de nivel înalt Prin scrierea graficului de flux

Prin scrierea scenariilor de nivel înalt

De exemplu , să presupunem că testăm Gmail aplicatie:

Conectați-vă la Gmail - trimite un e-mail și verifică dacă este în pagina Articole trimise
Conectați la …….
……
......

Scriem acest lucru pentru a descrie abordările care trebuie luate pentru testarea produsului și numai pentru caracteristicile critice în care vom scrie scenariile de nivel înalt. Aici, nu ne vom concentra pe acoperirea tuturor scenariilor, deoarece poate fi decis de către inginerul de testare care sunt caracteristicile care trebuie testate sau nu.

Prin scrierea graficului de flux

Graficul de flux este scris deoarece scrierea scenariilor de nivel înalt este un proces care durează biți, așa cum putem vedea în imaginea de mai jos:

Creăm grafice de flux pentru a obține următoarele beneficii, cum ar fi:

Acoperirea este ușoară
Fuzionarea este ușoară

Abordarea poate fi clasificată în două părți, care sunt după cum urmează:

Abordare de sus în jos
Abordare de jos în sus

Presupunere

Conține informații despre o problemă sau problemă care a apărut în timpul procesului de testare și atunci când scriem planurile de testare, ipotezele asigurate ar fi făcute ca resurse și tehnologii etc.

Risc

Acestea sunt provocările cu care trebuie să ne confruntăm pentru a testa aplicația în versiunea curentă și dacă ipotezele vor eșua, atunci riscurile sunt implicate.

De exemplu, efectul pentru o cerere, data lansării devine amânată.

Plan de atenuare sau plan de urgență

Este un plan de rezervă care este pregătit pentru a depăși riscurile sau problemele.

Să vedem împreună un exemplu de asumare, risc și plan de urgență, deoarece sunt corelate unul cu celălalt.

În orice produs, presupunere vom face este că toți cei 3 ingineri de testare vor fi acolo până la finalizarea produsului și fiecăruia dintre ei i se atribuie module diferite, cum ar fi P, Q și R. În acest scenariu particular, risc ar putea fi asta dacă inginerul de testare a lăsat proiectul în mijlocul acestuia.

De aceea plan de intervenție i se va atribui un proprietar principal și subordonat fiecărei caracteristici. Deci, dacă singurul inginer de testare va pleca, proprietarul subordonat preia acea caracteristică specifică și, de asemenea, îl ajută pe noul inginer de testare, astfel încât el/ea să poată înțelege modulele atribuite.

Ipotezele, riscul și planul de atenuare sau de urgență sunt întotdeauna precise asupra produsului în sine. Diferitele tipuri de riscuri sunt următoarele:

Perspectiva clientului
Abordarea resurselor
Aviz tehnic

Rol și responsabilitate

Acesta definește sarcina completă care trebuie îndeplinită de întreaga echipă de testare. Când vine un proiect mare, atunci Manager de testare este o persoană care scrie planul de testare. Dacă există 3-4 proiecte mici, atunci managerul de testare va atribui fiecare proiect fiecărui Test Lead. Și apoi, conducătorul de testare scrie planul de testare pentru proiect, pe care îi este atribuit.

Să vedem un exemplu în care vom înțelege rolurile și responsabilitatea managerului de testare, a șefului de testare și a inginerilor de testare.

Rol: Manager de testare

Nume: Ryan

Responsabilitate:

Pregătiți (scrieți și revizuiți) planul de testare
Conduceți întâlnirea cu echipa de dezvoltare
Conduceți întâlnirea cu echipa de testare
Conduceți întâlnirea cu clientul
Desfășurați o întâlnire lunară în picioare
Închideți nota de lansare
Gestionarea escaladelor și problemelor

Rol: conducător de testare

Nume: Harvey

Responsabilitate:

Pregătiți (scrieți și revizuiți) planul de testare
Conduceți o întâlnire zilnică
Examinați și aprobați cazul de testare
Pregătiți RTM-ul și Rapoartele
Atribuiți module
Program de manipulare

Rol: Inginer de testare 1, Inginer de testare 2 și Inginer de testare 3

Nume: Louis, Jessica, Donna

Atribuiți module: M1, M2 și M3

Responsabilitate:

poate o clasă extinde mai multe clase

Scrieți, revizuiți și executați documentele de testare care constă în cazuri de testare și scenarii de testare
Citiți, revizuiți, înțelegeți și analizați cerința
Scrieți fluxul aplicației
Executați cazul de testare
RTM pentru modulele respective
Urmărirea defectelor
Pregătiți raportul de execuție a testului și comunicați-l șefului de testare.

Programa

Este folosit pentru a explica timpul de lucru, care trebuie făcut sau acest atribut acoperă exact când trebuie să înceapă și să se termine fiecare activitate de testare? Și datele exacte sunt, de asemenea, menționate pentru fiecare activitate de testare pentru data anume.

Prin urmare, după cum putem vedea în imaginea de mai jos, pentru o anumită activitate, va exista o dată de începere și o dată de încheiere; pentru fiecare testare la o anumită versiune, va exista data specificată.

De exemplu

Scrierea cazurilor de testare
Procesul de execuție

Urmărirea defectelor

În general, se face cu ajutorul instrumentelor deoarece nu putem urmări manual starea fiecărui bug. Și, de asemenea, comentăm despre modul în care comunicăm erorile care sunt identificate în timpul procesului de testare și le trimitem înapoi echipei de dezvoltare și cum va răspunde echipa de dezvoltare. Aici menționăm și prioritatea bug-urilor precum mare, medie și scăzută.

Următoarele sunt diverse aspecte ale urmăririi defectelor:

Blocker sau showstopper

De exemplu

Critic

Major

Minor

P1 ridicat

Mediu-P2

P3 scăzut

Prin urmare, pe baza priorității erorilor precum mare, medie și scăzută, o vom clasifica ca P1, P2, P3 și P4.

Medii de testare

Acestea sunt mediile în care vom testa aplicația, iar aici avem două tipuri de medii, care sunt de software și hardware configurație.

The configurarea software-ului înseamnă detalii despre diferite Sisteme de operare ca Windows, Linux, UNIX și Mac si diverse Browsere ca Google Chrome, Firefox, Opera, Internet Explorer , și așa mai departe.

Si configurație hardware înseamnă informații despre diferite dimensiuni ale RAM, ROM și procesoare .

De exemplu

The Software include următoarele:

Server

Sistem de operare	Linux
Server web	Apache Tomcat
Server de aplicații	Websphere
Server de baze de date	Oracle sau MS-SQL Server

Notă: Serverele de mai sus sunt serverele care sunt folosite de echipa de testare pentru a testa aplicația.

Client

Sistem de operare	Windows XP, Vista 7
Browsere	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 și Internet Explorer 8

Notă: Detaliile de mai sus furnizează diferitele sisteme de operare și browsere în care echipa de testare va testa aplicația.

The Hardware include următoarele:

Server : Sun StarCat 1500

Acest server special poate fi folosit de echipa de testare pentru a-și testa aplicația.

Client:

Are următoarea configurație, care este după cum urmează:

Procesor	Intal2GHz
RAM	2 GB
….	….

Notă: va furniza configurația sistemelor inginerilor de testare care este echipa de testare.

Echipa de dezvoltare va oferi configurarea modului de instalare a software-ului. Dacă echipa de dezvoltare nu va furniza încă procesul, atunci îl vom scrie ca Dezvoltare bazată pe sarcini (TBD) în planul de testare.

Criterii de intrare și ieșire

Este o condiție necesară, care trebuie îndeplinită înainte de a începe și opri procesul de testare.

Criterii de intrare

Criteriile de intrare contin urmatoarele conditii:

Testarea cutiei albe ar trebui să fie terminată.
Înțelegeți și analizați cerința și pregătiți documentele de testare sau când documentele de testare sunt gata.
Datele de testare ar trebui să fie gata.
Build sau aplicația trebuie pregătită
Modulele sau caracteristicile trebuie alocate diferiților ingineri de testare.
Resursa necesară trebuie să fie gata.

Criterii de ieșire

Criteriile de ieșire conțin următoarele condiții:

Când toate cazurile de testare sunt executate.
Majoritatea cazurilor de testare trebuie să fie a trecut .
Depinde de gravitatea erorilor, ceea ce înseamnă că nu trebuie să existe niciun blocant sau erori majore, în timp ce există unele erori minore.

Înainte de a începe să efectuăm teste funcționale, toate cele de mai sus Criterii de intrare ar trebui urmat. După ce am efectuat testarea funcțională și înainte vom face testarea de integrare, apoi Criteriile de ieșire ale testarea funcțională trebuie urmată deoarece criteriile % de ieșire sunt decise de întâlnirea atât cu managerul de dezvoltare, cât și cu managerul de testare deoarece colaborarea acestora poate atinge procentul. Dar dacă nu sunt respectate criteriile de ieșire ale testării funcționale, atunci nu putem trece mai departe la testarea integrării.

Aici pe baza severității bug-ul înseamnă că echipa de testare ar fi decis că să continue în fazele următoare.

Test de automatizare

În acest sens, vom decide următoarele:

Ce caracteristică trebuie să fie automatizată și nu?
Ce instrument de automatizare a testelor vom folosi pe ce cadru de automatizare?

Automatizăm cazul de testare numai după prima lansare.

Aici se pune întrebarea că pe ce bază noi voi decideți ce caracteristici trebuie testate?

În imaginea de mai sus, după cum putem vedea că funcțiile cele mai frecvent utilizate trebuie testate din nou și din nou. Să presupunem că trebuie să verificăm aplicația Gmail unde sunt caracteristicile esențiale Compuneți e-mailuri, Articole trimise și Mesaje primite . Așa că vom testa aceste funcții, deoarece în timp ce efectuați testarea manuală, este nevoie de mai mult timp și devine, de asemenea, o muncă monotonă.

Acum, cum decidem ce caracteristici nu vor fi testate?

Presupune ajutorul caracteristica aplicației Gmail nu este testată din nou și din nou, deoarece aceste funcții nu sunt utilizate în mod regulat, așa că nu trebuie să o verificăm frecvent.

Dar dacă unele caracteristici sunt instabile și au o mulțime de erori , ceea ce înseamnă că nu vom testa acele caracteristici, deoarece trebuie testate din nou și din nou în timp ce facem testarea manuală.

Dacă există o caracteristică care trebuie testată frecvent , dar ne așteptăm la modificarea cerințelor pentru acea caracteristică, așa că nu o verificăm, deoarece modificarea cazurilor de testare manuale este mai confortabilă în comparație cu modificarea scriptului de testare de automatizare.

Estimarea efortului

În acest sens, vom planifica efortul necesar pentru fiecare membru al echipei.

Livrabil de testare

Acestea sunt documentele care sunt rezultatul echipei de testare, pe care le-am predat clientului împreună cu produsul. Acesta include următoarele:

Planul de testare Cazuri de testare Scripturi de testare RTM (Matricea de urmărire a cerințelor) Raport defect Raport de execuție a testului Grafice și metrici Note de lansare

Grafice și metrici

Grafic

În aceasta, vom discuta despre tipurile de grafice vom trimite și vom oferi, de asemenea, o mostră din fiecare grafic.

După cum putem vedea, avem cinci grafice diferite care arată diferitele aspecte ale procesului de testare.

Graficul 1: În aceasta, vom arăta câte defecte au fost identificate și câte defecte au fost remediate în fiecare modul.

Graficul 2: Figura 1 arată câte defecte critice, majore și minore au fost identificate pentru fiecare modul și câte au fost remediate pentru modulele respective.

Graficul 3: În acest grafic special, reprezentăm construi un grafic înțelept , ceea ce înseamnă că în fiecare build câte defecte au fost identificate și remediate pentru fiecare modul. Pe baza modulului, am determinat erorile. Vom adauga R pentru a arăta numărul de defecte în P și Q și, de asemenea, adăugăm S pentru a arăta defectele din P, Q și R.

Graficul 4: Cablul de testare va proiecta Analiza tendințelor erorilor grafic care se creează în fiecare lună și îl trimite și la Conducere. Și este exact ca predicția care se face la sfârșitul produsului. Și aici, putem și noi evaluați remedierea erorilor după cum putem observa că arc are o tendinta ascendenta în imaginea de mai jos.

Graficul 5: The Manager de testare a proiectat acest tip de grafic. Acest grafic are scopul de a înțelege decalajul în evaluarea erorilor și a erorilor reale care au apărut, iar acest grafic ajută, de asemenea, la îmbunătățirea evaluării erorilor în viitor.

Metrici

Ca și mai sus, creăm graficul de distribuție a erorilor, care se află în figura 1 și, cu ajutorul datelor menționate mai sus, vom proiecta și metricile.

De exemplu

În figura de mai sus, păstrăm înregistrările tuturor inginerilor de testare dintr-un anumit proiect și câte defecte au fost identificate și remediate. De asemenea, putem folosi aceste date pentru analize viitoare. Când apare o nouă cerință, putem decide cui să furnizăm caracteristica provocatoare pentru testare, pe baza numărului de defecte pe care le-au găsit mai devreme, în conformitate cu valorile de mai sus. Și vom fi într-o situație mai bună să știm cine poate gestiona foarte bine caracteristicile problematice și să găsim un număr maxim de defecte.

Notă de lansare: Este un document care este pregătit în timpul lansării produsului și semnat de Managerul de testare.

În imaginea de mai jos, putem vedea că produsul final este dezvoltat și implementat către client, iar cel mai recent nume de lansare este Beta .

The Notă de lansare constă din următoarele:

Manual de utilizare.
Lista defectelor în așteptare și deschise.
Lista de funcții adăugate, modificate și șterse.
Lista platformei (Sistem de operare, Hardware, Browsere) pe care este testat produsul.
Platformă în care produsul nu este testat.
Lista erorilor remediate în versiunea curentă și lista erorilor remediate în versiunea anterioară.
Procesul de instalare
Versiuni ale software-ului

De exemplu

Să presupunem că Beta este a doua ediție a aplicației după prima lansare Alfa este lansat. Unele dintre defectele identificate în prima lansare și care au fost remediate în eliberarea ulterioară. Și aici, vom evidenția, de asemenea, lista de funcții nou adăugate, modificate și șterse de la versiunea alfa până la versiunea beta.

Șablon

Această parte conține toate șabloanele pentru documentele care vor fi utilizate în produs, iar toți inginerii de testare vor folosi doar aceste șabloane în proiect pentru a menține consistența produsului. Aici, avem diferite tipuri de șablon care sunt utilizate pe parcursul întregului proces de testare, cum ar fi:

Șablon de caz de testare
Șablon de examinare a cazului de testare
Șablon RTM
Șablon de raportare erori
Raport de execuție a testului

Să vedem un eșantion de document al planului de testare

Pagina 1

Pagina3-pagina18

Pagina-20

În pagina 1, completăm în primul rând numai Versiuni, autor, comentarii și revizuit de câmpuri, iar după ce managerul îl aprobă, vom menționa detaliile în Aprobat până și data aprobării câmpuri.

În mare parte, planul de testare este aprobat de managerul de testare, iar inginerii de testare îl revizuiesc doar. Și când vor veni noile funcții, vom modifica planul de testare și vom face modificările necesare în Versiune câmp, iar apoi va fi trimis din nou pentru revizuire, actualizare și aprobare ulterioară din partea managerului. Planul de testare trebuie actualizat ori de câte ori au apărut modificări. La pagina 20, Referințe specificați detaliile despre toate documentele pe care le vom folosi pentru a scrie documentul de plan de testare.

Notă:

Cine scrie planul de testare?

Cablu de testare→60%
Manager de testare→20%
Inginer de testare→20%

Prin urmare, după cum putem vedea de sus, că în 60% din produs, planul de testare este scris de Tester Lead.

Cine examinează planul de testare?

Cablu de testare
Manager de testare
Inginer de testare
Client
Echipă de dezvoltare

Inginerul de testare revizuiește planul de testare din perspectiva modulului său, iar managerul de testare revizuiește planul de testare pe baza părerii clientului.

Cine aprobă planul de testare?

Verificarea java este nulă

Client
Manager de testare

Cine scrie cazul de testare?

Cablu de testare
Inginer de testare

Cine examinează cazul de testare?

Inginer de testare
Cablu de testare
Client
Echipă de dezvoltare

Cine aprobă cazurile de testare?

Manager de testare
Cablu de testare
Client

Ghid pentru planul de testare

Restrângeți planul de testare.
Evitați suprapunerea și redundanța.
Dacă credeți că nu aveți nevoie de o secțiune care este deja menționată mai sus, atunci ștergeți acea secțiune și continuați.
Fii specific. De exemplu, când specificați un sistem software ca parte a mediului de testare, apoi menționați versiunea software în loc de doar nume.
Evitați paragrafele lungi.
Folosiți liste și tabele ori de câte ori este posibil.
Actualizați planul atunci când este necesar.
Nu utilizați un document învechit și neutilizat.

Importanța planului de testare

Planul de testare dă direcție gândirii noastre. Acesta este ca o carte de reguli, care trebuie respectată.
Planul de testare ajută la determinarea eforturilor necesare pentru validarea calității aplicației software supusă testului.
Planul de testare îi ajută pe acești oameni să înțeleagă detaliile testului care au legătură cu exteriorul, cum ar fi dezvoltatorii, managerii de afaceri, clienții etc.
Aspecte importante precum programul de testare, strategia de testare, domeniul de testare etc. sunt documentate în planul de testare, astfel încât echipa de management să le poată revizui și reutiliza pentru alte proiecte similare.