Meniu

Ce este testarea exploratorie în testarea software-ului (un ghid complet)

  • Principal
  • Alte
  • Ce este testarea exploratorie în testarea software-ului (un ghid complet)

what is exploratory testing software testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ce este testarea exploratorie?

„Testarea exploratorie” - așa cum sugerează și numele, este un proces simultan de învățare, proiectare și executare a testelor. Putem spune că în acest test testarea planificării, analizei, proiectării și executării testelor, se face împreună și instantaneu.

Aceste teste vizează explorarea sistemului și încurajarea gândirii practice și în timp real a unui tester.

În această serie am tratat următoarele tutoriale:

Tutorial nr. 1: Ce este testarea exploratorie în testarea software (Acest tutorial)
Tutorial nr. 2: Utilizarea tururilor pentru a asigura testarea exploratorie completă
Tutorial # 3: Testare exploratorie vs testare scriptată
Tutorial # 4: Testare exploratorie cu HP Sprinter
Tutorial # 5: Top 17 instrumente de testare exploratorie

*************************************
Testarea exploratorie

Ce veți învăța:

Prezentare generală

În termeni simpli, testarea exploratorie implică proiectarea simultană a cazului de testare și executarea testului unei aplicații sau a unui sistem testat. Testerul va crea sau scrie o idee de testare pentru a da direcție și va explora sistemul în timp ce testează pentru a crea în continuare teste critice, practice și utile pentru testarea cu succes a unei aplicații.

Acest lucru necesită o planificare minimă. Testerii iau continuu o decizie cu privire la următorul ei pas de acțiune. Depinde complet de procesul de gândire al testerului.

Uneori, acest test poate fi mai benefic decât abordarea de testare formală pentru găsirea unor defecte subtile care lipsesc în testarea formală.

Conștient sau inconștient, fiecare tester ar fi făcut teste exploratorii la un moment dat în cariera lor.

După cum știm cu toții, un cursant va învăța mai bine prin experiență practică, mai degrabă decât înghesuiți teoria.

În același mod, un tester va cunoaște aplicația mai bine doar explorând și învățând despre toate funcționalitățile pe care le oferă de la sine. Este întotdeauna bine să aveți o perspectivă de client și de afaceri în timp ce testați pentru a asigura testarea cu succes a unei aplicații.

De exemplu, dacă deschideți un site de cumpărături, aveți o idee generală că acest site de cumpărături vă va permite să faceți cumpărături selectând un produs la alegere și apoi plătind pentru același lucru.

În timpul acestui proces, ați putea afla că site-ul web vă oferă un aspect virtual asemănător uman, care vă ajută în procesul de selecție a produselor. De asemenea, ați constatat că puteți comanda o serie de produse pentru încercare la domiciliu sau că puteți efectua plata prin puncte de recompense ale unor bănci etc.

În calitate de tester, nu numai că trebuie să verificați dacă un sistem funcționează conform așteptărilor, ci și să verificați dacă sistemul nu se comportă într-un mod care nu este de așteptat.

Câteva lucruri de reținut în timpul efectuării acestui test:

  • Misiunea ta ar trebui să fie clară.
  • Asigurați-vă că creați note și raportați cu privire la ceea ce faceți și la modul în care se comportă un sistem, care ar putea fi o posibilă eroare.
  • Aflați, observați și apoi veniți cu noi cazuri de testare.

Serviciul de testare exploratorie recomandat

# 1) Digivante Direct

Logo Digivante Direct

Digivante Direct efectuează teste exploratorii utilizând rețeaua sa globală de testere profesionale, astfel încât să puteți acoperi testarea pe toate dispozitivele majore într-un interval de timp care nu poate fi atins de niciun alt furnizor de testare sau echipă internă.

Lansați mai rapid, mai sigur și permiteți platformelor dvs. digitale să ofere satisfacție mai mare a clienților și venituri online crescute.

