Testarea ad-hoc este un tip de testare software pe care dezvoltatorii și companiile de software îl implementează atunci când verifică iterația curentă a software-ului. Această formă de testare oferă un nivel mai mare de înțelegere a programului, localizând probleme pe care testele convenționale nu le pot evidenția.
Este extrem de important ca echipele de testare să aibă o înțelegere completă a procesului de testare ad-hoc, astfel încât să știe cum să ocolească provocările acestuia și să se asigure că echipa poate implementa cu succes această tehnică.
Cunoașterea exactă a modului în care funcționează testarea ad-hoc și a instrumentelor care pot facilita punerea în aplicare a acesteia permite unei întreprinderi să își îmbunătățească în mod continuu propriile proceduri de asigurare a calității. Procesul de testare formală urmează reguli foarte specifice, ceea ce ar putea duce la faptul că echipa ar putea omite anumite erori – verificările ad-hoc pot evita aceste puncte moarte și pot testa rapid fiecare caracteristică software.
În acest articol, vom examina îndeaproape testarea ad-hoc și modul în care o puteți utiliza în avantajul dumneavoastră atunci când dezvoltați un produs software.
Ad-Hoc Testing Ad-Hoc Adică: Ce este testarea ad-hoc?
Testarea ad-hoc este un proces de asigurare a calității care evită regulile și documentația formală – ajutându-i pe testeri să găsească erori în aplicația lor pe care abordările convenționale nu le pot identifica. Acest lucru necesită, de obicei, o cunoaștere completă a software-ului înainte de începerea testării, inclusiv o înțelegere a mecanismelor interne ale programului. Aceste verificări ad-hoc au scopul de a întrerupe aplicația în moduri care să reflecte datele introduse de utilizator, ținând cont de diverse situații potențiale, astfel încât dezvoltatorii să poată remedia orice problemă existentă.
Lipsa documentației este esențială pentru această tehnică, care nu include nicio listă de verificare sau cazuri de testare care să ghideze testerii prin caracteristicile unei aplicații. Testarea ad-hoc se referă în întregime la testarea software-ului în orice mod pe care o echipă decide că este eficient în acel moment specific. Acest lucru ar putea lua în considerare testele formale preexistente, dar ar putea, de asemenea, să implice pur și simplu efectuarea a cât mai multe teste posibile în timpul (probabil limitat) alocat pentru această tehnică.
1. Când și de ce trebuie să faceți teste ad-hoc în testarea software?
Principalul motiv pentru care companiile efectuează teste ad-hoc este capacitatea de a descoperi erori pe care abordările tradiționale nu le pot găsi. Acest lucru ar putea fi din mai multe motive, cum ar fi cazurile de testare convenționale care urmează un proces standardizat care nu poate ține cont de particularitățile unei aplicații.
Fiecare tip de testare poate oferi noi perspective și abordări interesante în ceea ce privește asigurarea calității – acest lucru arată, de asemenea, problemele legate de strategia obișnuită de testare. De exemplu, dacă testarea ad-hoc poate identifica o problemă pe care cazurile de testare ale echipei nu o abordează, acest lucru sugerează că ar putea beneficia de o recalibrare a metodologiei de testare.
Testatorii pot efectua verificări ad-hoc în orice moment al procesului de testare. De obicei, acest lucru servește ca o completare a asigurării tradiționale (și mai formale) a calității și, în acest sens, verificatorii pot efectua inspecții ad-hoc în timp ce colegii lor efectuează examinări mai formale. Cu toate acestea, este posibil ca aceștia să prefere să păstreze verificările ad-hoc până după procesul de testare formală, ca o măsură de monitorizare care vizează în mod specific eventualele puncte moarte.
Testarea ad-hoc ar putea fi utilă, de asemenea, atunci când timpul este deosebit de limitat din cauza lipsei de documentație – momentul potrivit depinde de companie și de abordarea sa preferată.
2. Când nu este nevoie să faceți teste ad-hoc
În cazul în care nu există timp suficient pentru a efectua atât teste ad-hoc, cât și teste formale, este important ca echipa să acorde prioritate celor din urmă, deoarece astfel se asigură o acoperire substanțială a testelor – chiar dacă mai există unele lacune.
În cazul în care testele formale ale echipei descoperă erori care trebuie reparate, este, în general, mai bine să așteptați până când dezvoltatorii finalizează modificările necesare pentru a efectua verificări ad-hoc. În caz contrar, rezultatele pe care le furnizează ar putea deveni în curând depășite, mai ales dacă testele se referă la o componentă care se confruntă deja cu erori.
În plus, înainte de etapa de testare beta, trebuie să aibă loc o testare ad-hoc.
3. Cine este implicat în testarea ad-hoc?
Există mai multe roluri cheie implicate în procesul de testare Ad-Hoc, printre care:
– Testatorii de software sunt principalii membri ai echipei care efectuează verificări ad-hoc. În cazul în care se aplică testarea în echipă sau în perechi, atunci mai mulți dintre acești testeri vor lucra împreună la aceleași componente.
– Dezvoltatorii pot utiliza în mod independent aceste verificări înainte de etapa formală de asigurare a calității pentru a-și inspecta rapid propriul software, deși acest lucru este mai puțin profund decât testarea ad-hoc dedicată.
– Liderii de echipă sau de departament autorizează strategia generală de testare – ajutându-i pe testeri să determine când să înceapă testarea ad-hoc și cum să o efectueze fără a perturba alte verificări.
Beneficiile testării ad-hoc
Avantajele testării ad-hoc în testarea software includ:
1. Rezoluții rapide
Deoarece aceste teste nu implică o documentare frecventă înainte, în timpul sau după verificări, echipele pot identifica problemele mult mai rapid. Această simplitate oferă o libertate extraordinară tesatorilor.
De exemplu, dacă testează o componentă și nu poate identifica nicio eroare, echipa poate trece pur și simplu la următorul test fără să noteze acest lucru într-un document.
2. Completează alte tipuri de testare
Nicio strategie de testare nu este perfectă, iar o acoperire de 100% este de obicei imposibil de realizat – chiar și cu un program cuprinzător. Întotdeauna vor exista lacune în testarea convențională, astfel încât este important ca întreprinderile să integreze mai multe abordări.
Testarea ad-hoc are ca scop specific identificarea problemelor pe care testarea formală nu le poate acoperi – garantând o acoperire mai largă a testului global.
3. Execuție flexibilă
Testarea ad-hoc poate avea loc în orice moment al procesului de asigurare a calității înainte de testarea beta, permițând companiilor și echipelor să decidă când este cel mai bine să efectueze aceste verificări. Aceștia pot alege să efectueze teste ad-hoc în tandem cu testele convenționale sau pot aștepta până după aceea – în orice caz, echipa beneficiază de alegerile pe care le are la dispoziție.
4. O mai mare colaborare
Dezvoltatorii sunt mai implicați în acest proces decât în multe alte forme de testare – mai ales dacă întreprinderea folosește testele de tip „buddy și pair testing”.
Ca urmare, dezvoltatorii au o mai bună cunoaștere a propriilor aplicații și ar putea fi capabili să rezolve erorile la un standard mai ridicat. Acest lucru ajută la îmbunătățirea și mai mult a calității generale a software-ului.
5. Perspective diverse
Testarea ad-hoc poate prezenta aplicația din unghiuri noi, ajutându-i pe testeri să se implice în aceste caracteristici în moduri noi. Perspectivele suplimentare sunt esențiale pe tot parcursul testării, deoarece verificările formale prezintă adesea cel puțin mici lacune.
Dacă testerii ad-hoc folosesc software-ul cu intenția specifică de a-l sparge, vor putea să identifice mai ușor limitele programului.
Provocările testării ad-hoc
Procesul de testare ad-hoc are, de asemenea, mai multe provocări, cum ar fi:
1. Dificultatea de raportare
Lipsa de documentație face ca testarea ad-hoc să fie mult mai rapidă, dar poate face dificilă raportarea pentru orice altceva decât o problemă majoră.
De exemplu, un control efectuat anterior ar putea deveni mai relevant la o dată ulterioară, deși inițial nu a condus la rezultate semnificative. În lipsa unei documentații complete, este posibil ca echipa să nu fie în măsură să explice aceste teste.
2. Mai puțin repetabil
În mod similar, este posibil ca cei care efectuează testele să nu fie pe deplin conștienți de condițiile exacte necesare pentru a provoca reacțiile pe care le observă. De exemplu, este posibil ca o verificare ad-hoc care returnează o eroare să nu conțină suficiente informații pentru ca echipa să ia măsuri. S-ar putea să nu știe cum să repete acest test și să obțină același rezultat.
3. Necesită experiență în domeniul software
Deoarece viteza este esențială în cadrul testelor ad-hoc și, de obicei, implică încercarea de a sparge aplicația, este important ca acești testeri să aibă o înțelegere profundă a acestui program.
Cunoașterea modului în care funcționează le permite testerilor să spargă și să manipuleze software-ul în mai multe moduri, dar acest lucru ar putea crește semnificativ cerințele de calificare pentru testarea ad-hoc.
4. Responsabilitate limitată
O lipsă de documentație poate cauza mai multe probleme decât o raportare slabă; de asemenea, poate prelungi involuntar procesul de testare, afectând utilitatea testelor ad-hoc individuale rapide.
Testatorii se pot strădui să își urmărească progresul fără o documentație suficientă pe parcursul fiecărei etape. Acest lucru poate duce chiar la repetarea unei verificări pe care alți testeri au efectuat-o deja.
5. Este posibil să nu reflecte experiența utilizatorului
Scopul practic al fiecărui tip de testare este de a lua în considerare erorile care afectează într-un fel sau altul utilizatorii finali. Testarea ad-hoc se bazează în primul rând pe un tester experimentat care încearcă să emuleze un utilizator neexperimentat, iar acest lucru ar trebui să fie consecvent la fiecare verificare, până la și inclusiv la încercările acestuia de a sparge aplicația.
Caracteristicile testelor ad-hoc
Principalele caracteristici ale testelor ad-hoc de succes includ:
1. Investigație
Principala prioritate a testării ad-hoc este identificarea erorilor din aplicație prin tehnici pe care verificările convenționale nu le iau în considerare. Examinările ad-hoc cercetează acest software cu scopul expres de a găsi lacune în procedura de testare a echipei, inclusiv în ceea ce privește acoperirea cazurilor de testare.
2. Nerestructurat
Verificările ad-hoc nu au, de obicei, un plan prestabilit, în afară de efectuarea cât mai multor teste posibile în afara limitelor tipice ale asigurării formale a calității. În mod obișnuit, pentru comoditate, verificările vor fi grupate pe componente, dar nici măcar acest lucru nu este necesar – aceștia pot chiar să conceapă verificările în timp ce le efectuează.
3. Orientată spre experiență
Testatorii ad-hoc își folosesc experiența lor preexistentă în domeniul software pentru a evalua ce teste ar aduce cele mai multe beneficii și pentru a aborda punctele moarte obișnuite ale testelor formale.
Cu toate că procesul de testare este încă complet nestructurat, testerii își aplică cunoștințele dobândite în urma verificărilor ad-hoc anterioare, printre altele, atunci când își decid strategia.
4. Amplu domeniu de aplicare
Nu există ghiduri exacte cu privire la verificările pe care echipa ar trebui să le efectueze în timpul testelor ad-hoc, dar acestea acoperă, de obicei, o serie de componente – eventual cu un accent mai mare pe aspectele mai sensibile ale aplicației. Acest lucru îi ajută pe testeri să garanteze că examinările lor sunt capabile să completeze pe deplin testele formale.
Ce testăm în cadrul testelor ad-hoc?
Echipele de asigurare a calității testează, de obicei, următoarele aspecte în timpul testării ad-hoc:
1. Calitatea software-ului
Aceste verificări au ca scop identificarea erorilor din aplicație pe care testele convenționale nu le pot descoperi; acest lucru înseamnă că procesul testează în principal sănătatea generală a aplicației.
Cu cât sunt mai multe erori pe care testele ad-hoc le pot localiza, cu atât mai multe îmbunătățiri pot fi implementate de dezvoltatori înainte de termenul limită.
2. Cazuri de testare
Testarea ad-hoc nu implementează, în general, cazuri de testare – și asta tocmai pentru ca echipa să poată investiga cât de eficiente sunt acestea în asigurarea unei acoperiri ample. Cazurile de testare sunt probabil inadecvate dacă verificările ad-hoc pot găsi erori pe care procesele de testare convenționale nu le pot găsi.
3. Personalul de testare
Scopul ar putea fi, de asemenea, verificarea abilităților și cunoștințelor echipei de testare, chiar dacă cazurile de testare sunt adecvate. De exemplu, metodologia lor de implementare a cazurilor poate fi insuficientă, iar testarea ad-hoc poate fi esențială pentru a remedia lacunele rezultate în acoperirea testelor.
4. Limite software
Testarea ad-hoc urmărește, de asemenea, să înțeleagă limitele aplicației – cum ar fi modul în care aceasta răspunde la intrări neașteptate sau la sarcini mari ale sistemului. Testatorii ar putea cerceta în mod special mesajele de eroare ale programului și modul în care această aplicație se comportă atunci când este supusă unei presiuni semnificative.
Clarificarea unor confuzii:
Testarea ad-hoc și testarea exploratorie
Unii oameni consideră că testele ad-hoc și testele exploratorii sunt sinonime, deși adevărul este mai complicat decât atât.
1. Ce este testarea exploratorie?
Testarea exploratorie se referă la procedurile de asigurare a calității care investighează software-ul dintr-un punct de vedere holistic și combină în mod specific procesele de descoperire și testare într-o singură metodă. Aceasta este, de obicei, o cale de mijloc între testarea complet structurată și verificările ad-hoc complet libere.
Testarea exploratorie funcționează cel mai bine în scenarii specifice, cum ar fi atunci când este necesar un feedback rapid sau dacă echipa trebuie să abordeze cazuri limită. De obicei, acest tip de testare își atinge potențialul maxim atunci când echipa folosește alături de el testele scriptate.
2. Diferențe între testarea exploratorie
și testarea ad-hoc
Cea mai mare diferență între testarea ad-hoc și testarea exploratorie este utilizarea de către prima a documentației pentru a înregistra și a facilita verificările, în timp ce testarea ad-hoc evită complet acest lucru. Testarea exploratorie pune un accent mai mare pe libertatea de testare, dar niciodată la același nivel ca o abordare ad-hoc, care este complet nestructurată.
Testarea exploratorie implică, de asemenea, învățarea aplicației și a funcționării sale interne în timpul acestor verificări – în schimb, testerii ad-hoc au adesea o cunoaștere completă a funcționalității software-ului înainte de a începe.
Tipuri de teste ad-hoc
Există trei forme principale de testare ad-hoc în testarea software, inclusiv:
1. Testarea maimuțelor
Poate cel mai popular tip de testare ad-hoc, testele cu maimuțe sunt cele care implică o echipă care examinează la întâmplare diferite componente.
Aceasta are loc, de obicei, în timpul procesului de testare unitară și pune în aplicare o serie de verificări fără cazuri de testare. Testatorii investighează în mod independent datele în moduri complet nestructurate, permițându-le să examineze sistemul în general și capacitatea acestuia de a rezista la solicitări intense din partea utilizatorilor.
Observarea rezultatelor acestor tehnici nescriptate ajută echipa de testare să identifice erorile pe care alte teste unitare nu le-au observat din cauza deficiențelor metodelor de testare convenționale.
2. Testarea în echipă
Într-un context ad-hoc, testele de prietenie utilizează cel puțin doi membri ai personalului – de obicei un tester și un dezvoltator – și au loc, în principal, după etapa de testare unitară. „Prietenii” lucrează împreună pe același modul pentru a identifica erorile. Diversele lor seturi de competențe și experiența lor cuprinzătoare îi fac să fie o echipă mai eficientă, ceea ce ajută la atenuarea multor probleme care apar din cauza lipsei de documentație.
Dezvoltatorul ar putea chiar să sugereze el însuși o serie de teste, permițându-i să identifice componentele care ar putea avea nevoie de mai multă atenție.
3. Testarea perechilor
Testarea în perechi este similară în sensul că implică doi membri ai personalului, dar, de obicei, este vorba de doi testeri diferiți, dintre care unul execută testele efective în timp ce celălalt ia notițe.
Chiar și fără o documentație formală, luarea de notițe poate permite echipei să țină evidența în mod informal a verificărilor individuale ad-hoc. Rolurile testerului și ale scribului pot fi schimbate în funcție de test sau perechea își poate păstra rolurile atribuite pe parcursul întregului proces.
Testerul care are mai multă experiență este, de obicei, cel care efectuează verificările propriu-zise, deși aceștia își împart întotdeauna munca unul cu celălalt.
Teste Ad-Hoc manuale sau automate?
Testarea automatizată poate ajuta echipele să economisească și mai mult timp pe parcursul etapei de asigurare a calității, ceea ce le permite tesatorilor să includă mai multe verificări în programul lor. Chiar și fără o structură definită, este esențial ca testerii să lucreze pentru a maximiza acoperirea, iar automatizarea încurajează inspecțiile mai aprofundate ale acestui software.
Verificările ad-hoc automatizate sunt, în general, mai precise decât testele manuale, datorită capacității lor de a evita erorile umane în timpul sarcinilor repetate – acest lucru este deosebit de util atunci când se efectuează aceleași teste în diferite iterații. Succesul acestei proceduri depinde, de obicei, de instrumentul de testare automată pe care echipa îl alege și de funcționalitatea acestuia.
Cu toate acestea, testarea automată are anumite limitări. De exemplu, principalul punct forte al testării ad-hoc este capacitatea de a emula datele introduse de utilizator și de a efectua verificări aleatorii pe măsură ce testerul le găsește. Aceste teste ar putea să își piardă caracterul aleatoriu dacă programul de testare al organizației se confruntă cu verificări complexe.
Timpul necesar pentru a automatiza aceste sarcini extrem de specifice ar putea, de asemenea, să limiteze economiile de timp tipice ale acestui proces. Este important ca echipele să investigheze temeinic instrumentele de automatizare disponibile pentru a găsi unul care să se potrivească proiectului companiei lor.
De ce aveți nevoie pentru a începe testarea ad-hoc?
Iată care sunt principalele condiții prealabile ale testării ad-hoc:
1. Personal calificat
Deoarece testele ad-hoc sunt inspecții rapide și aleatorii ale funcționării interne a software-ului, este de obicei util să aveți testeri care au experiență cu software-ul respectiv. De asemenea, ar trebui să aibă cunoștințe practice despre principiile cheie de testare – acest lucru le permite să identifice cu ușurință cele mai eficiente verificări.
2. O abordare nestructurată
Testatorii trebuie să fie dispuși să renunțe la strategiile lor obișnuite de testare ad-hoc; această mentalitate este la fel de importantă ca și verificările de calitate în sine. Această metodă poate avea succes numai dacă nu există o structură sau o documentație și este vital ca testerii să țină minte acest lucru în fiecare etapă.
3. Software de automatizare
Deși testarea ad-hoc se bazează mai mult pe testarea intrărilor și condițiilor aleatorii, automatizarea este încă o tehnică foarte eficientă în orice context.
Din acest motiv, verificările ad-hoc ar trebui să implementeze în continuare instrumente de testare automatizate acolo unde este posibil, deoarece aplicația potrivită poate simplifica semnificativ procesul.
4. Alte forme de testare
Testele ad-hoc funcționează cel mai bine alături de alte verificări care au o abordare mai formală – ajutând echipa să garanteze o acoperire substanțială a întregului software. Este esențial ca testerii să îmbine diverse tehnici, deși acest lucru se poate întâmpla înainte, în timpul sau după ce au finalizat testarea ad-hoc.
Procesul de testare ad-hoc
Pașii obișnuiți pe care testerii ar trebui să îi urmeze atunci când efectuează teste ad-hoc în testarea software sunt:
1. Definirea obiectivelor testelor ad-hoc
Această etapă este limitată din cauza lipsei de documentație și de structură, dar este totuși extrem de important ca echipa să aibă un obiectiv clar. Testatorii pot începe să împărtășească idei vagi cu privire la testele care urmează să fie efectuate și la componentele cărora trebuie să le acorde prioritate.
2. Selectarea echipei de testare ad-hoc
Pe măsură ce echipa face un brainstorming pentru o serie de potențiale verificări ad-hoc, își dă seama, de asemenea, ce testeri ar fi cei mai potriviți pentru acest tip de testare. Aceștia selectează de obicei testeri care înțeleg foarte bine aplicația și pot, de asemenea, să îi asocieze cu un dezvoltator.
3. Executarea testelor ad-hoc
După ce se decide ce testeri sunt potriviți pentru această etapă, acești membri ai echipei își încep verificările la un punct convenit în timpul testării. Scopul lor este de a efectua cât mai multe verificări ad-hoc posibil, pe care testerii ar putea să nu le conceapă până în această etapă.
4. Evaluarea rezultatelor testelor
La finalizarea testelor (sau chiar între verificările individuale), testerii vor evalua rezultatele, dar fără a le documenta în mod oficial într-un caz de testare. În cazul în care descoperă probleme legate de aplicație, le înregistrează în mod informal și discută pașii următori ai echipei.
5. Raportarea oricăror erori descoperite
După ce evaluează rezultatele, testerii trebuie să informeze dezvoltatorii cu privire la erorile prezente în software, astfel încât aceștia să aibă timp suficient pentru a le remedia înainte de lansare.
Echipa de testare utilizează, de asemenea, informațiile pentru a determina cum să îmbunătățească procesele formale de testare.
6. Reexaminarea, dacă este necesar
Echipa de testare va repeta probabil procesul ad-hoc pentru noile iterații ale aplicației pentru a verifica cât de bine gestionează actualizările. Deoarece testerii vor fi rezolvat multe dintre lacunele identificate anterior în cazurile de testare, viitoarele verificări ad-hoc ar putea necesita o abordare diferită.
Cele mai bune practici pentru testarea ad-hoc
Există anumite practici pe care echipele de testare ar trebui să le implementeze în timpul testării ad-hoc, inclusiv:
1. Țintiți potențialele lacune în materie de testare
În timp ce testarea ad-hoc implică mult mai puțină planificare decât alte tipuri de testare, echipa își propune totuși să remedieze deficiențele în asigurarea calității. În cazul în care verificatorii ad-hoc suspectează probleme specifice cu cazurile de testare ale echipei, aceștia ar trebui să acorde prioritate la efectuarea verificărilor.
2. Luați în considerare software-ul de automatizare
Strategiile de automatizare, cum ar fi hiperautomatizarea, pot oferi multe beneficii companiilor care doresc să efectueze teste ad-hoc.
Succesul depinde de mai mulți factori cheie, inclusiv de instrumentul ales de întreprindere, precum și de complexitatea generală a testelor ad-hoc.
3. Luați notițe complete
Lipsa documentației în cazul testelor ad-hoc are ca principal scop simplificarea și mai mult a acestui proces – echipa ar putea beneficia de pe urma unor note informale pe măsură ce avansează. Acest lucru le oferă testerilor o evidență clară a acestor verificări și a rezultatelor lor, sporind astfel repetabilitatea generală a acestora.
4. Continuați să perfecționați testele
Testatorii ad-hoc își perfecționează continuu abordarea pentru a ține cont de schimbările în strategia de testare a echipei. De exemplu, atunci când analizează versiuni mai noi ale software-ului companiei, ar putea ajusta aceste verificări ca răspuns la cazuri de testare formală mai noi și mai cuprinzătoare.
7 greșeli și capcane în implementarea
Teste ad-hoc
La fel ca în orice proces de testare, există o gamă largă de greșeli potențiale pe care echipa ar trebui să încerce să le evite, cum ar fi:
1. Testeri neexperimentați
Pentru a menține ritmul așteptat al testării ad-hoc, liderul echipei trebuie să repartizeze testerii în funcție de cunoștințele și abilitățile pe care le au. În timp ce multe forme de testare se pot adapta la personalul de asigurare a calității de nivel începător, verificările ad-hoc necesită membri ai echipei care înțeleg pe deplin software-ul; de preferință cu experiență în efectuarea acestor teste.
2. Verificări necentrate
Testarea ad-hoc poate îmbunătăți semnificativ acoperirea testelor datorită ritmului său mai rapid – echipa nu trebuie să completeze o documentație extinsă înainte și după fiecare verificare.
Cu toate acestea, testerii ad-hoc trebuie să se concentreze în continuare asupra unui obiectiv puternic; de exemplu, aceștia ar putea decide să acorde prioritate anumitor componente cu un risc mai mare de eșec.
3. Fără planificare
Evitarea oricărui plan ar putea limita eficiența testelor ad-hoc. În ciuda naturii nestructurate a acestei abordări, este important ca echipa să aibă o idee aproximativă despre testele care trebuie executate înainte de a începe.
Timpul este limitat în timpul acestui proces, iar cunoașterea modului în care trebuie procedat poate oferi multe beneficii.
4. Prea structurat
La capătul opus al spectrului, această abordare se bazează de obicei pe o lipsă de planificare, deoarece aceasta îi ajută pe testeri să submineze în mod activ cazurile de testare și să găsească erori ascunse.
Testarea ad-hoc este cunoscută și sub numele de testare aleatorie, iar forțarea unei structuri ar putea împiedica aceste verificări să localizeze erori.
5. Fără modificări pe termen lung
Scopul testelor ad-hoc este de a identifica orice slăbiciune în cazurile de testare ale echipei; astfel se examinează strategia generală a acesteia la fel de mult ca și software-ul în sine.
Totuși, acest lucru înseamnă că testele ad-hoc sunt, în general, eficiente doar dacă echipa folosește aceste informații pentru a-și perfecționa verificările formale în timp.
6. Seturi de date incompatibile
Practic, orice formă de testare necesită o formă de date simulate pentru a evalua modul în care răspunde aplicația; unele instrumente permit tesatorilor să alimenteze automat un program cu date simulate.
Cu toate acestea, este posibil ca acest lucru să nu reflecte modul în care un utilizator s-ar angaja cu software-ul – verificările ad-hoc necesită seturi de date pe care software-ul le va întâlni probabil.
7. Silozuri de informații
Este esențial ca testerii și dezvoltatorii să fie în comunicare constantă între ei, chiar dacă aceștia din urmă nu fac parte din procesul de testare ad-hoc.
Acest lucru îi ajută pe toți să înțeleagă ce teste au fost efectuate – indicând următoarele acțiuni care trebuie întreprinse și, în același timp, împiedicând testatorii să repete inutil anumite verificări.
Tipuri de rezultate ale testelor ad-hoc
Verificările ad-hoc produc mai multe rezultate distincte, printre care:
1. Rezultatele testelor
Testele individuale produc rezultate diferite în funcție de componenta exactă și de abordarea implicată – aceasta poate lua mai multe forme.
De obicei, este responsabilitatea testerului să determine dacă rezultatele constituie o eroare, deși lipsa de documentație face dificilă compararea cu așteptările acestuia. Echipa transmite aceste rezultate dezvoltatorilor în cazul în care observă probleme.
2. Jurnalele de testare
Software-ul în sine utilizează un sistem complicat de jurnale interne pentru a monitoriza intrările utilizatorului și pentru a evidenția o serie de probleme legate de fișiere sau baze de date care ar putea apărea.
Acest lucru ar putea indica o eroare internă, inclusiv partea specifică a software-ului care cauzează problema. Cu aceste informații, testerii și dezvoltatorii ad-hoc pot aborda mult mai ușor problemele pe care le descoperă.
3. Mesaje de eroare
Multe verificări ad-hoc au ca scop specific să spargă software-ul și să-i expună limitele, ceea ce înseamnă că mesajele de eroare ale aplicației sunt unul dintre cele mai frecvente rezultate ale acestor teste.
Provocând în mod deliberat mesaje de eroare, echipa poate prezenta ceea ce vede utilizatorul final mediu ori de câte ori acțiunile neașteptate pe care le întreprinde au un efect negativ asupra funcționării programului.
Exemple de testare ad-hoc
Iată trei scenarii de testare ad-hoc care arată cum o echipă ar putea să o implementeze pentru diferite aplicații:
1. Aplicație web de comerț electronic
În cazul în care o companie dorește să testeze o aplicație web bazată pe comerț electronic, ar putea utiliza teste ad-hoc – în special testele de tip „monkey testing” – pentru a vedea cât de bine gestionează platforma interacțiunile neașteptate ale utilizatorilor.
Cei care testează pot încerca să împingă fiecare funcție la limită, de exemplu, adăugând articole în coș în cantități nerealiste sau încercând să cumpere produse care nu mai sunt în stoc. Aceștia nu sunt constrânși de cazurile de testare ale echipei și există puține limite în ceea ce privește verificările pe care le-ar putea efectua; testerii ar putea chiar să încerce să finalizeze achizițiile folosind URL-uri depășite.
2. Aplicație desktop
Testatorii ad-hoc pot, de asemenea, să implementeze aceste tehnici pentru aplicațiile desktop, cu un posibil accent pe diferite mașini și pe modul în care fiecare dintre ele se adaptează la program.
Membrii echipei ar putea efectua aceste verificări în mod repetat pentru a vedea cum afectează performanța generală a unei aplicații modificarea setărilor hardware sau software. De exemplu, este posibil ca o anumită placă grafică să aibă dificultăți în redarea interfeței.
Alternativ, acești testeri ar putea pur și simplu să dea programului lor intrări imposibile și să vadă cum răspunde, de exemplu dacă poate afișa corect mesaje de eroare care să explice problema în mod adecvat utilizatorului final.
3. Aplicație mobilă
Un mod în care testerii ad-hoc ar putea examina o aplicație mobilă este de a testa protocoalele de securitate ale acesteia – ar putea încerca să acceseze direct instrumentele de dezvoltare a aplicației, de exemplu.
Echipa poate încerca să vadă dacă poate efectua acțiuni neautorizate prin găsirea unor lacune și exploatări comune; ar putea solicita în mod special membrilor personalului cu experiență în securitatea aplicațiilor să faciliteze acest lucru.
Acest lucru ar putea implica, de asemenea, testarea în pereche cu dezvoltatorii, datorită cunoștințelor lor în ceea ce privește proiectarea aplicației, permițând unui tester să spargă software-ul și să arate exact unde lipsește securitatea.
Tipuri de erori și erori detectate
prin testare ad-hoc
Verificările ad-hoc pot scoate la iveală multe probleme ale unui program, cum ar fi:
1. Erori de funcționalitate
Folosirea testelor ad-hoc pentru a examina caracteristicile de bază ale unei aplicații ar putea dezvălui erori grave care afectează modul în care utilizatorii finali se pot implica în utilizarea acesteia.
De exemplu, testarea maimuței care testează opțiunile de plată ale unui site de comerț electronic va ilustra condițiile care împiedică tranzacția.
2. Probleme de performanță
Testatorii pot lucra în mod special pentru a crea probleme de performanță în program – de exemplu, prin umplerea bazei de date cu diverse intrări de spam.
Acest lucru s-ar putea manifesta sub forma unui decalaj semnificativ sau chiar a unei instabilități generale a software-ului, care va duce probabil la o blocare (potențial la nivelul întregului sistem).
3. Probleme de utilizare
Aceste verificări ar putea, de asemenea, să evidențieze defecte ale interfeței și ale experienței generale a utilizatorului. Interfața de utilizare a unei aplicații mobile, de exemplu, ar putea fi prezentată diferit pe un alt sistem de operare sau pe o altă rezoluție a ecranului. O interfață slabă poate determina utilizatorii să se chinuie să utilizeze această aplicație.
4. Defecte de securitate
Natura aleatorie a testării ad-hoc permite acoperirea unei serii de probleme de securitate comune și rare; un tester poate folosi aceste verificări pentru a găsi ușile administrative ale unui program.
În mod alternativ, inspecția acestora poate arăta că software-ul nu are criptare de date.
Măsurători comune de testare ad-hoc
Testarea ad-hoc utilizează diverse măsurători pentru a facilita rezultatele sale, inclusiv:
1. Eficiența detectării defectelor
Acest indicator analizează cât de eficient este procesul de testare pentru a găsi defecte în fiecare formă de testare, inclusiv testarea ad-hoc. Eficiența de detectare a defectelor este procentul de defecte descoperite împărțit la numărul total de probleme, ceea ce arată cât de eficiente sunt testele.
2. Rata de acoperire a testelor
O funcție auxiliară a testării ad-hoc este de a crește acoperirea prin verificarea componentelor într-un mod pe care cazurile de testare nu îl iau în considerare. Acest lucru înseamnă că testerii vor urmări, de asemenea, să mărească în mod radical acoperirea testelor pentru fiecare verificare, pe cât de mult pot.
3. Durata totală a testului
Testarea ad-hoc este mult mai rapidă decât alte procese de asigurare a calității – și este esențial ca testerii să lucreze pentru a menține acest avantaj. Măsurătorile privind durata testelor le arată membrilor echipei cum pot economisi timp și cum pot spori și mai mult avantajele strategiilor ad-hoc.
4. Rata de accidentare
Aceste teste au adesea scopul de a întrerupe software-ul și de a provoca un accident sau o eroare gravă, ceea ce le permite să depășească strategiile de testare tipice și să găsească probleme neașteptate. În acest scop, poate fi util să știți cât de des se blochează software-ul și care sunt cauzele acestor probleme.
5 Cele mai bune instrumente de testare ad-hoc
Există multe instrumente de testare gratuite și cu plată disponibile pentru testarea ad-hoc în testarea software – cele mai bune cinci sunt următoarele:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST este un program cuprinzător de testare a software-ului care oferă un nivel ridicat de funcționalitate de testare + RPA, atât în versiunea gratuită, cât și în cea de întreprindere.
Această suită completă de automatizare software + RPA permite testarea completă pe diferite platforme desktop și mobile; tehnologia 1SCRIPT a software-ului permite, de asemenea, utilizatorilor să execute cu ușurință aceleași verificări în mod repetat. În plus, instrumentul utilizează o viziune computerizată de ultimă generație, ceea ce face posibil ca ZAPTEST să ruleze teste ad-hoc dintr-o perspectivă umană.
2. BrowserStack
BrowserStack este o platformă cloud care poate facilita testarea pe peste 3.000 de mașini diferite, cu caracteristica suplimentară de automatizare a scripturilor Selenium. Deși oferă o acoperire solidă pentru proiectele software, funcționează cel mai bine cu aplicațiile de browser și mobile.
Soluțiile de testare BrowserStack includ, de asemenea, o versiune de încercare gratuită cu 100 de minute de testare automată – deși aceasta ar putea avea o utilizare limitată.
Deși abordarea bazată pe cloud poate fi utilă, aceasta afectează negativ și timpul de răspuns al platformei.
3. LambdaTest
LambdaTest utilizează în mod similar tehnologia bazată pe cloud și pune un accent puternic pe testarea browserului, ceea ce îi poate limita eficiența pentru alte aplicații – deși se potrivește bine cu programele iOS și Android. Aceasta este o platformă utilă atunci când scalabilitatea este o problemă și se integrează cu multe alte servicii de găzduire a testelor.
Cu toate acestea, unii utilizatori au reacții mixte în ceea ce privește prețurile aplicației în cadrul diferitelor opțiuni care nu sunt disponibile pentru testare, ceea ce ar putea limita accesibilitatea pentru organizațiile mai mici.
4. TestRail
TestRail este, în general, destul de adaptabil datorită faptului că rulează în întregime în browser și, în ciuda accentului puternic pus pe cazuri de testare eficiente, se mândrește, de asemenea, cu o funcționalitate ad-hoc directă. Analizele pe care le oferă după fiecare test pot ajuta, de asemenea, echipele care evită în mod activ să realizeze propria documentație independentă, permițându-le în același timp să își valideze procesul de testare.
Cu toate acestea, suitele mai mari s-ar putea să se confrunte cu formatul său bazat pe browser, care poate limita în mod semnificativ economiile de timp ale testelor ad-hoc.
5. Zephyr
Zephyr este o platformă de gestionare a testelor de la SmartBear care ajută echipele de asigurare a calității să își îmbunătățească vizibilitatea testelor, integrându-se în același timp cu alte programe de urmărire a erorilor.
Cu toate acestea, această caracteristică este limitată la anumite aplicații, Confluence și Jira fiind cele care beneficiază cel mai mult de Zephyr – acestea ar putea să nu fie cele mai eficiente soluții pentru orice afacere. Există mai multe programe scalabile disponibile sub marca Zephyr la diferite prețuri.
Lista de verificare, sfaturi și trucuri pentru testarea ad-hoc
Iată câteva sfaturi suplimentare pe care echipele trebuie să le ia în considerare atunci când efectuează teste ad-hoc:
1. Stabilirea priorității componentelor sensibile
Unele caracteristici sau componente sunt, în mod natural, mai expuse riscului de eroare decât altele, în special dacă sunt importante pentru funcționarea generală a programului.
Fiecare abordare a testării ar trebui să identifice părțile unei aplicații care ar putea beneficia de o atenție mai amănunțită. Acest lucru este util mai ales atunci când timpul total pentru testare este limitat.
2. Investigarea diferitelor instrumente de testare
Instrumentul pe care o organizație îl implementează pentru a facilita testele sale ar putea afecta acoperirea și fiabilitatea acestor verificări.
În cazul testelor ad-hoc, merită să analizați cât mai multe programe pentru a găsi cele care se potrivesc aspectului său centrat pe utilizator. Software-ul care utilizează tehnologia de viziune computerizată, cum ar fi ZAPTEST, poate aborda testele ad-hoc folosind o strategie asemănătoare celei umane.
3. Adoptați o mentalitate ad-hoc
Testarea ad-hoc oferă o libertate extraordinară pe parcursul etapei de asigurare a calității, dar echipa trebuie să se angajeze în acest sens pentru a beneficia de avantajele cheie ale strategiei.
De exemplu, testerii ad-hoc ar trebui să renunțe la toate documentele obișnuite în afară de luarea de notițe de bază și trebuie să inspecteze software-ul dintr-o perspectivă complet nouă.
4. Aveți încredere în instinctele de testare
Experiența în testarea ad-hoc sau în verificările generale ale software-ului poate ajuta la evidențierea punctelor comune de eșec, iar acest lucru îi ajută pe testeri să determine cum să detecteze erorile de toate tipurile.
Este esențial ca testerii să aibă încredere în instinctele lor și să folosească întotdeauna aceste cunoștințe în avantajul lor – ei pot intui care verificări ad-hoc ar fi cele mai utile.
5. Înregistrarea completă a erorilor descoperite
Deși testarea ad-hoc nu are o documentație formală și se bazează în principal pe note informale, este totuși esențial ca echipa să fie capabilă să identifice și să comunice cauza unei erori software.
Aceștia trebuie să înregistreze orice informație furnizată de test care este relevantă pentru dezvoltatori, cum ar fi orice cauze potențiale ale acestor probleme.
6. Țineți cont întotdeauna de utilizator
Fiecare formă de testare intenționează să se adapteze, într-o anumită măsură, la experiența generală a utilizatorului, iar testarea ad-hoc nu face excepție. Deși adesea analizează mai profund funcționarea internă a aplicației și chiar codul intern al acesteia, testerii ad-hoc ar trebui să încerce să spargă acest software în moduri în care utilizatorii ar putea teoretic să o facă.
7. Îmbunătățirea continuă a procesului
Echipele de testare ar trebui să își perfecționeze abordarea testelor ad-hoc între mai multe iterații ale aceluiași software și de la un proiect la altul.
Aceștia pot colecta feedback de la dezvoltatori pentru a vedea cât de bine au ajutat testele ad-hoc în etapa de asigurare a calității și dacă au reușit să crească semnificativ acoperirea testelor.
Concluzie
Testarea ad-hoc poate ajuta organizațiile de toate tipurile să își autentifice strategia de testare a software-ului, dar modul în care acestea implementează această tehnică poate fi un factor semnificativ în ceea ce privește eficiența sa.
Echilibrarea diferitelor tipuri de testare este cheia pentru a obține cele mai multe beneficii din verificările ad-hoc – mai ales că această formă de testare intenționează să le completeze pe celelalte, umplând un gol strategic.
Cu o aplicație precum ZAPTEST, este posibil ca echipele să efectueze teste ad-hoc cu mai multă încredere sau flexibilitate, în special dacă implementează automatizarea. Indiferent de abordarea specifică a echipei, angajamentul acesteia față de testarea ad-hoc ar putea revoluționa întregul program sau proiect.
