Meniu

Când se oprește testarea (Criteriile de ieșire din testarea software-ului)

when stop testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Criteriile de ieșire din testare:

„Bine început este pe jumătate făcut” - Se aplică peste tot, chiar și testarea software-ului.

Deseori vedem testeri de software foarte entuziaști la începutul proiectului. Noi creăm testarea documentelor precum Strategia de testare, Planul de testare sau Cazurile de testare cu nerăbdare și entuziasm.

Apoi ajungem la testarea software-ului cu un BANG! Acest lucru este amplificat doar de defectele interesante pe care le găsim la începutul proiectului. Rezolvarea lor va contribui doar la realizarea noastră.

când să oprești testarea

Pe măsură ce găsim o mulțime de defecte și finalizăm prima rundă, trecem la faza următoare. Când ajungem la a doua cursă ne relaxăm și așa cum este tendința generală a omului plictisindu-se de testarea aceluiași lucru în a doua rundă.

clasificarea arborelui decizional în exploatarea datelor

Mulți testeri simt că devine muncă monotonă în rundele ulterioare și începeți să vă pierdeți interesul de a testa același software din nou și din nou. Când ajungem la, poate a treia rundă, o întrebare începe să ne bântuie și este „Când să oprim testarea software-ului?”

Pun pariu că trebuie să fi simțit la fel și ați întrebat „Când să încetați testarea?”, Cel puțin o dată. Aș spune că întrebarea este „Când, unde și cum să oprești testarea?” :)

Conceptual am citit și mulți testeri cred că nu poate exista o condiție sau o ecuație specifică pentru a decide „Când să oprești testarea?” Există o serie de factori de luat în considerare înainte de a ajunge la concluzia asupra acestei întrebări.

În articolul de astăzi, aș dori să vă împărtășesc gândurile despre cum să închei activitățile de testare atunci când ajungem la un punct din ciclul nostru de testare în care putem spune că testarea este suficientă. Vom face acest lucru cu ajutorul câtorva exemple din viața reală într-un ciclu tipic de testare.

Ce veți învăța:

Când este suficient testarea?

Când putem spune că atâta testare este suficientă? Testarea poate fi finalizată vreodată?

Pentru a răspunde la aceste întrebări, va trebui să analizăm activitățile de testare de la început până la sfârșit. Vă rugăm să rețineți că - Voi defini aceste activități în termenii unui laic - Nu într-un mod tehnic elegant.

Să considerăm că începeți testarea unui nou proiect.

Activități inițiale:

  • Echipa de testare primește cerințe.
  • Echipa de testare începe planificare și proiectare.
  • Documentele de testare inițiale sunt gata și revizuite.

Testul nr. 1)

  • Echipa de testare începe executarea testului odată ce primesc produsul dezvoltat.
  • În timpul fazei de testare, ei execută diferite scenarii pentru a sparge software-ul și a găsi multe defecte. (De asemenea, rata defectelor aici este mai mare, deoarece aplicația este nouă și este în curs de evaluare pentru prima dată.)
  • Defectele sunt remediate de către dezvoltatori și returnate înapoi la echipa de testare pentru reevaluare.
  • Echipa de testare efectuează reevaluarea defectelor și execută regresia.
  • Odată ce majoritatea defectelor cu severitate ridicată sunt rezolvate și software-ul pare stabil, echipa de dezvoltare lansează următoarea versiune.

Testul de rulare nr. 2)

  • Echipa de testare începe a doua rundă de testare și activități similare sunt executate ca Runda 1.
  • În acest proces, în timpul celei de-a doua runde de testare, mai sunt detectate câteva defecte.
  • Defectele sunt remediate de dezvoltatori și returnate înapoi echipei de testare pentru o nouă testare.
  • Echipa de testare re-testează defectele și funcționează regresie .

Acest lucru poate continua pentru totdeauna. Rulați 3, rulați 4 până când se găsesc toate defectele software-ului și software-ul devine fără erori.

Dacă dorim să desenăm o diagramă pentru aceste activități, va arăta aproximativ ca mai jos:

Test diagramă de flux

Din diagrama de mai sus, putem concluziona în mod clar că testarea poate continua până când se găsesc toate defectele software-ului.

Dar întrebarea este - Este posibil să găsiți fiecare defect în software? Să încercăm să găsim răspunsul la această întrebare de un milion de dolari :).

Oprirea când se găsesc toate defectele: Este posibil?