Caracteristici:

  • 24 de zile lucrătoare de testare în doar 24 de ore sau 90 de zile lucrătoare în 72 de ore și un nivel cuprinzător de testare, de neegalat, de nerealizat prin orice alte mijloace.
  • Cost scăzut , pachete de preț ușor de înțeles, fără extras ascunse.
  • Autoservire portal online care nu necesită niciun angajament continuu.
  • Oameni reali care testează pe dispozitive reale - o acoperire mult mai mare a dispozitivului și a browserului decât puteți obține intern și totul într-un interval de timp mai rapid.
  • Acoperirea completă a testelor exploratorii - reduceți riscul și îmbunătățiți satisfacția utilizatorului final și ratele de conversie, crescând astfel veniturile, reducând în același timp costurile.
=> Vizitați site-ul web Digivante Direct

Exemple de testare exploratorie

Exemplul nr. 1:

Un site web pentru furnizorii de servicii de îngrijire la domiciliu cu următoarele componente:

  • Autentificare
  • Servicii
  • Cart
  • Plată
  • Istoric comenzi
  • Alocarea tehnicianului

O idee generală pentru a începe exploratorie testarea va fi să vă conectați sau să rezervați un serviciu.

Cum se acoperă cazurile de testare?

Testarea cazurilor de testare exploratorie

programarea java întrebări și răspunsuri pentru interviuri cu experiență

În cele de mai sus Exemplu, ideea este să începeți cu funcționalitatea bazată pe cunoștințele dvs. Pe măsură ce învățați și observați mai multe despre aplicație, puteți controla următorul set de cazuri de testare.

Exemplul nr. 2:

Am fost odată inclus într-un mic proiect care presupunea adăugarea unui nou fond mutual în aplicație. Sarcina mea a fost să testez aplicația pentru a mă asigura că noul fond mutual este disponibil pentru cumpărarea utilizatorilor și pentru a verifica dacă evaluarea asociată este corectă. Am avut doar 2 zile să-mi finalizez testele.

Având în vedere termenul limită și severitatea testelor, am folosit abordarea exploratorie a testării. Scopul meu a fost să testez funcții noi și să găsesc încălcări ale cerințelor de compatibilitate.

Scopul menționat mai sus a devenit statutul meu pentru această sesiune de testare.

Următoarele cazuri de testare au fost dezvoltate în timpul acestei testări:

  • Testarea pentru a vă asigura că noul fond mutual a fost adăugat la cerere.
  • Nou MF este cumpărat cu succes.
  • Evaluarea noului MF este corectă.
  • Am încercat să cumpăr un nou MF pentru un portofoliu existent.
  • Poate fi adăugat un nou MF la toate portofoliile?
  • Impactul noului MF asupra evaluării existentului.
  • Deci, în alte cazuri de testare au fost evoluate.

Am pregătit note și rapoarte în timpul testării pentru a discuta observația mea cu BA și clientul implicat.

Strategia fundamentală a testării exploratorii este de a avea un plan de atac. Începeți testarea cu ideea dvs. și improvizați noi cazuri de testare pe baza cunoștințelor și observației dvs.

Exemplul nr. 3:

Testarea exploratorie a site-ului IRCTC

=> Faceți clic aici pentru a descărca exemplele de cazuri de testare a testelor exploratorii de pe site-ul IRCTC.

Abordarea de testare

  • Folosiți euristicile pentru a ghida testarea.
  • Executarea cazurilor de testare și crearea cazurilor de testare merg mână în mână.
  • Testele continuă să evolueze pe baza observării și învățării testerului.
  • Diferite tehnici de testare precum Analiza valorii limită , testarea echivalenței etc. se poate aplica la ET.
  • ET bazat pe sesiune poate fi folosit pentru a-l face mai structurat și mai concentrat.
  • Testatorii pot ramifica idei acolo, dar nu se pot abate niciodată de la misiunea ta.
  • Testarea ET nu folosește scripturi, ci depinde de intuiția, abilitățile și experiența testerului.

Beneficii

Beneficiile acestui test includ:

  • Promovează gândirea în timp real și ajută la descoperirea mai multor defecte.
  • Promovați cazurile de utilizare și testarea bazată pe scenarii.
  • Documentare minimă, testare maximă.
  • Accentul se pune mai mult pe învățarea și lărgirea orizontului unui tester.
  • Evitați munca duplicat.
  • Util când doriți să auditați munca altor testeri.

Demerite

