Meniu

Cum se testează o aplicație fără cerințe?

how test an application without requirements

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Din punct de vedere tehnic, nu există aplicații fără cerințe. Imaginați-vă un software care nu face nimic specific, dar este pur și simplu linie după linie de cod care se întinde. Va fi o scară care nu duce nicăieri.

Toate software-urile au cerințe și vizează o anumită sarcină; în mod specific, este o soluție la o problemă. Asa de fără cerințe software-ul nu este o posibilitate.

Cu toate acestea, software-ul fără cerințe documentate este o realitate cu care, din păcate, majoritatea dintre noi ne confruntăm mai des cu asta ne place. Singurul lucru mai rău ar putea fi că documentația este insuficientă, inexactă sau teribil de depășită. Din păcate, și asta se întâmplă.

test fără cerințe

Sincer, nu există într-adevăr un substitut la un document de cerință funcțional / sistem bine documentat, cu cazuri de utilizare elaborate și ecrane de machetă. Deși trebuie să recunoaștem că acest lucru devine o raritate în industrie din cauza ciclurilor rapide de dezvoltare și a schimbării paradigmei către o documentare minimă sau deloc.

Prin urmare, acest articol este o încercare de a practica unele practici pe care le-am urmat atunci când ne-am găsit în aceste situații.

Citește și:

cele mai bune scanări și reparații gratuite ale computerului

Să ne uităm mai întâi la câteva motive pentru care s-ar putea să nu existe documentație, pentru început:

  1. Proiectul raft fiind redeschis
  2. Documentație mai puțin format de lucru - Proces
  3. Este posibil ca documentația să existe, dar poate să nu fie detaliată sau completă
  4. Versiunile continue și informațiile referitoare la versiunile mai vechi nu au fost arhivate, rezultând o lacună în înțelegerea modului în care reacționează funcționalitatea existentă cu cea nouă

Acestea sunt toate impedimente pe care noi testerii trebuie să le traversăm cu curaj și să ieșim cu succes. Dar exact cum, nu?

Iată cele mai bune 3 metode pentru a testa o aplicație fără cerințe:

Metoda nr. 1:

Lucrați cu orice documentație mică pe care o puteți pune. Ar putea fi un backlog simplu de bază (în proiecte agile), un fișier de ajutor, un e-mail, o versiune mai veche a BRD / FRD sau cazuri de testare vechi (verificați-le în instrumentele ALM și le-ați putea găsi) etc.

Investigați, întrebați în jur și există întotdeauna un proces documentat, chiar dacă este unul subțire.

Când acest lucru nu funcționează, nu renunțați la experiența dvs. ca utilizator de software.De exemplu, dacă trebuie să testați o operațiune de transfer pentru un cont bancar, nimeni nu trebuie să ne spună cum să facem acest lucru, nu-i așa? Pentru că, în calitate de clienți bancari online, știm cu toții că avem nevoie de la și către conturi cu un număr de fonduri disponibile pentru a fi transferate.

Am fost de acord că nu toate situațiile vor fi la fel de simple, dar din nou, ar putea fi și ele.

Metoda # 2:

Utilizați versiunea veche / actuală a aplicației ca referință pentru a testa lansarea viitoare a unui produs software. Acum, recunosc că acest lucru este în negare cu regula „Nu scrieți niciodată cazuri de testare folosind aplicația ca referință”. Cu toate acestea, atunci când lucrăm într-o situație mai puțin perfectă, trebuie să modelăm regulile pentru a se potrivi nevoilor noastre.

Vă ajută să păstrați următoarele aspecte în perspectivă atunci când faceți acest lucru:

  • Aplicația poate conține erori - deci dacă după înregistrare sistemul vă duce direct la Screen1 (un anumit ecran ipotetic de dragul exemplului nostru) - Nu presupuneți niciodată că acesta este comportamentul corect. De asemenea, dacă un câmp ia caractere alfanumerice și este un număr de telefon - o întrebare și asigurați-vă că nu luați aplicația ca exemplu acordat pentru funcționalitatea așteptată.
  • În situațiile de mai sus, folosiți-vă judecata și luați ajutorul aplicației pentru a vă da startul, dar fiți critic față de aceasta pentru a vă pune la îndoială că funcționează.