Majoritatea software-urilor sunt complexe și au un domeniu enorm de testare. Nu este imposibil să găsiți toate defectele software-ului, dar va dura pentru totdeauna.

Chiar și după ce am găsit multe erori în software, nimeni nu poate garanta de fapt că software-ul este acum fără defecte. Nu poate exista o situație în care să putem spune cu încredere că am finalizat testarea, că am găsit toate defectele software-ului și că nu mai are erori.

Mai mult, scopul testării nu este de a găsi fiecare defect al software-ului. Intenția testării software-ului este de a dovedi că software-ul funcționează conform intenției, rupându-l sau găsind abateri între comportamentul său actual și comportamentul așteptat.

Există defecte nelimitate în software și, prin urmare, nu este practic să îl testăm până când nu se găsesc toate defectele, deoarece nu putem ști niciodată care este defectul ultimul. Adevărul este că nu putem depinde de găsirea tuturor defectelor din software pentru a încheia testarea.

Sincer vorbind, testarea este nesfârșită și ciclurile de testare vor continua până când se ia o decizie când și unde să se oprească. Acum devine și mai complicat să se ia o decizie de a opri testarea. Dacă „oprirea când se găsesc toate defectele” nu este criteriul de a opri testarea, atunci pe ce bază ar trebui să se decidă?

Decizia de a opri testarea: Criteriile de ieșire

Să încercăm acum să înțelegem - Care sunt cei mai importanți factori care trebuie luați în considerare la încheierea activităților de testare? Cred că decizia de a opri testarea depinde în mare măsură de Timp, buget și amploarea testării.

Cea mai obișnuită abordare este oprirea atunci când timpul / bugetul este epuizat sau toate scenariile de testare sunt executate. Cu toate acestea, cu această abordare, vom compromite calitatea testării și acest lucru nu va oferi suficientă încredere în software; Cum?

Să vedem cu unexemplu.

Scenariu de testare:

Să presupunem că testați un modul software. Vi s-a alocat un anumit buget pentru acoperirea acestuia. Termenele proiectului sunt pentru o lună. Scenariile totale de testare sunt 200. Sunteți singurul care testează acest modul.

Scenariul 1)

Saptamana 1: Găsiți defectul showstopper / severitatea 1 în ziua 1 și întregul test este blocat timp de 3 zile. Prin urmare, nu puteți executa niciunul dintre scenarii până când nu se rezolvă defectul de severitate 1. După pierderea a 3 zile, blocatorul este rezolvat și continuați cu executarea.

La sfârșitul săptămânii, finalizați 20 de scenarii cu puține valori mai importante defecte prioritare .

Săptămâna 2: Începeți să testați software-ul punând mai mult accent pe depistarea defectelor. Mai deschideți câteva defecte de severitate 1, 2 și 3 în timpul celei de-a doua săptămâni și la sfârșitul săptămânii, puteți acoperi 70 de scenarii.

Săptămâna 3: Până la începutul celor 3rdsăptămână veți rezolva toate defectele cu prioritate ridicată, așa că, împreună cu executarea scenariilor în așteptare, trebuie să re-testați toate defectele care au aterizat în cupa de testare. Continuând cu progresul bun, acoperiți 120 de scenarii cu defecte suplimentare.

În acest moment, toate defectele cu prioritate ridicată sunt deja găsite și raportate. Deci, acum mai aveți doar defecte de severitate 3 de găsit.

Săptămâna 4: Până în săptămâna 4 trebuie să re-testați majoritatea defectelor deschise și a celor 80 de scenarii rămase. Cu aceasta până la sfârșitul săptămânii 4, puteți finaliza până la 180 de scenarii cu toate defectele cu prioritate înaltă și medie remediate și re-testate.

Punerea acestor informații în formă tabelară:

SăptămâniActivități de testare efectuateRezultat la sfârșitul săptămânii
Saptamana 1• Ziua 1 - Afișarea defectului Stopper găsit.
• Testarea este blocată din cauza defectului de severitate 1 constatat în ziua 1.
• Defectul blocantului a fost rezolvat în ziua 4.
• Execuția testului a continuat până la sfârșitul săptămânii 1.		• Priorități ridicate / Defecte critice deschise.
• 20 de scenarii finalizate.
Săptămâna 2• Mai multă concentrare pe depistarea defectelor.
• Executarea scenariilor de testare rămase.
• Re-testarea defectelor remediate.		• Mai puține defecte de severitate 1, 2 și 3 au fost deschise.
• Acoperire totală 70 Scenarii acoperite.
Săptămâna 3• Re-testarea tuturor defectelor cu prioritate ridicată.
• Executarea scenariilor de testare rămase.
• Doar defectele de gravitate 3 au rămas de găsit.		• Mai puține defecte de severitate 1, 2 și 3 au fost deschise.
• Acoperire totală 120 Scenarii acoperite.
Săptămâna 4• Re-testarea tuturor defectelor cu prioritate ridicată și medie.
• Executarea scenariilor de testare rămase.		• Mai puține defecte de severitate 3 au fost deschise.
• Acoperire totală 180 de scenarii acoperite.