Demeritele sunt enumerate mai jos:

  • Testarea depinde de experiența, abilitățile și cunoștințele testerului.
  • Aveți nevoie de timp pentru a învăța aplicația. Testerul este mai probabil să rateze dacă știe mai puțin despre aplicație.
  • Nu este adecvat pentru proiecte cu timp de execuție lung.

Testare exploratorie bazată pe sesiune

În timp ce fac teste exploratorii, este foarte dificil pentru testatori să spună în cuvinte cât de mult a testat și pe ce bază.

Practic, este dificil de cuantificat munca și timpul petrecut. Cu toate acestea, în fiecare proiect, trebuie să oferim valori, estimări și rapoarte de progres liderilor de echipă și managerilor. După cum se spune, „dacă nu o poți cuantifica, nu o poți gestiona”.

Testarea bazată pe sesiune este o abordare bazată pe timp pentru a efectua acest test, care ajută la gestionarea și urmărirea. Include o sesiune dedicată de testare în timp, fără întreruperi de la e-mail, telefon, mesaje etc.

Abordare:

Sarcinile de testare sunt împărțite în sesiuni.

Următoarele sunt componentele testării bazate pe sesiune (SBT):

  • Misiune: Misiunea strigă scopul sesiunii și într-un fel oferă atenția testerului. De asemenea, va include o durată a sesiunii.
  • Cartă: Include domeniul de aplicare al testării. Practic, o agendă care detaliază obiectivele care trebuie îndeplinite în timpul sesiunii.

Exemplu de carte de test pentru funcționalitatea de conectare a site-ului web al serviciului de îngrijire la domiciliu:

Exemplu de carte de testare pentru funcționalitatea de conectare

  • Sesiune: Sesiune de testare predefinită în timp, fără nicio întrerupere. Fiecare sesiune poate avea următoarea durată:
    • „Scurt” (60min)
    • „Normal” (90 minute)
    • „Lung” (120 min)
  • Raportul sesiunii: Includeți note și un raport ușor pentru a furniza valori liderilor și managerilor. Oferă detalii despre sesiunea de charter rămasă sau terminată, timpul de configurare a sesiunii, scenariul testat, despre procesul de testare, o listă de erori și problemele găsite și alte informații pentru valori.
  • De-brief al sesiunii: O scurtă întâlnire sau stand-up între tester și conducătorul / managerul de testare pentru a revizui rezultatele sesiunii de testare.

Managerii pot obține următoarele valori practice pe baza raportului de sesiune:

  • Numărul de sesiuni finalizate și rămase.
  • Numărul de erori raportate.
  • Timpul petrecut la configurarea sesiunii.
  • Timpul petrecut pentru testare.
  • Timpul petrecut pentru analiza problemelor sau problemelor.
  • Caracteristici acoperite.

Pentru a rezuma cele de mai sus:

SBT permite răspunderea este testarea exploratorie și oferă o mai bună gestionare a timpului petrecut la testare. De asemenea, crește productivitatea și oferă o mai bună înțelegere a detectării erorilor. Este o modalitate excelentă de a oferi conducătorilor de echipă și managerilor valori pentru a verifica progresul proiectului.

Testare exploratorie bazată pe perechi

Testarea pereche este o abordare în care două persoane testează același lucru / caracteristică a aplicației în același timp, partajând un computer. Își împărtășesc continuu gândurile și ideile. În timpul acestei testări, o persoană se ocupă de tastatură, în timp ce cealaltă persoană sugerează cazuri de testare și ia notă.

Este întotdeauna util să aveți o comunicare bună între parteneri, astfel încât ambii să fie conștienți de ceea ce se face și de ce. O pereche în care puterea testerilor își completează reciproc slăbiciunea este considerată o grupare puternică.

O astfel de asociere aduce beneficii atât părților, cât și fiecare poate învăța ceva de la partenerul său. Este, de asemenea, o modalitate bună de a instrui resurse noi prin asocierea acestora cu resurse cu experiență.

Avantajele testării perechilor

  • Ajută un tester să se concentreze asupra sarcinii la îndemână.
  • Încurajați încrederea reciprocă și respectul dintre parteneri.
  • Brainstorming-ul dintre testerii asociați, de obicei, duce la idei mai constructive.
  • Evitați vederea tunelului.
  • Există șanse mai mici ca alții să le întrerupă.

Tehnici de testare exploratorie

