Meniu

Cum să faceți față cerințelor proaste ca tester

how deal with bad requirements

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Sala de conferințe tăcută se sufoca și toată lumea din interiorul ei era confuză. Cum am putea să ne lipsească , a fost întrebarea reflectată pe fața tuturor.

La urma urmei, să nu apară nicio eroare relevantă atunci când utilizatorul încearcă să dubleze înregistrarea existentă și să-i permită să facă acest lucru nu a fost o mică eroare - Și asta pentru o companie de asigurări.

După ce au decis să rezolve problema, toată lumea s-a dispersat. Și, în timp ce a săpat, s-a observat că clientul nu a menționat niciodată nimic despre duplicitatea înregistrărilor în documentul de cerințe și, prin urmare, nimeni nu a pus întrebări relevante și nici nu s-a gândit la asta.

cerințe proaste

Acesta a fost doar un exemplu.

Într-o carieră de peste 10 ani Am observat numeroase cazuri în care proiectele au suferit din cauza unor cerințe proaste sau proaste.

Dar, așa cum se spune, nimic nu este perfect în această lume și va trebui să te descurci cu ea și să te ocupi de proiecte fără cerințe sau cerințe slabe este un fel de coșmar.

Lasă-mă să explic -

Ce veți învăța:

Cât de rele, sărace și conflictuale cerințele creează probleme:

# 1) Fără cerințe - Nici o cerință nu presupune presupuneri și presupuneri și, prin urmare, nu există încredere. Este foarte dificil să testați un produs / aplicație fără nicio linie de bază. Și aceste rezultate în mai multă muncă, mai multe bug-uri de la client și mai multă suferință pentru proiect.

  • Cum ai face raportează o problemă Despre blocarea sistemului când nu există o definiție a modului în care trebuie tratat comportamentul a fost disponibilă?
  • Cum ați transmite că timpul de încărcare de 100 de secunde pentru pagina principală este inacceptabil atunci când nu există o cerință relevantă pentru performanță?

Mai multe informații despre Fără cerințe și despre modul de gestionare a situației în timpul testării pot fi găsite în articolul publicat anterior - Cum se testează o aplicație fără cerințe?

# 2) Cerințe slabe - Citatul, Să știi ceva incomplet este periculos decât să nu știi deloc , este foarte adevărat atunci când vine vorba de a face față unei cerințe slabe.

Interpretarea unei cerințe slabe și punerea în aplicare a acestora reprezintă un risc mare.

  • Cum ați confirma că fereastra pop-up care afișează rezultatele căutării este valabilă sau nu atunci când singura cerință menționată a fost - rezultatele căutării ar trebui să fie corecte și nu sunteți sigur ce criterii ar trebui luate în considerare în timpul căutării.
  • Cum ați interpreta acest lucru - parola uitată ar trebui implementată pentru a facilita utilizatorului regenerarea / resetarea parolei uitate. Necunoscut despre fluxul de lucru pe care clientul îl dorește pentru parola uitată, dezvoltatorul implementează ceea ce crede că este cel mai bun și încep conflictele.

# 3) Cerințe conflictuale - A cere unei persoane să facă două lucruri diferite în același timp înseamnă doar a-l face confuz, iar sistemul nu este o excepție.

  • Cum ați testa o aplicație cu cerințele menționate sunt cele de mai jos:
    • Aplicația trebuie deschisă întotdeauna pe pagina de pornire.
    • Se așteaptă ca utilizatorii să se conecteze pentru a accesa aplicația.
  • Ce ați decide prioritatea atunci când documentul de cerință este după cum urmează:
    • Aplicația de jocuri ar trebui să promoveze utilizatorul la nivelul următor dacă utilizatorul obține 1000.
    • Utilizatorul ar trebui să fie redirecționat către pagina de abonament gratuită după ce va obține 1000.

Iată cum, cerințele rele, sărace și conflictuale creează bătăi de cap.

Fiind în industria software-ului, ar trebui să facă parte din proiect, deoarece uneori chiar și clientul nu este sigur ce anume doresc și cum să-l formuleze.

Din perspectiva testării, deși este dificil de gestionat aceste cerințe ambigue sau vagi, nu este complet imposibil.

Să analizăm posibilele soluții:

Cerințe necorespunzătoare și cum să le gestionați ca tester:

Metoda nr. 1)Explorează și învață:

Explorarea altor aplicații, învățarea despre comportamentul general așteptat, înțelegerea fluxului de lucru, gândirea la comoditatea utilizatorului și aplicarea logicii este o modalitate de a face față situației. De asemenea, bazându-se pe testarea exploratorie ar fi de ajutor în astfel de situații în care cerințele nu sunt clare.

De cele mai multe ori, este un bun pariu să acordați prioritate experienței utilizatorului și confortului atunci când cerințele nu sunt clare.

Metoda # 2)Utilizați experiența:

Folosiți experiența

Experiența domeniului , experiența generală de testare, problemele cu care se confruntă trecutul și cunoștințele personale pot ajuta la abordarea situațiilor și cerințelor confuze.

Metoda nr. 3)Consultați wireframe:

Wireframele sunt un fel de cerință vizuală în care puteți găsi mici detalii, iar aceste detalii pot fi foarte utile în crearea imaginii așteptate a produsului sau aplicației și ajută la acoperirea aspectelor de testare într-un mod mai bun.

Citeste mai mult => Wireframes - Ar trebui să fie testate cu adevărat? Și dacă da, cum?

Metoda # 4)Discuție de la egal la egal:

cum se scriu cazuri de test în foaia Excel

Discutie de la egal la egal

Indiferent care este confuzia, dacă se discută cu o grămadă potrivită de oameni, lucrurile se clarifică. Toată lumea poartă experiențe diferite, așteptări, vizualizare a utilizatorului și vizualizare a analizei și discutarea acestor cerințe slabe cu colegii va servi un avantaj al cristalizării înțelegerii și al sporirii încrederii în sine.

Metoda # 5)Clarificare de la client:

Clientul este proprietarul produsului / aplicației și este întotdeauna înțelept să îl abordați atunci când vine vorba de claritatea cerințelor. Dar nu uitați, nu este recomandabil să atacați clientul cu sute de întrebări. Înainte de a face acest lucru, sunt necesare niște teme.

Încercați să aflați cele mai bune practici disponibile, să înțelegeți avantajele implementării și apoi contactați clientul cu întrebări și soluții posibile.

Concluzie

În cele din urmă, cerințele vag definite sau nedefinite fac parte din viața testerului și trebuie să le acceptăm, dar să încercăm să fim optimiști și să stabilim soluții pentru aceasta. La urma urmei, suntem testeri, ajutăm la menținerea aplicațiilor pe drumul cel bun și protejăm-le împotriva căderii plate. DA pentru noi :)

Despre autor: Această postare de inspirație este scrisă de Bhumika M., membru al echipei STH. Este liderul proiectului, având peste 10 ani de experiență în testarea software-ului.

Testare fericită, ca de obicei ... .. așteaptă opiniile, comentariile și opiniile tale.

Lectură recomandată

^