Ar trebui să te oprești aici?

Motivul pentru care v-ați epuizat Timpul de testare complet și au raportat și remediat majoritatea defectelor cu prioritate ridicată. Oprirea în acest moment vă va oferi încredere în software? Nu chiar din cauza motivelor de mai jos:

  • Scenariile nu sunt executate complet.
  • Puține fluxuri nici măcar nu sunt testate o dată.
  • Toate scenariile acoperite sunt executate o singură dată.
  • Software-ul are încă defecte.
  • Regresia nu este acoperită.

Scenariul nr. 2)

Saptamana 1: Găsiți un defect de severitate 1 în ziua 1 și testarea completă este blocată timp de 3 zile. Prin urmare, nu puteți executa niciunul dintre scenarii până când nu se rezolvă defectul de severitate 1. După pierderea a 3 zile, blocatorul este rezolvat și continuați cu executarea.

La sfârșitul săptămânii, finalizați 20 de scenarii cu câteva alte defecte. Săptămâna aceasta rămâne aceeași cu scenariul 1.

Săptămâna 2: Mai deschideți câteva defecte Severitate 1, Severitate 2 și Severitate 3 în a doua săptămână, dar accentul este să acoperiți mai multe scenarii pentru a acoperi restanțele din săptămâna 1. La sfârșitul săptămânii, puteți acoperi 120 de scenarii.

Săptămâna 3: Până la începutul celor 3rdsăptămână veți rezolva toate defectele deschise, așa că, împreună cu executarea scenariilor în așteptare, trebuie să re-testați toate defectele care sunt aterizate într-o cupă de testare. Continuând cu progrese bune la sfârșit, numărul scenariilor finalizate devine 200 cu defecte suplimentare.

Acum puteți raporta doar defectele Severity 2 și Severity 3.

Punerea acestor informații în formă tabelară:

SăptămâniActivități de testare efectuateRezultat la sfârșitul săptămânii
Saptamana 1• Ziua 1 - Afișare defect opritor găsit.
• Testarea este blocată din cauza defectului de severitate 1 constatat în ziua 1.
• Defect blocant rezolvat în ziua 4.
• Execuția testului a continuat până la sfârșitul primei săptămâni.		• Priorități ridicate / Defecte critice deschise.
• 20 de scenarii finalizate.
Săptămâna 2• Accentul este pe executarea mai multor scenarii pentru a acoperi restanțele din săptămâna precedentă.
• Re-testarea defectelor remediate.		• Mai puține defecte de severitate 1, severitate 2 și 3 au fost deschise.
• Acoperire totală 120 Scenarii acoperite.
Săptămâna 3• Re-testarea tuturor defectelor cu prioritate ridicată.
• Executarea scenariilor de testare rămase.
• Doar Severitatea 3 și câteva defecte ale Severității 2 rămân de găsit.		• Mai puține defecte de severitate 1, severitate 2 și 3 au fost deschise.
• Toate scenariile acoperite.

Ar trebui să te oprești aici?

Tu ai a acoperit complet toate scenariile de testare odată și au deschis câteva defecte majore. Oprirea în acest moment vă va oferi încredere în software?

Nu chiar din cauza motivelor de mai jos:

  • Toate scenariile sunt executate o singură dată.
  • Software-ul are încă multe defecte majore.
  • Regresia nu este acoperită.

Putem vedea că calitatea este compromisă deasupra ambelor scenarii. Cea mai bună abordare va fi găsirea unui punct în care toți factorii din scenariul 1 și scenariul 2 sunt acoperiți și calitatea nu este compromisă. Pentru a realiza acest lucru, va trebui să definim anumite criterii la începutul testării.

Aceste criterii sunt denumite criterii de finalizare sau de ieșire. Este răspunsul la întrebarea noastră - „Când să oprești testarea?”.

Ce sunt criteriile de finalizare sau de ieșire?