Metoda # 3:

Discutați cu membrii echipei de proiect:

  • Oferiți-vă să participați la întâlnirile lor.
  • Întrebați dacă puteți participa la unitatea și etapele de testare a integrării.
  • Dacă nu, întrebați dacă echipa de dezvoltatori poate partaja rezultatele testelor de unitate și de integrare.
  • Aranjați un timp pentru transferul de cunoștințe la un moment convenabil.

Acum, să aplicăm metodele într-un exemplu:

Să presupunem că există un site de cumpărături unde puteți adăuga articole în coșul de cumpărături. În mod ideal, dacă a existat documentație, trebuie să ne spună cum să îi adăugăm articole, câte articole poate avea la un moment dat, ce se întâmplă când articolul pe care l-ați adăugat se stinge brusc, care este numărul maxim din aceleași articole pe care le puteți cumpăra în același timp etc. Situația noastră este că NIMIC din acestea nu este disponibil în acest moment.

Aplicați metoda nr. 1:

Găsiți orice documentație pe care o puteți. Întrebați echipa de dezvoltatori dacă au ecrane machete / căutați în instrumentul ALM sau orice altceva. Dacă găsiți ceva, acesta ar fi un bun punct de plecare. Dar dacă această metodă nu arată nimic, atunci poți să folosești judecata / intuiția testerului.

Știm cu toții cum funcționează coșurile de cumpărături, deci faceți-vă presupunerile și ajungeți la câteva scenarii de bază, cum ar fi:

  • Articolele pot fi adăugate în coșul de cumpărături după ce a fost căutat sau căutat
  • Odată ce am adăugat articole în coșul de cumpărături, lista articolelor ar trebui actualizată
  • Utilizatorul ar trebui să poată continua să cumpere și după ce a adăugat câteva articole în coș
  • Adăugarea aceluiași articol de două ori va determina creșterea numărului de articole adăugate
  • Elementele pot fi actualizate
  • Articolele pot fi eliminate
  • Totalul ar trebui să fie echivalent cu suma tuturor prețurilor adăugate
  • Impozitele trebuie calculate pe baza codului poștal introdus
  • Costurile de expediere trebuie adăugate în consecință

Putem continua, dar sunt sigur că veți obține imaginea.

Aplicați metoda nr. 2:

Dacă există o versiune mai veche a aplicației disponibilă, acest lucru vă poate fi de ajutor în scrierea cazurilor de test, deoarece va trebui să scrieți pașii exacți de unde să faceți clic, unde să introduceți intrarea, ce să verificați etc. Capturi de ecran / machete / fire- cadre - dacă sunt disponibile, pot fi și înlocuitori excelenți.

După cum puteți vedea din ecranul de mai jos, aceste lucruri sunt evidente - numele câmpurilor, butoanele sau alte elemente prezente etc. (faceți clic pe imagine pentru vizualizare mărită)

test fără cerințe

Acum, în acest moment testerii au câteva întrebări, cum ar fi:

  1. Ce se întâmplă atunci când dau un char în caseta de sumă?
  2. Când adaug prea multe articole?
  3. Care este maximul nr. de articole pe care le poate lua? Etc.

Aplicați metoda nr. 3 :

Luați lista de întrebări către BA, dezvoltator sau chiar către client și solicitați clarificări. Odată ce metoda 3 este realizată, ar trebui să fiți echipat cu toate informațiile de care aveți nevoie pentru a scrie cazuri de testare detaliate și pentru a vă efectua testarea cu atât de multă încredere cât ați face atunci când documentația elaborată a fost disponibilă.

Am fost de acord că sunt mult mai mulți pași și mult mai multă urmărire, dar pentru a asigura testarea calității, acești pași sunt inevitabili.

În concluzie, totul nu se pierde atunci când documentația nu există sau este insuficientă. Încă mai există speranță! Vă rugăm să împărtășiți experiențele dvs. în situații similare.

Despre autor: Această postare utilă este scrisă de Swati S., membru al echipei noastre STH.

Ca întotdeauna comentariile, întrebările și sugestiile dvs. sunt binevenite.

Lectură recomandată

^