Meniu

Testare ad-hoc: Cum să găsiți defecte fără un proces de testare formal

ad hoc testing how find defects without formal testing process

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Termenul ad-hoc implică lipsa de structură sau ceva care nu este metodic. Când vorbești despre testare ad-hoc , înseamnă că este o formă a cutie neagră sau testarea comportamentală efectuată fără a avea loc un proces formal.

Procesul formal de aici înseamnă să aveți documentație, cum ar fi documentele de cerință, planurile de testare, cazurile de testare și planificarea corectă a testelor în ceea ce privește programul și ordinea testelor efectuate. De asemenea, orice acțiune efectuată în timpul testării nu este de obicei documentată.

Testarea ad-hoc

Acest lucru se face în principal cu scopul de a încerca să descoperi defecte sau defecte care nu pot fi capturate prin procese tradiționale sau formale urmate în timpul ciclului de testare.

Așa cum s-a înțeles deja, esența acestui test constă în a nu avea un mod formal sau structurat de testare. Când se efectuează un astfel de tip de tehnici de testare aleatorie, este evident că testerii efectuează acest lucru fără să aibă în vedere niciun caz de utilizare special cu scopul de a sparge sistemul.

Prin urmare, este cu siguranță și mai evident că o astfel de metodologie de testare intuitivă sau creativă necesită testerul să fie extrem de calificat, capabil și să aibă cunoștințe aprofundate despre sistem. Testarea ad-hoc asigură că testarea efectuată este completă și este deosebit de utilă pentru a determina eficacitatea cupei de testare.

Lectură recomandată=> Testarea exploratorie - Cum să gândiți dincolo de limitele de testare tradiționale?

Ce veți învăța:

Să începem cu un exemplu de testare ad-hoc

Iată un exemplu despre modul în care putem efectua aceste testări când vine vorba de UI Wizard.

Să presupunem că trebuie să creați un plan sau un șablon pentru un anumit tip de sarcină care trebuie efectuată folosind acest expert UI. Vrăjitorul este o serie de panouri care au date de utilizator, cum ar fi numele, descrierea etc.

Pe măsură ce expertul progresează: spuneți pe unul dintre panouri, datele utilizatorului trebuie să fie introduse, ceea ce implică expertul UI pentru a arunca o casetă pop-up contextuală care adaugă datele asociate pentru a finaliza expertul și a implementa / activa expertul.

Pentru a testa acest tester, el efectuează testele sale regulate, cum ar fi:

ce dispozitiv efectuează traducerea adresei de rețea (nat)?
  • Completați expertul cu succes cu toate datele valide și creați planul.
  • Anulați expertul la jumătatea drumului.
  • Editați un plan creat prin expert.
  • Ștergeți planul creat și vedeți că nu există reziduuri din acesta.
  • Introduceți o valoare negativă în expert și vedeți că sunt afișate mesajele de eroare corespunzătoare.