Criteriile de ieșire sunt evaluate la sfârșitul ciclului de testare și sunt definite în Planul de testare. Este setul de condiții sau activități care trebuie îndeplinite pentru a încheia testarea.

Criteriile de ieșire definesc cât de mult este suficient testarea și când activitățile de testare pot fi declarate complete. Acoperire și criteriile de finalizare sunt combinate pentru a defini criteriile de ieșire pentru testare.

Ce ar trebui să fie prezent în Criteriile de ieșire?

În mod ideal, Criteriile de ieșire sau oprire sunt definite prin combinarea diferiților factori și, prin urmare, este unic în toate proiectele. Depinde de cerința proiectului și, prin urmare, ar trebui definit în timpul planificării testelor; la începutul proiectului. Parametrii definiți în acesta ar trebui să fie cuantificați cât mai mult posibil.

Mai jos sunt câteva indicații care trebuie luate în considerare la definirea criteriilor de ieșire în cazul testării funcționale sau a sistemului. Puteți combina câțiva sau toți factorii de mai jos, în timp ce decideți unde să opriți testarea conform nevoilor proiectului dvs.

Testarea poate fi oprită atunci când:

Cerințe:

  • Se realizează acoperirea 100% a cerințelor.

Defecte:

  • S-a atins numărul defectelor definite / dorite.
  • Toate defectele sau blocantele Show Stopper sunt remediate și niciun defect cunoscut critic / severitate 1 nu este în stare deschisă.
  • Toate defectele cu prioritate înaltă sunt identificate și remediate.
  • Rata defectelor scade sub rata acceptabilă definită.
  • Foarte puține defecte cu prioritate medie sunt deschise și au o soluție la locul lor.
  • Foarte puține defecte deschise cu prioritate redusă care nu afectează utilizarea software-ului.
  • Toate defectele cu prioritate înaltă sunt re-testate și închise și scenariile de regresie corespunzătoare sunt executate cu succes.

Acoperirea testului:

  • Acoperirea testului trebuie realizată cu 95%.
  • Rata de promovare a cazului de testare ar trebui să fie de 95%. Acest lucru poate fi calculat prin formulă
    • (Numărul total de TC-uri promovate / Numărul total de TC-uri) * 100.
  • Toate cazurile de testare critice sunt trecute.
  • 5% cazuri de testare pot fi eșuate, dar cazurile de testare nereușite au prioritate redusă.
  • Se realizează o acoperire funcțională completă.
  • Toate fluxurile majore funcționale / de afaceri sunt executate cu succes cu diverse intrări și funcționează bine.

Termenele limită:

  • Termenul limită al proiectului sau termenul de finalizare a testului este atins.

Documente de testare:

  • Toate documentele de testare / livrabile (Exemplu - Raport rezumat test ) sunt pregătite, revizuite și publicate peste tot.

Buget:

  • Bugetul complet de testare este epuizat.

Întâlniri „Du-te / Nu Du-te”:

  • ' Du-te / Nu Du-te ' întâlnire a fost realizat cu părțile interesate și se ia o decizie dacă proiectul ar trebui să meargă la producție sau nu.

Concluzie:

Să facem acest lucru foarte simplu la final.

Vă rugăm să răspundeți la întrebări cu un simplu Da sau Nu.

Dacă primiți majoritatea răspunsurilor ca Da, înseamnă că puteți opri testarea în acest moment. Dacă majoritatea răspunsurilor sunt Nu, înseamnă că trebuie să verificați ce lipsește din testare și acest lucru vă poate ajuta să găsiți un defect de producție care scapă :)

  • Sunt toate cazurile de testare executate cel puțin o dată?
  • Rata de testare a cazului de testare este definită?
  • S-a realizat acoperirea completă a testului?
  • Sunt executate toate fluxurile funcționale / de afaceri cel puțin o dată?
  • Este atins numărul de defecte decis?
  • Sunt toate defectele majore cu prioritate ridicată fixate și închise?
  • Au fost retestate și închise toate defectele?
  • S-a făcut regresia pentru toate defectele deschise?
  • Ați epuizat bugetul de testare?
  • A ajuns timpul de încheiere a testării?
  • Sunt toate rezultatele testate revizuite și publicate?

Despre autor: Acesta este un articol invitat de Renuka K. Are peste 11 ani de experiență în testarea software-ului.

cea mai bună companie de recuperare a datelor de pe hard disk

Sper că acest articol ți-a fost de ajutor. Aș dori, de asemenea, să vă aud gândurile / comentariile pe această temă.

Testare fericită!

Lectură recomandată

^