Meni

Testni scenarij i testni slučaj: Koja je razlika između njih?

test scenario vs test case

Razlika između scenarija ispitivanja i test slučaja.

Prije 6 godina , dok sam radio sa srednjim MNC-om, kad sam predložio dokumentiranje testnih scenarija, umjesto da gubim vrijeme na pripremu cjelovitog dokaznog dokumenta koji se naziva test slučajevi, sve su mi se glave dosađivale.

Izraz lica jasno je dokazivao da sam počinio veliku pogrešku sugerirajući je. Iako nitko nije negirao tu ideju, nitko nije ni prihvatio. Svi su smatrali da bi slijeđenje tradicije, tj. Pisanje dokumenata s testnih slučajeva, bilo sigurnije. Nisam mogao raspravljati.

Test scenarij protiv test slučaja

Nakon 4 godine , tvrtka je dobila projekt testiranja, gdje je jedino ograničenje bilo vrijeme, a jedino očekivanje bilo je potpun dokaz testiranje.

ai softver uči izrađivati ​​ai softver

Ponovno smo bili na sastanku i razgovarali smo o idejama kako bismo ispunili kritični rok. Aplikacija se uglavnom bavila pretraživanjem i generiranjem različitih izvještaja putem različitih stavki izbornika. Dokumentiranje testnih slučajeva trebalo je ugrabiti većinu vremena i nismo bili sigurni koliko će dokument klijentu koristiti.

Predložio sam dokumentiranje scenarija ispitivanja i nekako su se, uz oklijevanje, svi složili. Ne treba spominjati da bismo mogli uštedjeti dragocjeno vrijeme za dokumentaciju i iskoristiti je za testiranje.

Što ćete naučiti:

Da li se test slučajevi brzo zamjenjuju test scenarijima?

S vremenom, kako se sve mijenja, softverska industrija i procesi također su se puno promijenili.

Tradicionalno Slap i V-modeli zamjenjuju se pokretnim i iterativnim modelima. Potrebna je dokumentacija no kako bi se ispunili rokovi i postupak učinio lakim i transparentnim, način dokumentacije se može promijeniti.

Kada je dokumentacija o test slučajevima važna?

  1. Klijent je tražio isto kao dio projekta.
  2. Nema vremenskog ograničenja (mislim da to nije moguće).
  3. Ispitivači su svježi ili nepoznati proizvodu.
  4. Politika tvrtke (čvrsto vjerujem da se može promijeniti).

Dopustite mi da podijelim s vama jedno iskustvo:

Ja i moj tim bili smo uključeni u testiranje projekta tvrtke Fortune 500 s fleksibilnim vremenskim rokovima. Dokumentirali smo test slučajeve s najboljim dostupnim predloškom i odobrili ga klijentu.

Jednom kada je izrada počela puštati QA timu, veći dio dana bila nam je dužnost, mehanički pratiti 100 testnih slučajeva dnevno, ažurirati dokument rezultatom prolaska / neuspjeha i poslati ga klijentu na kraju dana. Većina članovi tima počeli su se žaliti monotono djelo ali tvrtka je stvarala prihod.

Zatim je uslijedila stanka na jedan dan, bez nove gradnje za testiranje. Sjeli smo zajedno na početku dana i raspravljali o tome što ćemo učiniti za taj dan. Kad sam predložio generiranje više ideja za poboljšanje dokumenta o testnom slučaju, svi su članovi tima poricali ulaganje napora.

Što se njih tiče, više se nije imalo o čemu razmišljati jer smo pokrili sve scenarije. I uvjeriti ih da razmišljajte izvan okvira i generirajte više ideja bilo stvarno teško.

Većinu vremena, kada dokumentiramo test slučajeve i to i nakon što ih klijent odobri, taj ljudski um misli da smo odradili svoj posao i naš um automatski prestaje razmatrati bilo kakav napor da razmišlja o drugim načinima za testiranje proizvoda.

I vjerujte mi, kad se pripremi dokument o testnim slučajevima, mi ga samo želimo mehanički pratiti. Recite mi koliko ste puta u svojoj karijeri doživjeli da ste vi ili suigrač ponudili dodatne ispitne slučajeve uz odobreni dokument o testnim slučajevima?

Još jedno iskustvo:

Tijekom tjednih aktivnosti timskog izazova, najavili smo prijavu i zamolili članove tima da ulijeju testne scenarije.

kako reproducirati torrent datoteku

