Meni

Kako testirati prijavu bez zahtjeva?

how test an application without requirements

Isprobajte Naš Instrument Za Uklanjanje Problema

Tehnički nema aplikacija bez zahtjeva. Zamislite softver koji ne radi ništa specifično, već se jednostavno širi red za retkom koda. To će biti stubište koje ne vodi nikamo.

Sav softver ima zahtjeve i usmjeren je na određeni zadatak; konkretno, to je rješenje problema. Tako bez zahtjeva softver nije mogućnost.

Međutim, softver bez dokumentiranih zahtjeva stvarnost je s kojom se nažalost većina nas češće suočava mi volimo. Jedino gore može biti to što je dokumentacija nedostatna, netočna ili užasno zastarjela. Nažalost, događa se i ovo.

test bez zahtjeva

Iskreno, stvarno nema zamjene za dobro dokumentirani dokument o funkcionalnim / sistemskim zahtjevima s složenim slučajevima korištenja i maketama zaslona. Iako moramo priznati da ovo postaje rijetkost u industriji zbog brzih razvojnih ciklusa i pomaka paradigme prema minimalnoj ili nikakvoj dokumentaciji.

Stoga je ovaj članak pokušaj nekih praksi koje smo slijedili kad smo se našli u tim situacijama.

Također pročitajte:

kako započeti karijeru u qa testiranju

Pogledajmo prvo nekoliko razlozi zašto možda ne postoji dokumentacija, za početak:

  1. Policijski projekt se ponovno otvara
  2. Dokumentacija bez formata radnog procesa
  3. Dokumentacija možda postoji, ali možda nije detaljna ili cjelovita
  4. Kontinuirana izdanja i podaci u vezi sa starijom verzijom nisu arhivirani što je rezultiralo prazninom u razumijevanju kako postojeća funkcionalnost reagira s novom

Sve su to prepreke koje mi ispitivači moramo hrabro prijeći i uspješno se pojaviti. Koliko točno točno, zar ne?

Evo tri najbolje metode za testiranje aplikacije bez zahtjeva:

Metoda # 1:

Radite s bilo kojom malo dokumentacije koja vam dođe pod ruku. To bi mogao biti osnovni jednostavan zaostatak (u agilnim projektima), datoteka pomoći, e-pošta, starija verzija BRD / FRD ili stari test slučajevi (provjerite ih u svojim ALM alatima i možda ćete ih pronaći) itd.

Istražite, raspitajte se i uvijek postoji neko dokumentirano suđenje, čak i ako je tanko.

Kad to ne uspije, nemojte popuštati svoje iskustvo kao korisnik softvera.Na primjer, ako morate testirati operaciju prijenosa za bankovni račun, nitko nam ne treba reći kako to učiniti, zar ne? Budući da kao klijenti internetskog bankarstva svi znamo da trebamo s računa na i s računa s većim brojem sredstava dostupnih za prijenos.

Složili smo se da neće sve situacije biti tako izravne, ali opet, mogle bi biti i previše.

Metoda # 2:

Koristite stariju / trenutnu verziju aplikacije kao referencu za testiranje budućeg izdanja softverskog proizvoda. Sada priznajem da ovo negativno utječe na pravilo: 'Nikad ne piši test slučajeve koristeći aplikaciju kao referencu'. Međutim, kada radimo u manje savršenoj situaciji, moramo oblikovati pravila koja će odgovarati našim potrebama.

Pomaže pri zadržavanju sljedećih aspekata u perspektivi:

  • Aplikacija može sadržavati bugove - pa ako vas nakon registracije sustav izravno odvede na Screen1 (određeni hipotetski zaslon radi našeg primjera) - Nikad ne pretpostavljajte da je to ispravno ponašanje. Također ako polje zauzima alfanumeričke znakove i ako je telefonski broj, pitanje je i pobrinite se da aplikaciju ne uzimate kao odobreni primjer za očekivanu funkcionalnost.
  • U gore navedenim situacijama upotrijebite svoju prosudbu i iskoristite pomoć aplikacije kako biste započeli, ali budite kritični prema njoj i postavite pitanje da li radi.