Acum, pentru exemplul de mai sus iată câteva cazuri de testare pentru testele ad-hoc care ar putea fi efectuat pentru a descoperi cât mai multe defecte posibil:

  • În timp ce încercați să adăugați date negative, adăugați anumite caractere speciale care nu sunt restricționate pentru a vedea dacă sunt tratate corect. De exemplu, uneori, vrăjitorii nu restricționează {sau (paranteze, dar în anumite situații, acest lucru poate intra în conflict cu codul bazat pe limba în care este scris și poate provoca un comportament foarte fiabil.
  • Un alt test este specific în ceea ce privește ferestrele pop-up. Un utilizator poate face ca pop-up-ul să se lanseze și apoi să încerce să apese butonul backspace de pe tastatură. De multe ori am observat că, făcând acest lucru, vrăjitorul de fundal dispare complet și se pierd toate datele utilizatorului introduse până la momentul lansării ferestrei pop-up!

Caracteristicile testării ad-hoc:

Dacă observați scenariile de mai sus, veți vedea caracteristici foarte distincte ale acestui tip de testare.

Sunt:

  • Ele sunt întotdeauna în conformitate cu obiectivul testului. Cu toate acestea, sunt anumite teste drastice efectuate cu intenția de a sparge sistemul.
  • Testatorul trebuie să aibă cunoștințe complete și conștientizare despre sistemul testat. Rezultatul acestei testări găsește erori care încearcă să evidențieze lacunele procesului de testare.
  • De asemenea, analizând cele două teste de mai sus, reacția naturală la aceasta ar fi aceea - acest tip de test poate fi efectuat o singură dată, deoarece nu este fezabil pentru un re-test, cu excepția cazului în care există un defect asociat.

Când facem teste ad-hoc?

O întrebare de un milion de dolari într-adevăr!

Cele mai multe dintre echipele de testare din timp sunt întotdeauna împovărate cu prea multe funcții pentru a le testa într-un termen limitat. În acest interval de timp limitat, există o mulțime de activități de testare care sunt derivate din procesul formal care trebuie, de asemenea, să se finalizeze. În astfel de situații, testarea ad-hoc este ușoară.

Cu toate acestea, din experiența mea, o rundă de testare ad-hoc poate face minuni pentru calitatea produsului și poate ridica multe întrebări de proiectare.

Întrucât testarea ad-hoc este mai degrabă o tehnică de testare „wild-child” care nu trebuie structurată, recomandarea generală este că trebuie efectuată după ce se execută bucketul de test curent. Un alt punct de vedere este că acest lucru se poate face atunci când testarea detaliată nu poate fi efectuată din cauza unui timp mai redus.

În opinia mea, aș spune asta testarea ad-hoc se poate face aproape oricând - la început, spre mijloc și spre sfârșit! Pur și simplu își găsește locul la un moment dat. Cu toate acestea, atunci când testarea ad-hoc trebuie făcută pentru a scoate valoarea maximă este cel mai bine judecată de un tester cu experiență care are cunoștințe aprofundate despre sistemul testat.

Când să nu execute?

Dacă întrebarea anterioară valora un milion de dolari, aceasta ar trebui să merite un miliard!

Deși am stabilit cât de eficace și fructuoase pot fi testele ad-hoc, în calitate de tester calificat și capabil, trebuie să descifrăm și atunci când să nu investim în acest tip de testare. Deși este la discreția testerului, iată-le câteva recomandări / exemple când s-ar putea să nu fie necesar.

  • Evitați această testare atunci când există un caz de testare pentru care există un defect. Într-o astfel de situație este necesar să se documenteze punctul de eșec al cazului de testare și apoi să verifice / re-testeze defectul atunci când este remediat. Prin urmare, nu va fi aplicabil aici.
  • De asemenea, pot exista anumite scenarii în care clienții sau clienții pot fi invitați testați versiunea beta a software-ului . În astfel de cazuri, nu trebuie efectuată această testare.
  • Un alt scenariu este atunci când există un ecran UI foarte simplu care este adăugat. Testarea tradițională pozitivă și negativă ar trebui să fie suficientă aici pentru a evidenția defectele maxime.

Tipuri de testare ad-hoc

Testarea ad-hoc poate fi clasificată în trei categorii de mai jos:

# 1) Testarea prietenilor

În această formă de testare, va exista un membru de testare și un membru de dezvoltare care va fi ales să lucreze la același modul. Chiar după dezvoltatorul finalizează testarea unității , testerul și dezvoltatorul stau împreună și lucrați la modul. Acest tip de testare permite vizualizarea caracteristicii într-un domeniu mai larg pentru ambele părți.

Dezvoltatorul va obține o perspectivă asupra tuturor diferitelor teste pe care testerul le efectuează, iar testerul va obține o perspectivă asupra modului în care este proiectarea inerentă, care îl va ajuta să evite proiectarea scenariilor nevalide, prevenind astfel defectele nevalide. Îl va ajuta pe unul să gândească ca pe celălalt.

# 2) Testare pereche

În acest test, doi testeri lucrează împreună pe un modul cu aceeași configurare de test partajată între ei. Ideea din spatele acestei forme de testare a celor doi testeri face o idee despre idei și metode pentru a avea o serie de defecte. Ambele pot împărtăși activitatea de testare și pot face documentația necesară a tuturor observațiilor făcute.

# 3) Testarea maimuțelor

Această testare se efectuează în principal la nivelul testării unitare. Testerul analizează datele sau testele într-un mod complet aleatoriu pentru a se asigura că sistemul este capabil să reziste la orice blocare. Aceste teste pot fi clasificate în continuare în două categorii:

emisiuni anime gratuite pentru vizionare online

Beneficii de testare ad-hoc

Testarea garantează testerului cu multă putere să fie la fel de creativ cât este necesar.

Acest lucru crește calitatea și eficiența testării, după cum urmează:

  • Cel mai mare avantaj care iese în evidență este că un tester poate găsi numărul de defecte decât în ​​testarea tradițională datorită diferitelor metode inovatoare pe care le pot aplica pentru a testa software-ul.
  • Această formă de testare poate fi aplicată oriunde în SDLC; nu este limitat doar la echipa de testare. Dezvoltatorii pot efectua, de asemenea, această testare, ceea ce i-ar ajuta să codeze mai bine și, de asemenea, să prezică ce probleme ar putea apărea.
  • Poate fi cuplat cu un alt test pentru a obține cele mai bune rezultate, care uneori pot reduce timpul necesar testării obișnuite. Acest lucru ar permite generarea unor cazuri de testare de calitate mai bună și o calitate mai bună a produsului pe ansamblu.
  • Nu impune nicio documentație care să împiedice sarcina suplimentară asupra testerului. Un tester se poate concentra pe înțelegerea efectivă a arhitecturii subiacente.
  • În cazurile în care nu există prea mult timp disponibil pentru testare, acest lucru se poate dovedi foarte valoros în ceea ce privește acoperirea și calitatea testului.

Dezavantaje de testare ad-hoc

Testarea ad-hoc are, de asemenea, câteva dezavantaje. Să aruncăm o privire la unele dintre dezavantaje care se pronunță:

Deoarece nu este foarte organizat și nu există nicio documentație obligatorie, cea mai evidentă problemă este că testerul trebuie să-și amintească și să rețină toate detaliile scenariilor ad-hoc din memorie. Acest lucru poate fi și mai dificil, în special în scenarii în care există o mulțime de interacțiune între diferite componente.

  • Urmărit de la primul punct, acest lucru ar avea ca rezultat, de asemenea, imposibilitatea de a recrea defecte în încercările ulterioare dacă i se cer informații.
  • O altă întrebare foarte importantă pe care aceasta o scoate la iveală este responsabilitatea efortului. Deoarece acest lucru nu este planificat / structurat, nu există nicio modalitate de a explica timpul și efortul investit în acest tip de testare.
  • Testarea ad-hoc trebuie să fie efectuată doar de un tester foarte informat și calificat din echipă, deoarece solicită să fie proactiv și intuitiv în ceea ce privește prevederea potențialelor zone defectate.

Cele mai bune practici pentru a face acest test mai eficient

Am discutat pe larg punctele forte și punctele slabe asociate acestui test.

În mod ideal, testarea ad-hoc ar trebui să-și găsească locul în SDLC, cu toate acestea, dacă nu este abordată în mod adecvat, se poate dovedi costisitoare și o pierdere de timp valoros de testare. Deci, prezentate mai jos sunt câteva indicații pentru a face testarea ad-hoc eficientă:

# 1) Identificați zonele predispuse la defecte:

Când aveți o reținere bună asupra testării unui anumit software, veți fi de acord că vor exista anumite caracteristici care sunt mai predispuse la erori decât celelalte. Dacă sunteți nou în sistem, continuați și verificați caracteristicile defectelor v / s deschise împotriva acestora.

Numărul de defecte într-o anumită caracteristică vă va arăta că este sensibil și că ar trebui să alegeți cu exactitate acea zonă pentru a efectua teste ad-hoc. Acest lucru se dovedește a fi un mod foarte eficient de expunere a unor defecte grave.

# 2) Expertiza de construire:

Fără îndoială, un tester care are mai multă experiență este mai intuitiv și poate ghici unde ar putea fi erorile, în comparație cu cineva care nu are prea multă experiență. Aș spune, cu experiență sau nu, depinde de individ să facă pasul și să-și construiască expertiza în sistemul testat.

Da, testerii cu experiență au un avantaj, pe măsură ce abilitățile lor acumulate de-a lungul anilor vin la îndemână, dar noii testeri ar trebui să le folosească ca o platformă pentru a obține cât mai multe cunoștințe posibil pentru a proiecta scenarii ad-hoc mai bune.

# 3) Creați categorii de testare:

După ce știți lista funcțiilor care trebuie testate, rezervați câteva minute pentru a decide cum ați clasifica aceste caracteristici și testați. De exemplu, ar trebui să decideți să testați caracteristicile care sunt cele mai vizibile și cele mai frecvent utilizate de utilizator înainte de orice, deoarece acestea ar părea esențiale pentru succesul software-ului.

Apoi le-ați putea clasifica funcționalitatea / prioritatea și le puteți testa segment cu segment.

Un alt exemplu în care acest lucru este deosebit de important este dacă există integrare între componente sau module. În aceste cazuri, pot apărea o mulțime de anomalii. Utilizarea clasificării ar ajuta la atingerea acestui tip de test cel puțin o dată sau de două ori.

# 4) Aveți un plan dur:

Da, da, acest punct vă poate deruta puțin, deoarece am descris testarea ad-hoc drept testare care nu ar trebui să aibă planificare sau documentare. Ideea aici este să rămânem la esența testării ad-hoc, dar totuși, aveți câteva indicații aspre notate cu privire la modul în care intenționați să testați.

Un exemplu foarte simplu este că uneori este posibil să nu vă puteți aminti toate testele pe care intenționați să le efectuați. Așadar, notarea lor ar asigura că nu pierdeți nimic.

# 5) Instrumente:

Să luăm un exemplu cu care ne confruntăm cu toții. De multe ori, dacă observați, testarea funcționalității în sine are succes, fără nicio discrepanță raportată în comportamentul său. Cu toate acestea, jurnalele din culise ar putea raporta unele excepții văzute, care ar putea fi ratate de testeri, deoarece nu împiedică în niciun fel obiectivul testului.

Acestea ar putea avea chiar o severitate ridicată. Prin urmare, este foarte important pentru noi să învățăm și instrumente care vă vor ajuta să identificați imediat acest lucru.

# 6) Document pentru mai multe defecte:

Din nou, înțeleg că acest lucru poate ridica din nou unele sprâncene. Documentația nu trebuie să fie detaliată, ci doar o mică notă pentru referința proprie a tuturor diferitelor scenarii acoperite, abaterea în pași implicați și înregistrați aceste defecte pentru categoria particulară de funcții de testare.

Acest lucru vă va ajuta să îmbunătățiți bucket-ul de testare, de asemenea, prin care puteți decide cum să improvizați cazurile de test existente sau să adăugați mai multe, dacă este necesar.

Concluzie

Am discutat în detaliu despre tehnicile de testare ad-hoc - punctele forte, punctele slabe, situațiile în care ar fi și nu ar fi benefic.

Aceasta este o tehnică de testare care garantează satisfacerea și satisfacerea la maximum a creativității testerului. În întregul meu test de carieră , Câștig cea mai mare satisfacție din testarea ad-hoc, deoarece nu există nicio limită pentru a fi inovator și ajungeți doar să aveți mai multă cunoștință.

Acestea fiind spuse, principalul lucru care trebuie luat înapoi de la toate informațiile de mai sus ar fi să stabiliți cum să atingeți punctele forte de testare ad hoc și faceți-i să adauge valoare procesului general de testare și calității produsului.

Despre autor: Acesta este un articol invitat de Sneha Nadig. Lucrează ca șef de testare cu peste 7 ani de experiență în proiecte de testare manuală și de automatizare.

Efectuați teste ad-hoc pentru proiectul dvs.? Care sunt sugestiile dvs. pentru ca testele ad-hoc să aibă succes?

Lectură recomandată

^