Svi članovi tima, uključujući one koji kasne ili oni koji ne reagiraju, daju ideje. Zašto? Nije bilo formalne dokumentacije u kojoj su morali ispuniti očekivani rezultat za svaki slijed funkcionalnosti i preduvjeta za svaki testni slučaj. Dnevno smo prikupili 40 testnih scenarija i to je bilo izvrsno iskustvo.

Da favoriziram svoje iskustvo, Iznio bih primjer.

Uzmite uzorak aplikacije, recimo stranicu za prijavu s gumbima za korisničko ime, lozinku, prijavu i otkazivanje. Ako se od nas zatraži da napišete testne slučajeve, na kraju ćemo napisati više od 50 testnih slučajeva kombinirajući različite opcije i detalje.

Ali ako će se napisati testni scenariji, bit će potrebno 10 redaka kao u nastavku:

Scenarij na visokoj razini: Funkcionalnost prijave
Scenariji niske razine :

1. Da biste provjerili pokreće li se aplikacija
2. Da biste provjerili tekstualni sadržaj na stranici za prijavu
3. Da biste provjerili polje Korisničko ime
4. Da biste provjerili polje Lozinka
5. Provjeriti gumb za prijavu i otkazati funkciju gumba

Vidi također=> 180+ uzornih scenarija za testiranje web i desktop aplikacija.

Kako nam svima nedostaje vremena, scenariji ispitivanja djeluju kao sprej protiv bolova, a ne kao stari IODEX. I dalje, učinak je isti.

Razlike između scenarija ispitivanja i test slučaja u tabličnom formatu

Na kraju, želio bih sažeti razliku između Testnog scenarija i Testnog slučaja:

Ispitni slučajeviTestni scenariji
Što je to => Koncept koji pruža detaljne informacije što testirati, korake koje treba poduzeti i očekivani rezultat istihKoncept koji pruža informacije u jednom retku o tome što testirati.
Riječ je o => Više se radi o dokumentiranju detalja.Više se radi o razmišljanju i raspravi o detaljima.
Važnost => Važno je kada je testiranje isključeno, a razvoj je na licu mjesta. Pisanje testnih slučajeva s pojedinostima pomoći će sinkronizaciji i razvojnog i QA tima.Važno je kad je vremena manje i većina članova tima može se složiti / razumjeti detalje iz jednog liner scenarija.
Prednost => Jednokratna dokumentacija svih testnih slučajeva korisna je za praćenje 1000 krugova regresijskog testiranja u budućnosti.
Većinu vremena korisno je dok prijavljujete greške. Tester mora dati referencu ID-a test slučaja i ne zahtijeva spominjanje svake pojedinosti.
Ušteda vremena i aktivnost generiranja ideja, koju preferira zajednica za testiranje softvera nove generacije.
Izmjena i dodavanje je jednostavno i nije specifično za osobu.
Za ogroman projekt, gdje skupina ljudi poznaje samo određene module, ova aktivnost daje priliku svima da pogledaju druge module i oluju mozga i rasprave
Korisno za => Potpuno dokazani testni slučaj spas je života novog ispitivača.Dobra pokrivenost testom može se postići podjelom primjene u testnim scenarijima i smanjuje ponovljivost i složenost proizvoda
Nedostatak => Zahtjeva vrijeme i novac jer zahtijeva više resursa za detaljno objašnjenje svega što testirati i kako testiratiAko ga je stvorila određena osoba, recenzent ili drugi korisnik možda neće sinkronizirati točnu ideju koja stoji iza toga. Trebate više rasprava i timskih napora.

Zaključak

Test slučajevi su najvažniji dio životnog ciklusa razvoja softvera i bez njega je teško nešto pratiti, razumjeti, slijediti i obrazložiti. Ali u eri Agile, test slučajevi se brzo zamjenjuju test scenarijima.

Zajednicko ispitni kontrolni popis za svaku vrstu testiranja (testiranje baze podataka, testiranje grafičkog sučelja, funkcionalnost itd.), zajedno sa scenarijima testiranja, predstavlja moderno topništvo za softverske testere. Rasprave, trening, pitanja i vježbanje definitivno mogu promijeniti konačni grafikon svoju produktivnost kao i matrica izvještaja o greškama.

Kao i obično, pozdravljamo vaše misli i upite. Molim vas, prilagodite se.

PREV Vodič | SLJEDEĆA Vodič

Preporučena literatura

^