Metoda # 3:

Razgovarajte s članovima projektnog tima:

  • Ponudite se da prisustvujete njihovim sastancima.
  • Pitajte možete li sudjelovati u jedinicama i fazama testiranja integracije.
  • Ako nije, pitajte može li razvojni tim podijeliti svoje jedinice i rezultate testova integracije.
  • Dogovorite vrijeme za prijenos znanja u prikladno vrijeme.

Sada, primijenimo metode u primjeru:

Pretpostavimo da postoji web mjesto za kupnju na kojem možete dodati predmete u košaricu. U idealnom slučaju da postoji dokumentacija, treba nam reći kako joj dodati stavke, koliko predmeta može imati u određenom trenutku, što se događa kada stavka koju ste dodali iznenada nestane na zalihi, koji je maksimalan broj istih predmeta koje možete kupiti istovremeno, itd. Naša situacija je da NITKO od toga trenutno nije dostupno.

Primijeni metodu 1:

Pronađite bilo koju dokumentaciju koju biste mogli. Pitajte svoj razvojni tim imaju li makete zaslona / potražite alat ALM ili nešto slično. Ako nešto pronađete, to bi bilo dobro polazište. Ali ako ova metoda ništa ne pokaže, tada možete koristiti svoj prosudba / intuicija ispitivača.

Svi znamo kako funkcioniraju kolica za kupovinu, zato pretpostavite i dođite do nekoliko osnovnih scenarija kao što su:

  • Predmeti se mogu dodati u košaricu nakon pregledavanja ili pretraživanja
  • Jednom kad dodam stavke u košaricu, popis stavki trebao bi se osvježiti
  • Korisnik bi trebao moći nastaviti s kupnjom čak i nakon dodavanja nekoliko predmeta u košaricu
  • Dvostruko dodavanje iste stavke rezultirat će povećanjem broja dodanih stavki
  • Stavke se mogu ažurirati
  • Predmeti se mogu ukloniti
  • Ukupni iznos trebao bi biti jednak zbroju svih dodanih cijena
  • Porez bi se trebao izračunati na temelju unesenog poštanskog broja
  • U skladu s tim moraju se dodati troškovi dostave

Možemo nastaviti, ali siguran sam da ste shvatili.

Primijeni metodu 2:

Ako je dostupna starija verzija aplikacije, ovo može biti korisno za pisanje testnih slučajeva, jer ćete morati napisati točne korake kamo kliknuti, gdje unijeti unos, što provjeriti itd. Snimke zaslona / makete / žice- okviri - ako su dostupni, mogu biti i izvrsna zamjena.

Kao što možete vidjeti sa donjeg zaslona, ​​ove stvari su očite - nazivi polja, gumbi ili drugi prisutni elementi itd. (kliknite na sliku za uvećani prikaz)

test bez zahtjeva

U ovom trenutku testeri imaju nekoliko pitanja poput:

  1. Što se događa kada dam znak u polju s iznosom?
  2. Kada dodam previše stavki?
  3. Koji je maksimalni br. od predmeta koje ovo može potrajati? Itd.

Primijenite metodu # 3 :

Odnesite svoj popis pitanja BA-u, programeru ili čak klijentu i potražite pojašnjenje. Jednom kada je metoda 3 gotova, trebali biste biti u velikoj mjeri opremljeni svim informacijama koje su vam potrebne za pisanje detaljnih slučajeva ispitivanja i provođenje testiranja s toliko povjerenja kao što bi bilo kada bi bila dostupna detaljna dokumentacija.

Složili smo se da je puno više koraka i puno više praćenja, ali kako bi se osiguralo ispitivanje kvalitete, ti su koraci neizbježni.

U zaključku, sve se ne gubi kad dokumentacija ne postoji ili je nedostatna. Još uvijek ima nade! Molimo podijelite svoja iskustva u sličnim situacijama.

O autoru: Ovaj korisni post napisao je član našeg STH tima Swati S.

Kao i uvijek vaši komentari, pitanja i prijedlozi su dobrodošli.

Preporučena literatura

^