Tururi: Este o tehnică simplă care permite unui tester să-și folosească imaginația și să se gândească la sine ca la un turist care explorează un oraș pe care îl vizitează. Aici o aplicație de testat este orașul, iar testerii sunt turiștii. Este foarte dificil să explorezi întregul oraș, cu excepția cazului în care ai mult timp și bani în mână, așa că un turist trebuie să aibă în vedere un plan cu un anumit scop.

Un turist poate face următoarele tururi:

  • Tur ghid - Testarea caracteristicii evidențiate a aplicației. Utilizați scenarii bazate pe utilizatori.
  • Explorarea istoriei orașului - Testați caracteristicile vechi ale unei aplicații.
  • Turul banilor, ceea ce înseamnă să vă asigurați că toate caracteristicile critice referitoare la client sau client sunt testate și funcționează cu succes.
  • Turneu de crimă - Introduceți date de intrare nevalide și testați scenarii negative.
  • Turul aleii din spate - Testați cele mai puțin utilizate caracteristici ale aplicației.
  • Turneu plictisitor - Petreceți timp minim pe fiecare ecran al aplicației, completați câmpurile minime și urmați cea mai scurtă cale. Acest lucru vă va ajuta cu valoarea implicită și testarea validării.

În timp ce faceți un tur, aveți întotdeauna posibilitatea de a lua orice cale. Puteți naviga prin software și găsiți o cale unică pentru a testa caracteristica.

Mai jos sunt câteva sfaturi / trucuri pe care le puteți folosi în ET:

  • Împărțiți aplicația în module și bifurcați modulele în diferite pagini. Porniți ET din pagini. Acest lucru va oferi acoperirea corectă.
  • Faceți o listă de verificare a tuturor caracteristicilor și marcați o bifă atunci când aceasta este acoperită.
  • Începeți cu un scenariu de bază și apoi îmbunătățiți-l treptat pentru a adăuga mai multe caracteristici pentru a-l testa.
  • Testați toate câmpurile de intrare.
  • Testați pentru mesajul de eroare
  • Testați toate scenariile negative.
  • Verificați GUI în raport cu standardele.
  • Verificați integrarea aplicației cu alte aplicații externe.
  • Verificați logica complexă a afacerii.
  • Încercați să faceți hacking etic al aplicației.

Factorii care afectează ET sunt după cum urmează:

  • Obiectivul proiectului
  • Strategia de testare
  • Scopul testării unei anumite faze
  • Instrumente și facilități disponibile
  • Rolul și abilitățile testerilor
  • Timp disponibil
  • Suport de administrare
  • Suport de la egal la egal
  • Resurse disponibile (materiale de studiu, condiții de testare etc.)
  • Interesul clienților
  • Înțelegerea produsului.
  • UI a aplicației
  • Funcționalitatea aplicației
  • Rezultatele testelor anterioare
  • Riscuri asociate aplicației
  • Defecte anterioare
  • Schimbări recente
  • Tipuri de date de utilizat pentru testare
  • Tipul de utilizator care îl va folosi

În loc să întrebăm testerii ce să alerge, lăsăm la latitudinea testerului să decidă ce vor să testeze și cum vor să testeze.

Diferența dintre testarea exploratorie și testarea ad-hoc

Nu confundați ET cu Test ad-hoc .

  • Testarea ad-hoc se referă la un proces de căutare neexcriptată, neplanificată și improvizată a defectelor, în timp ce testarea exploratorie este o metodologie atentă pentru testarea ad-hoc.
  • Testarea ad-hoc este o metodă de încercare pentru a găsi o eroare, în timp ce ET nu este. În abordarea ET, un tester învață despre sistem în timp ce explorează și în cele din urmă dezvoltă testele folosind cunoștințele dobândite.
  • Testarea ad-hoc este o activitate nestructurată, în timp ce ET este oarecum o activitate structurată.

Testare automată exploratorie (EAT)

Testarea automată exploratorie este o metodă care ajută un tester să eficientizeze raportarea și reproducerea erorilor, colectarea instantaneelor ​​și pregătirea viitoarei proceduri de regresie. Este un proces care combină testarea automatizării cu testarea exploratorie.

Există două tipuri de abordare EAT:

combinați codul de sortare în c ++ cu recursivitate
  • EAT pasiv
  • EAT activ

EAT pasiv

EAT pasiv poate fi efectuat de un singur tester sau în pereche. În această metodologie, de obicei, un instrument, care captează și înregistrează fiecare activitate efectuată de o resursă de testare și este instalat pe computerul resursei.

EAT pasiv este similar cu ET care se efectuează manual, deoarece nu există nicio schimbare în modul în care testele sunt executate în afară de elaborarea rezultatului testului pe baza sesiunii capturate. Aceste rezultate ale testului pot fi utilizate pentru raportarea și reconstituirea acțiunilor înregistrate mai târziu.

Instrumentul video instalat ajută un tester la înregistrarea cazurilor de testare și raportarea defectelor.

De asemenea, are câteva alte beneficii, cum ar fi:

  • Oferă pași clari pentru reproducerea erorilor.
  • Reproducerea defectelor este mai ușoară chiar și atunci când reporterul defectelor nu este disponibil.
  • Înlăturați conflictele dintre echipa de testare și dezvoltare atunci când este raportat un bug intermitent.
  • Ajută la testarea performanței obținând timpul de răspuns al sistemului la momentul specific.

Iată câteva alte puncte care trebuie luate în considerare înainte de EAT pasiv:

  • Este recomandat să efectuați un test pilot înainte de a adapta complet instrumentul pentru EAT automatizat. Aceasta este pentru a se asigura că timpul necesar pentru reproiectarea jurnalelor de test create în timpul sesiunii de test nu este mai mult decât execuția testului. Dacă da, atunci echipa trebuie să ia o decizie reciprocă cu privire la următoarele:
    • Dacă este necesar, automatizarea testului este necesară pentru proiectul respectiv.
    • Dacă instrumentul utilizat trebuie schimbat.
    • Dacă performanța instrumentului utilizat poate fi optimizată.
  • Instrumentul utilizat pentru efectuarea EAT automatizat trebuie instalat pe fiecare resursă de testare implicată în testare. Este, de asemenea, o idee bună să implicați dezvoltatorii, ceea ce poate fi realizat fie oferind dezvoltatorilor VPN sau acces de la distanță la mașinile de testare, fie instalând instrumentul în mediul de dezvoltare.
  • Este întotdeauna o idee bună să aveți obiectul GUI al aplicației organizat în instrumentul de testare, astfel încât, atunci când vine momentul analizei erorii sau a unei probleme, obiectul să poată fi recunoscut datorită unui nume semnificativ.
  • Este o practică extraordinară să dai un nume semnificativ obiectului GUI utilizat în AUT și să le menții organizate pentru o utilizare ulterioară.

Acum, să trecem la a doua abordare.

EAT activ

Este recomandabil să efectuați EAT activ cu testarea perechii. În această abordare, testarea bazată pe cuvinte cheie este utilizată în sincronizare cu testarea sesiunii. Un tester creează scriptul de test automat și al doilea tester execută scripturile de test create de primul tester.

Crearea scripturilor de testare a automatizării în această abordare ia o cale diferită decât în ​​testarea convențională. Scripturile automate de testare sunt realizate în timpul testării și ceea ce a fost descoperit în testele anterioare determină proiectarea lor.

O fază de închidere este executată la sfârșitul sesiunii de testare. Și ar trebui să aibă următoarele sarcini:

  • Testerii implicați ar trebui să schimbe rolurile astfel încât resursa de testare care a creat scriptul de testare să aibă șansa de a executa din nou scripturile pentru a confirma fiabilitatea și robustețea suitei create.
  • O scurtă descriere împreună cu câteva caracteristici de identificare ar trebui să fie furnizate pentru fiecare script de test automat.
  • Trebuie definit un criteriu pentru a identifica care scripturi de test automat pot fi utilizate pentru testul de regresie.

Beneficiile EAT

  • La începutul fiecărei sesiuni, scripturile de test automat create deja sunt executate, îmbunătățind astfel acoperirea testului de fiecare dată.
  • Raportare mai bună a erorilor și documentare pentru reproducerea defectelor.
  • EAT oferă suficiente dovezi și documentație pentru ca un părți interesate să vadă progresul.

Tipuri de testare exploratorie

