Meniu

Testare exploratorie vs testare scriptată: cine câștigă?

exploratory testing vs scripted testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Beneficiile din lumea reală ale testelor exploratorii:

În mod tradițional, testarea software-ului a fost o activitate foarte rigidă, dar în ultimii ani a existat o schimbare de la testarea bazată pe scripturi. Testarea exploratorie , care este mai mult bazat pe context, a ieșit în prim plan. Asta pentru că oferă testerilor mai multă libertate de a-și exploata abilitățile și cunoștințele și îi face responsabili pentru optimizarea valorii propriei lor munci.

Testare exploratorie vs testare scriptată

Nu toată lumea este vândută la valoarea testelor exploratorii. Lipsa percepută de formalitate și accentul pus pe responsabilitatea personală pot declanșa sunete de alarmă. Dar această preocupare se bazează în mare parte pe o interpretare greșită a testelor exploratorii. Nu este vorba despre aruncarea regulilor pe fereastră și testarea la întâmplare, este de fapt foarte structurată și sistematică. Și este, de asemenea, extrem de eficient.

Scepticii doresc dovada concretă a faptului că face mai mult decât îmbunătățirea moralului testerului. De aceea, am decis să desfășurăm un studiu care să pună testele exploratorii bazate pe context direct în raport cu o abordare de testare bazată pe scripturi. Rezultatele au fost foarte interesante, pe măsură ce veți afla.

Ce veți învăța:

exemple de cazuri de testare pentru aplicații web

Echipe de testare bazate pe context (testare exploratorie) vs scripturi

Două echipe, două abordări:

Am început prin a împărți testerii în două echipe de câte trei. Testerii din fiecare echipă aveau aceleași cunoștințe de aplicație comparabile. Aceleași definiții pentru severitatea defectului (major, minor) au fost stabilite pentru ambele echipe. Ambele echipe au primit aceeași versiune de aplicație. O echipă („scriptată”) ar aplica o abordare tradițională de testare bazată pe scripturi, iar cealaltă echipă („exploratorie”) ar adopta o abordare de testare bazată pe context. Activitățile de testare ar fi împărțite în două faze de câte trei zile fiecare.

Echipa bazată pe scenarii a identificat cinci fluxuri de lucru pentru a testa și a generat 15 cazuri de testare. Cazurile de testare au fost limitate, astfel încât testerii nu au avut nicio libertate de a explora în afara limitelor scriptului.

Echipa exploratorie a creat două hărți mentale vizuale , una care a identificat acoperirea testelor și cartele de testare, iar cealaltă care acoperă componentele / modulele produsului. Procesul a produs 24 de charte de testare în total. Cartele definite au fost la nivel înalt și au permis interpretarea contextuală, extinzând sfera sesiunii de testare pentru testeri.

Faza 1:

Echipa cu scenarii a reușit să finalizeze 6 cazuri de testare în cele trei zile alocate. Au raportat 6 defecte majore în acel moment.

Echipa de explorare a reușit să finalizeze 13 sesiuni de testare cuprinse între 30 de minute și 180 de minute fiecare. Au raportat 10 defecte majore și 5 defecte minore.

testare scripturată vs testare exploratorie 1

Interesant este că echipa de explorare a raportat toate defectele pe care echipa de scenariu le raportase.

Faza 2:

Echipa cu scenarii a reușit să finalizeze 9 cazuri de testare de data asta. Au raportat 10 defecte majore și 8 defecte minore .

Echipa de explorare a finalizat 18 sesiuni. Au raportat 14 defecte majore și 5 defecte minore.

testare scripturată vs testare exploratorie 2

În faza 2, echipa cu scenariu a raportat 2 defecte majore și 1 defecte minore pe care echipa de explorare nu le-a găsit, dar echipa de explorare a raportat 3 defecte majore și 1 defecte minore pe care echipa de scenariu nu le-a raportat.

Acest lucru nu ia în considerare complexitatea relativă a fluxurilor de lucru care ar fi putut fi alese de testeri în cadrul acestor sesiuni și în cazurile de testare, dar putem trage totuși câteva concluzii interesante.

Ce înseamnă?

S-ar părea că o abordare exploratorie, precum și responsabilitatea și flexibilitatea pe care o generează, rezultă într-o formă mai eficientă de testare. Poate fi posibil să acoperiți mai mult teren dezvoltând și adaptând cartele de test pe măsură ce sesiunile de test progresează, pe baza a ceea ce are sens în context. Această libertate lipsește în testarea bazată pe scripturi și poate preveni descoperirea defectelor.

cel mai bun editor python mac os x

A te lipi rigid de scripturi creează căi bine purtate și doar prin abaterea de la acele căi vom descoperi toate defectele. După cum sa menționat de mai multe ori de către liderii de gândire din cadrul comunității de testare, „Dacă vă imaginați un produs ca un câmp al minelor terestre și fiecare mină terestră este un defect, atunci este destul de clar că parcurgerea aceeași cale nu este calea de a le găsi toate.'

În cele din urmă, niciuna dintre abordări nu a fost perfectă, deoarece fiecare echipă a raportat defecte pe care cealaltă echipă nu le-a identificat, chiar dacă echipa de explorare a raportat mai multe, în general.

Realist, aceasta poate însemna că abordarea corectă, în ceea ce privește apropierea cât mai mare posibil de defectele „minime”, va fi un amestec al celor două. Dar, există multe beneficii cu abordare bazată pe context care vorbesc în favoarea sa. Necesită mai puțin timp de pregătire, mai puțină documentare, identifică problemele mai devreme și provoacă testerii să utilizeze abilități analitice și raționamente deductive. Aceștia dobândesc o înțelegere mai profundă și mai aprofundată a produsului și acționează cu adevărat ca avocați pentru utilizatorul final.

Concluzie

Rezultatul final demonstrează că testarea exploratorie duce la raportarea mai multor defecte înainte de lansare, rezultând un produs mai bun livrat de echipă și, în cele din urmă, testeri mai mulțumiți / îndepliniți care sunt toate rezultatele de dorit, în orice fel îl priviți.

Despre autor

Mush Honda este director QA la Tehnologie KMS , un furnizor de servicii IT pe tot parcursul ciclului de viață al dezvoltării software cu birouri în Atlanta, GA și Ho Chi Minh City, Vietnam. Anterior a fost tester la Ernst & Young, Nexidia, Colibrium Partners și Connecture. Serviciile KMS includ gestionarea aplicațiilor, testarea, asistența, serviciile profesionale și creșterea personalului.

Ești de acord? Nu ezitați să postați comentariile dvs., întrebările de mai jos.

PREV Tutorial | URMATORUL Tutorial nr. 4: Testare exploratorie cu HP Sprinter

Lectură recomandată

^