7 principles software testing
Șapte principii de testare software: inclusiv mai multe detalii despre gruparea defectelor, principiul Pareto și paradoxul pesticidelor.
Sunt sigur că toată lumea este conștientă de „ Șapte principii de testare software ”.
Aceste principii fundamentale de testare ajută echipele de testare să își folosească timpul și efortul pentru a face procesul de testare eficient. În acest articol, vom învăța în detaliu despre două principii, adică Clusterarea defectelor, principiul Pareto și paradoxul pesticidelor .
Ce veți învăța:
- Șapte principii de testare software
Șapte principii de testare software
Înainte de a analiza în detaliu aceste două principii, să înțelegem pe scurt cele șapte principii ale testării software.
Să explorăm !!
# 1) Testarea arată prezența defectelor
Fiecare aplicație sau produs este lansat în producție după o cantitate suficientă de testare de către diferite echipe sau trece prin diferite faze, cum ar fi testarea integrării sistemului, testarea acceptării utilizatorilor și testarea beta etc.
Asa de ați văzut sau ați auzit vreodată de la vreuna dintre echipele de testare că au testat complet software-ul și că nu există niciun defect în software ? În loc de asta, fiecare echipă de testare confirmă faptul că software-ul îndeplinește toate cerințele afacerii și că funcționează conform nevoilor utilizatorului final.
În industria testării software-ului, nimeni nu va spune că există niciun defect în software, ceea ce este destul de adevărat, deoarece testarea nu poate dovedi că software-ul este fără erori sau fără defecte.
Cu toate acestea, obiectivul testării este de a găsi din ce în ce mai multe defecte ascunse folosind diferite tehnici și metode. Testarea poate dezvălui defecte nedescoperite și dacă nu se găsesc defecte, atunci nu înseamnă că software-ul este fără defecte.
Exemplul 1 :
Luați în considerare o aplicație bancară, această aplicație este testată temeinic și suferă diferite faze de testare, cum ar fi SIT, UAT etc. și în prezent nu sunt identificate defecte în sistem.
Cu toate acestea, ar putea exista posibilitatea ca, în mediul de producție, clientul efectiv să încerce o funcționalitate care este rar utilizată în sistemul bancar, iar testerii au trecut cu vederea acea funcționalitate, prin urmare nu a fost găsit niciun defect până în prezent sau codul nu a fost niciodată atins de dezvoltatori. .
Exemplul 2:
Am văzut mai multe reclame pentru săpunuri, pastă de dinți, spălare de mână sau spray-uri dezinfectante etc. la televizor.
Luați în considerare o reclamă de spălare a mâinilor care spune la televizor că 99% germeni pot fi eliminați dacă se folosește acea spălare de mână specifică. Acest lucru demonstrează în mod clar că produsul nu este 100% fără germeni. Astfel, în conceptul nostru de testare, putem spune că niciun software nu este defect.
# 2) Testarea timpurie
Testerii trebuie să se implice într-un stadiu incipient al ciclului de viață al dezvoltării software-ului (SDLC). Astfel, pot fi identificate defectele din faza de analiză a cerințelor sau orice defecte ale documentației. Costul implicat în remedierea unor astfel de defecte este foarte mic în comparație cu cele care se găsesc în etapele ulterioare ale testării.
Luați în considerare imaginea de mai jos, care arată cum crește costul remedierii defectelor pe măsură ce testarea se îndreaptă spre producția live.
(imagine sursă )
Imaginea de mai sus arată că costul necesar pentru remedierea unui defect găsit în timpul analizei cerințelor este mai mic și continuă să crească pe măsură ce ne îndreptăm spre faza de testare sau de întreținere.
Acum întrebarea este cât de devreme ar trebui să înceapă testarea ?
Odată ce cerințele sunt finalizate, testerii trebuie să se implice pentru testare. Testarea ar trebui să fie efectuată pe documente de cerințe, specificații sau orice alt tip de document, astfel încât, în cazul în care cerințele sunt definite incorect, atunci acesta poate fi reparat imediat, mai degrabă decât fixarea lor în faza de dezvoltare.
# 3) Testarea exhaustivă nu este posibilă
Nu este posibil să testați toate funcționalitățile cu toate combinațiile valide și nevalide de date de intrare în timpul testării reale. În loc de această abordare, testarea câtorva combinații este considerată pe baza priorității folosind diferite tehnici.
Testarea exhaustivă va necesita eforturi nelimitate și majoritatea acestor eforturi sunt ineficiente. De asemenea, calendarul proiectului nu va permite testarea unui număr atât de mare de combinații. Prin urmare, este recomandat să testați datele de intrare folosind diferite metode, cum ar fi partiționarea echivalenței și analiza valorii limită.
De exemplu ,Dacă presupunem că avem un câmp de intrare care acceptă alfabete, caractere speciale și numere de la 0 la 1000. Imaginați-vă câte combinații ar apărea pentru testare, nu este posibil să testați toate combinațiile pentru fiecare tip de intrare.
Eforturile de testare necesare testării vor fi uriașe și vor avea un impact asupra calendarului și costului proiectului. Prin urmare, se spune întotdeauna că testarea exhaustivă nu este practic posibilă.
# 4) Testarea este dependentă de context
Există mai multe domenii disponibile pe piață, cum ar fi Banca, Asigurările, Medicale, Călătorii, Publicitate etc. și fiecare domeniu are mai multe aplicații. De asemenea, pentru fiecare domeniu, aplicațiile lor au cerințe diferite, funcții, scopuri diferite de testare, risc, tehnici etc.
Diferitele domenii sunt testate diferit, astfel testarea se bazează pur pe contextul domeniului sau aplicației.
De exemplu ,testarea unei aplicații bancare este diferită de testarea oricărei aplicații de comerț electronic sau publicitate. Riscul asociat fiecărui tip de aplicație este diferit, prin urmare nu este eficient să se utilizeze aceeași metodă, tehnică și tip de testare pentru a testa toate tipurile de aplicații.
# 5) Clusterarea defectelor
În timpul testării, se poate întâmpla ca majoritatea defectelor găsite să fie legate de un număr mic de module. Ar putea exista mai multe motive pentru acest lucru, cum ar fi modulele pot fi complexe, codarea legată de astfel de module poate fi complicată etc.
Acesta este principiul Pareto al testării software unde 80% din probleme se găsesc în 20% din module. Vom afla mai multe despre gruparea defectelor și principiul Pareto mai târziu în acest articol.
# 6) Paradoxul pesticidelor
Principiul paradoxului pesticidelor spune că, dacă același set de cazuri de testare sunt executate din nou și din nou pe parcursul perioadei de timp, atunci aceste seturi de teste nu sunt suficient de capabile să identifice noi defecte ale sistemului.
Pentru a depăși acest „paradox al pesticidelor”, setul de cazuri de testare trebuie revizuit și revizuit în mod regulat. Dacă este necesar, se poate adăuga un nou set de cazuri de testare și cazurile de testare existente pot fi șterse dacă nu mai pot găsi alte defecte din sistem.
# 7) Absența erorii
Dacă software-ul este testat complet și dacă nu se găsesc defecte înainte de lansare, atunci putem spune că software-ul este 99% fără defecte. Dar dacă acest software este testat împotriva unor cerințe greșite? În astfel de cazuri, chiar găsirea defectelor și remedierea lor la timp nu ar ajuta, deoarece testarea se efectuează pe cerințe greșite care nu sunt conform nevoilor utilizatorului final.
De exemplu, să presupunem că aplicația este legată de un site de comerț electronic și de cerințele referitoare la funcționalitatea „Coș de cumpărături sau coș de cumpărături”, care este interpretată și testată greșit. Aici, chiar și găsirea mai multor defecte nu ajută la mutarea aplicației în faza următoare sau în mediul de producție.
Acestea sunt cele șapte principii ale testării software.
Acum să explorăm Gruparea defectelor, principiul Pareto și paradoxul pesticidelor în detaliu .
Clusterarea defectelor
În timpul testării oricărui software, testerii întâmpină în cea mai mare parte o situație în care majoritatea defectelor găsite sunt legate de anumite funcționalități specifice, iar restul funcționalităților vor avea un număr mai mic de defecte.
Clusterizarea defectelor înseamnă un număr mic de module care conțin majoritatea defectelor. Practic, defectele nu sunt distribuite uniform pe întreaga aplicație, mai degrabă defectele sunt concentrate sau centralizate în două sau trei funcționalități.
Uneori, este posibil datorită complexității aplicației, codificarea poate fi complexă sau dificilă, un dezvoltator poate comite o greșeală care ar putea afecta doar o anumită funcționalitate sau modul.
Clusterarea defectelor se bazează pe „ Principiul Pareto ”Care este, de asemenea, cunoscut sub numele de Regula 80-20 . Înseamnă că 80% din defectele găsite se datorează 20% din modulele din aplicație. Conceptul de principiu Pareto a fost inițial definit de un economist italian - Vilfrodo Pareto .
Dacă testerii analizează 100 de defecte, atunci nu va fi clar dacă există vreun sens subiacent împotriva acelor 100 de defecte. Dar dacă aceste 100 de defecte sunt clasificate pe anumite criterii specifice, atunci este posibil ca testerii să înțeleagă că un număr mare de defecte aparțin doar unor module specifice.
De exemplu ,să luăm în considerare imaginea de mai jos, care este testată pentru una dintre aplicațiile bancare și arată că majoritatea defectelor sunt legate de funcționalitatea „Overdraft”. Restul funcționalităților, cum ar fi Rezumatul contului, Transferul de fonduri, Instrucțiunile permanente etc., au un număr limitat de defecte.
(imagine sursă )
Imaginea de mai sus afirmă că există 18 defecte în jurul funcționalității Overdraft din totalul de 32 de defecte, ceea ce înseamnă că 60% din defecte se găsesc în modulul „Overdraft”.
Prin urmare, testerii se concentrează în cea mai mare parte pe această zonă în timpul execuției pentru a găsi din ce în ce mai multe defecte. Se recomandă ca testerii să se concentreze similar și pe celelalte module în timpul testării.
Când se testează același cod sau modul, din nou și din nou, utilizând un set de cazuri de testare decât în timpul iterațiilor inițiale, atunci numărul defectelor este mare, cu toate acestea, după o anumită iterație, numărul defectelor va fi redus semnificativ. Gruparea defectelor indică faptul că zona predispusă la defecte trebuie testată temeinic în timpul testării de regresie.
Paradoxul pesticidelor
Când se constată că unul dintre module are mai multe defecte, testerii depun eforturi suplimentare pentru a testa acel modul.
După câteva iterații de testare, calitatea codului se îmbunătățește și numărul defectelor începe să scadă deoarece majoritatea defectelor sunt remediate de echipa de dezvoltare, deoarece dezvoltatorii sunt, de asemenea, precauți în timp ce codifică un anumit modul în care testerii au găsit mai multe defecte.
Prin urmare, la un moment dat, majoritatea defectelor sunt descoperite și remediate astfel încât să nu se găsească defecte noi în acel modul.
Cu toate acestea, uneori se poate întâmpla ca, în timp ce să fiți extrem de precaut în timpul codificării pe un anumit modul (aici, în cazul nostru, „ Descoperit ”), Dezvoltatorul poate neglija celelalte module pentru a-l codifica corect sau modificările făcute în acel modul particular ar putea avea un impact negativ asupra celorlalte funcționalități, cum ar fi Rezumatul contului, Transferul de fonduri și Instrucțiunile permanente.
Când testerii folosesc același set de cazuri de testare pentru a executa modulul în care se găsesc cele mai multe defecte (modulul Overdraft), atunci, după remedierea acelor defecte de către dezvoltatori, aceste cazuri de testare nu sunt prea eficiente pentru a găsi noi defecte. Ca flux de la capăt la cap a Overdraft, modulul este testat amănunțit și dezvoltatorii au scris cu precauție codul pentru modulul respectiv.
Este necesar să revizuiți și să actualizați aceste cazuri de testare. De asemenea, este o idee bună să adăugați noi cazuri de testare, astfel încât să poată fi găsite defecte noi și mai multe în diferite domenii ale software-ului sau aplicației.
Metode preventive ale paradoxului pesticidelor
Există două opțiuni prin care putem preveni paradoxul pesticidelor, așa cum se arată mai jos:
la) Scrieți un nou set de cazuri de testare care se vor concentra pe diferite zone sau module (altul decât modulul anterior predispus la defecte - Exemplu: „Overdraft”) al software-ului.
b) Pregătiți noi cazuri de testare și adăugați-le la cazurile de testare existente.
În ' metoda A ”, Testerii pot găsi mai multe defecte în celelalte module în care nu au fost focalizați în timpul testării anterioare sau dezvoltatorii nu au fost foarte precauți în timpul codării.
În exemplul nostru de mai sus, testerii pot găsi mai multe defecte în modulul Rezumatul contului, Transferul de fonduri sau Instrucțiunile permanente folosind noul set de cazuri de testare.
Dar se poate întâmpla ca testerii să neglijeze modulul anterior ( Exemplu: „Overdraft”) unde majoritatea defectelor au fost găsite în iterația anterioară și acest lucru ar putea fi un risc deoarece acest modul (Overdraft) ar fi putut fi injectat cu noile defecte după codificarea celorlalte module.
În ' metoda B ”, Sunt pregătite noi cazuri de testare, astfel încât noi defecte potențiale să poată fi găsite în restul modulelor.
Aici, în exemplul nostru, cazurile de testare create recent vor putea ajuta la identificarea defectelor în module precum Rezumatul contului, Transferul de fonduri și Instrucțiunile permanente. Cu toate acestea, testerii nu pot ignora modulele predispuse la defecte ( Exemplu: „Overdraft”) deoarece aceste noi cazuri de testare sunt combinate cu cazurile de testare existente.
Cazurile de testare existente s-au concentrat mai mult pe modulul „Overdraft”, iar noile cazuri de testare s-au concentrat pe celelalte module. Prin urmare, toate seturile de cazuri de testare sunt executate cel puțin o dată, chiar dacă o modificare a codului are loc pe orice modul. Acest lucru va asigura că regresia corectă este executată și defectul poate fi identificat datorită acestei modificări de cod.
Folosind a doua abordare, numărul total de cazuri de testare crește semnificativ și are ca rezultat mai multe eforturi și timp necesar pentru execuție. Acest lucru va avea în mod evident impact asupra calendarului proiectului și, cel mai important, asupra bugetului proiectului.
Prin urmare, pentru a depăși această problemă, cazurile de testare redundante pot fi revizuite și apoi eliminate. Există multe cazuri de testare care devin inutile după adăugarea de noi cazuri de testare și modificarea cazurilor de testare existente.
Este necesar să verificați ce cazuri de testare nu au reușit pentru a identifica defectele din ultimele 5 iterații (să presupunem 5 iterații) și care cazuri de testare nu sunt prea importante. Poate fi, de asemenea, cazul în care fluxul unic acoperit în câteva cazuri de testare poate fi acoperit într-un alt caz de testare cap la cap și acele cazuri de testare cu flux unic pot fi eliminate.
La rândul său, aceasta va reduce numărul total de cazuri de testare.
De exemplu ,avem 50 de cazuri de testare pentru a acoperi un anumit modul și am văzut că din aceste 50 de cazuri de testare 20 de cazuri de testare nu au reușit să detecteze un nou defect în ultimele câteva iterații de testare (să presupunem 5 iterații). Așadar, aceste 20 de cazuri de testare trebuie revizuite în detaliu și trebuie să verificăm cât de importante sunt aceste cazuri de testare și se poate lua o decizie în consecință cu privire la menținerea celor 20 de cazuri de testare sau eliminarea acestora.
Înainte de a elimina orice caz de testare, verificați dacă fluxul de funcționalitate acoperit în aceste cazuri de testare este acoperit într-un alt caz de testare. Acest proces trebuie urmărit pe toate modulele, astfel încât numărul total de cazuri de testare să fie redus semnificativ. Acest lucru va asigura că numărul total al cazurilor de testare este redus, dar există încă o acoperire a cerințelor de 100%.
Înseamnă că toate cazurile de testare rămase acoperă toate cerințele comerciale, prin urmare nu există compromisuri privind calitatea.
Concluzie
Testarea software-ului este un pas esențial în SDLC, deoarece verifică dacă software-ul funcționează în funcție de necesitățile utilizatorului final sau nu.
Testarea identifică cât mai multe defecte posibil. Prin urmare, pentru a efectua testarea în mod eficient și eficient, toată lumea ar trebui să fie conștientă și să înțeleagă în mod clar cele șapte principii ale testării software și sunt cunoscuți drept pilonii testării.
Majoritatea testerilor au implementat și experimentat aceste principii în timpul testării propriu-zise.
cum se creează o listă de obiecte în java
În general, termenul de principiu înseamnă regulile sau legile care trebuie respectate. Prin urmare, toată lumea din industria de testare a software-ului trebuie să respecte aceste șapte principii și, dacă cineva ignoră oricare dintre aceste principii, ar putea costa enorm proiectul.
Lectura placuta!!
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Testare software Job asistent QA
- Curs de testare software: La ce institut de testare software ar trebui să mă alătur?
- Alegerea Testelor software ca carieră
- Testarea software-ului Conținut tehnic Scriitor Freelancer Job
- Ce este tehnica de testare bazată pe defecte?
- Câteva întrebări interesante despre testarea software-ului
- Feedback și recenzii despre cursul de testare software