Mai jos sunt câteva tipuri de ET:

1) Freestyle ȘI:

Explorarea aplicației în stil ad-hoc.

În acest tip de ET, nu există reguli, nici un cont pentru acoperire, etc. Cu toate acestea, acest tip de testare este bun atunci când trebuie să vă familiarizați cu aplicația rapid, când doriți să verificați activitatea celorlalți testeri și când doriți să investigați un defect sau doriți să faceți un test rapid de fum.

2) ET bazat pe scenariu:

După cum sugerează și numele, testarea efectuată se bazează pe scenarii. Începe cu scenarii de utilizator real, scenarii de la capăt la capăt sau scenarii de testare. După testarea inițială, testerii pot injecta variații conform învățării și observării lor.

Scenariile sunt ca un ghid generic pentru ceea ce trebuie făcut în timpul ET. Testerii sunt încurajați să exploreze mai multe căi posibile în timp ce execută un scenariu pentru a asigura toate căile posibile către funcția de lucru. Testatorii ar trebui, de asemenea, să se asigure că adună cât mai multe scenarii posibil din diferite categorii.

3) StrategieET bazat pe:

Tehnici de testare cunoscute, cum ar fi analiza valorii limită, tehnica echivalenței și tehnica bazată pe riscuri, care sunt combinate cu testarea exploratorie. Pentru acest tip de testare este numit un tester experimentat sau un tester care este familiarizat cu aplicația.

Testare exploratorie agilă

Chiar dacă nu ați lucrat într-un mediu agil, sunt sigur că trebuie să fi citit sau auzit despre asta din cauza popularității sale în creștere. Metodologia Agile are sprinturi scurte și termene limitate, ceea ce oferă o echipă câteva săptămâni pentru a termina planificarea, estimarea, dezvoltarea, codificarea, testarea și lansarea.

Testarea exploratorie devine utilă în astfel de termene limitate, deoarece în această abordare de testare accentul se pune pe rezultatul rapid și util. După ce ați înțeles cerința, puteți începe testarea pe baza experienței și cunoștințelor dvs.

După ce vă familiarizați cu caracteristicile și comportamentul aplicației, puteți proiecta mai multe cazuri de testare pentru a valida funcționalitatea aplicației și pentru a detecta erori neplanificate. Deoarece este o abordare de testare freestyle, trebuie să documentați totul. Cu toate acestea, trebuie să păstrați note și un scurt raport despre ceea ce ați testat, erori și probleme găsite etc.

Meritele exploratorii în agilitate

  • Oferirea de feedback dezvoltatorilor cât mai curând posibil.
  • Sunt descoperite o varietate mai largă de defecte.
  • Un grup divers al unei resurse, cum ar fi un dezvoltator, un tester, un BA, designerii pot efectua ET deoarece nu există cazuri de testare scriptate și fiecare aduce o perspectivă diferită.
  • Cercetarea efectuată în ET ajută la explorarea de noi teritorii și la expunerea unor erori critice.
  • În caz de codare iterativă a unei aplicații, ET se poate concentra pe testarea noilor caracteristici în timp ce automatizarea face regresie și teste de compatibilitate inversă.
  • În cazul unei cerințe instabile, ET poate ajuta la testarea noilor cerințe într-un timp limitat.

Puncte de reținut:

1. Necesită diferite abilități: Testerii care efectuează ET trebuie să aibă abilități bune de ascultare, citire, gândire și raportare. Este necesară experiența domeniului deoarece nu există scripturi și cazuri de testare.

2. Uneori este dificil să raporteaza o eroare: În timp ce ne aflăm într-un flux ET, putem întâlni un defect, dar este posibil să nu îl putem reproduce. Acest lucru se datorează faptului că nu urmărim pașii de testare și este posibil să uităm pașii exacți pentru a reproduce problema respectivă.

3. Poate fi realizat ca activitate de recreere: Personal fac ET atunci când vreau o pauză de la ciclul meu obișnuit de execuție a testului. Dar multe echipe au ET ca o fază separată a ciclului lor de testare.

4. Se poate face pentru toate fazele de testare: Putem implementa ET înainte de începerea oricărei faze de testare. Puteți efectua ET chiar înainte de faza de testare funcțională.

5. Feedback rapid: ET necesită feedback rapid cu privire la problemele și eventualele anomalii întâlnite.

6. Gândire critică și idei diverse: Acest test necesită o gândire critică. Testatorii ar trebui să poată reproduce, revizui și exprima ideile lor într-un mod logic. Un tester își poate implementa experiența în diversele tehnologii și domenii la care au lucrat.

Cum să gândiți dincolo de limitele de testare tradiționale în testarea exploratorie

„Apreciez foarte mult îngrijorarea dvs. pentru produs și ne ajută într-o perspectivă de înțelegere a utilizatorului final. Va fi foarte util. Vă mulțumim pentru munca bună și continuați-o !!! ”

Acesta a fost ultimul e-mail al unui lanț de e-mailuri cu 21 de e-mailuri de la clientul nostru. Era miezul nopții și lansarea produsului nostru a fost amânată din cauza unei erori critice pe care am găsit-o. S-ar putea să vă gândiți, ce este nou în asta? Se poate întâmpla de multe ori. Dar acest lucru a fost cu adevărat diferit, deoarece eroarea critică pe care am raportat-o ​​nu a fost rezultatul unui caz de testare documentat.

După finalizare testarea regresiei pentru ultima oară în seara aceea, mă jucam doar cu produsul. Ce inseamna asta? Ești liber să faci ceea ce nu ar trebui să faci. Pe baza experienței și a cunoștințelor despre proiect, am avut câteva idei despre cum să testez produsul în afară de depozitul nostru de testare tipic, numit Testarea exploratorie .

Testarea exploratorie efectuată a constatat o eroare critică legată de o problemă de blocare a serverului în timp ce se făcea ceva neașteptat.

Fiind un fan al testelor exploratorii, îmi place să explorez produsul în diferite moduri. Pentru mine, definiția software-ului este:

„Ar trebui să facă ceea ce ar trebui să facă și nu ar trebui să facă ceea ce nu ar trebui să facă.”

Procesul de testare exploratorie

Limitarea limitelor de testare pentru a verifica dacă produsele care ar trebui să funcționeze funcționează vă face un tester incomplet. De fapt, viața unui tester începe atunci când se termină testarea de regresie documentată și rezultatele sunt actualizate. Privirea produselor din perspective diferite și înțelegerea cerințelor utilizatorilor finali în diferite scenarii fac o mare diferență. Așadar, astăzi, să înțelegem împreună, cum se poate face această diferență:

Cum să privim un produs din perspective diferite?

testarea exploratorie

# 1. Înțelegeți clientul / utilizatorul final

Testarea software-ului se referă la verificarea calității produsului în termeni de satisfacție a clienților. Cum știți punctul de vedere al unui client? Răspunsul este simplu - trebuie să fii clientul. OK, lasă-mă să fac o corecție. A fi client nu va fi suficient. Trebuie să înțelegeți modul în care clientul dorește să gestioneze produsul. Nici doi clienți care au cumpărat aceleași materii prime nu vor pregăti aceeași rețetă. Da, produsul pe care îl dezvoltăm / livrăm este o materie primă pentru afacerile clienților și aceștia au o mentalitate diferită în timp ce îl utilizează.

În calitate de tester de software, trebuie să verificăm scopul produsului și nu obiectul sau aspectul acestuia.

Permiteți-mi să vă dau câteva exemple practice din viața reală:

  • Foarfeca nu a fost niciodată limitată doar la tăierea hârtiei. Tăierea este scopul și nu hârtia (obiectul).
  • Telefoanele mobile nu au fost niciodată limitate doar la apeluri, dar „posibilitatea de a apela” a fost întotdeauna scopul de bază.
  • Cutii de depozitare sunt folosite pentru depozitare, dar siguranța materialului depozitat este la fel de importantă ca depozitarea.

Înțelegerea părților interesate și o gamă largă de așteptări ale acestora ar trebui să fie baza de testare exploratorie.

# 2. O mentalitate

În timp ce căutați (să zicem) un anunț de angajare la locul de muncă, vedeți jackpot-ul respectiv și între pagini cu fontul bold? Majoritatea dintre noi nu (crede-mă, este adevărat). Pentru că ne-am instruit mintea să căutăm ceea ce este util sau să fie verificat. Orice altceva nu este de nici un folos, așa că mintea ne refuză să o recunoaștem.

Deschide-ți mintea și nu-ți seta nicio așteptare atunci când începi să explorezi un produs . Amintiți-vă întotdeauna, nu este OK dacă produsul face ceea ce ar trebui să facă. De asemenea, este important să nu facă ceea ce nu ar trebui să facă.

Îmi amintesc un exemplu clasic:

În Linux, comanda „cat” este utilizată pentru a verifica conținutul unui fișier, iar comanda „ls” este pentru a verifica conținutul directorului. Lucrând cu Linux și fiind în testarea software-ului timp de cinci ani, nu m-am gândit niciodată să fac pisică, deoarece mintea mea era pregătită; dacă aveam nevoie de conținut dir, trebuie să folosesc „ls”. Acest lucru a funcționat, dar partea inversă a așteptărilor este că produsul nu trebuia să se comporte așa cum nu trebuia, era greșit. Unul dintre clienții noștri, care nu cunoștea bine Linux-ul, a greșit din greșeală și sistemul sa prăbușit. Am plătit pentru această mentalitate.

Fiți întotdeauna gata să faceți greșeli cu software-ul, deoarece asta va face utilizatorul final. Pentru a testa software-ul, ați fost instruit, dar utilizatorul final nu va fi la fel de instruit ca dvs. sau el / ea nu va fi la fel de expert tehnic ca tine. De asemenea, el / ea va face orice cu software-ul atunci când au probleme.

Gândiți-vă la aceste scenarii și oferiți feedback de testare. Viața software-ului și a ta (ca tester) se vor schimba.

# 3. Cunoașteți concurenții

În timp ce testați orice aplicație software pentru clientul dvs., ați încercat vreodată să cunoașteți și să înțelegeți alte programe cu același scop? Ați sugerat vreodată câteva funcționalități utile pe care le-ați observat în produsul unui concurent? Nu se încadrează în fișa postului nostru, este răspunsul tipic. Dar știi avantajul de a o face?

Iată câteva exemple din viața reală pentru a vă face să înțelegeți ideea:

  • Nu îți place designerul care nu numai că îți cusută rochia, dar îți oferă cel mai mult informații despre accesoriile potrivite?
  • Nu-ți place brandul de pizza care nu numai că face pizza grozave, dar livrează acasă la timp?
  • Nu-ți place fotograful care nu numai că face fotografii bune, dar sugerează un alt tip de cadre pentru ședința foto?

Toată lumea vrea să aibă ceva în plus pentru ceea ce plătește. Analiza noastră a software-ului competitiv poate funcționa în același mod și pentru noi. Clientului îi place întotdeauna să audă sugestii valoroase - în principal sugestii comparative pentru a face produsul mai util sau mai comercializabil.

De asemenea, acest tip de comparație și analiză a aceleiași game de produse face ca analiza noastră să fie mai puternică și, în cele din urmă, creăm o comoară la care putem să ne întoarcem în orice moment și să găsim ceva util.

Concluzie

Explorator nu intră sub un mod convențional de testare, dar totuși, este un mod foarte puternic de testare.

Acesta scoate la iveală gândirea unui tester și îi încurajează să vină cu cazuri practice și în timp real pentru a găsi un defect. Natura sa liberă îi conferă un avantaj față de celelalte tipuri de testare și poate fi efectuată oriunde, fie că este un proiect care utilizează Agile sau cascadă sau orice alt proiect care necesită o documentare minimă.

Succesul testării exploratorii depinde de numeroase intangibile, cum ar fi abilitatea unui tester, capacitatea de a crea cazuri de testare eficiente, experiența lor și abilitatea de a-și urmări sentimentul intestinal.

Este imperativ să ne amintim că ET este mai degrabă un proces adaptiv decât unul predictiv și este esențial să menținem un echilibru sănătos între testarea exploratorie și testarea scriptată sau regulată.

Sunteți un tester care are experiențe tipice de testare exploratorie? Așteptăm să vă auzim gândurile. Nu ezitați să le împărtășiți în secțiunea de comentarii de mai jos.

Următorul tutorial # 2: Cum se utilizează tururi pentru a asigura testarea exploratorie completă

Lectură recomandată

^