Meni

Kako pregledati SRS dokument i stvoriti scenarije za testiranje - Trening za testiranje softvera na projektu uživo - 2. dan

how review srs document

Isprobajte Naš Instrument Za Uklanjanje Problema

Ovo je drugi tutorial u našem ‘Besplatni internetski trening za testiranje softvera na projektu uživo’ niz. Ako ste ovdje novi, provjerite prvi uvodni vodič: Kraj treninga za testiranje softvera na projektu uživo.

Krenimo sada u detaljnu analizu kako se događa prolazak kroz SRS, što je to što moramo prepoznati iz ovog koraka, koje korake moramo poduzeti prije nego što započnemo, koji su izazovi s kojima bismo se mogli suočiti itd. U detaljan način.

kako da otvorim json datoteku

Kako pregledati SRS dokument i stvoriti test scenarije_

SDLC-ova faza dizajna:

Sljedeća faza SDLC-a je 'Dizajn' - ovdje se funkcionalni zahtjevi prevode u tehničke detalje. U ovaj su korak uključeni timovi za razvoj, dizajn, okruženje i podatke. Ishod ovog koraka obično je tehnički projektni dokument - TDD.

Ulazni podatak je SRS dokument kako za stvaranje TDD-a, tako i za QA tim koji će početi raditi na QA aspektu projekta, a to je pregled SRS-a i utvrđivanje cilja ispitivanja.

Što ćete naučiti:

Što je pregled SRS-a?

SRS je dokument koji kreira razvojni tim u suradnji s poslovnim analitičarima i timovima za zaštitu okoliša / podataka. Tipično, ovaj dokument nakon finalizacije podijelit će se s QA timom putem sastanka na kojem je dogovoren detaljan opis.

Ponekad nam za već postojeću prijavu možda neće trebati službeni sastanak i netko tko će nas voditi kroz ovaj dokument. Za to bismo mogli imati potrebne informacije.

Pregled SRS-a nije ništa drugo nego prolazak kroz dokument specifikacije funkcionalnih zahtjeva i pokušaj razumijevanja kakva će biti ciljana aplikacija.

Službeni format i uzorak podijeljeni su sa svima vama u prethodnom članku. To ne znači nužno da će se svi SRS-ovi točno dokumentirati. Uvijek, oblik je sekundarni u odnosu na sadržaj .

Neki će timovi samo odlučiti napisati popis s oznakama, neki će timovi uključiti slučajeve upotrebe, neki će timovi uključiti uzorke snimaka zaslona (poput dokumenta koji smo imali), a neki samo opisuju detalje u odlomcima.

Prethodni koraci za pregled specifikacija softverskih zahtjeva

Korak 1) Dokumenti prolaze kroz više revizija, pa se pobrinite da imamo pravu verziju referenciranog dokumenta, SRS.

Korak 2) Uspostavite smjernice o tome što se očekuje na kraju pregleda od svakog člana tima. Drugim riječima, odlučite koji se rezultati očekuju od ovog koraka - obično je rezultat ovog koraka identificiranje testnih scenarija. Scenariji testiranja nisu ništa drugo do jednoredni pokazivači 'što testirati' za određenu funkcionalnost.

Korak # 3) Također utvrdite smjernice o načinu prikazivanja ovog rezultata - mislim, predloška.

Korak # 4) Odlučite hoće li svaki član tima raditi na cijelom dokumentu ili ga podijeliti između sebe. Preporučuje se da svi čitaju sve jer će to spriječiti koncentraciju znanja kod određenih članova tima.

Ali u slučaju velikog projekta, s dokumentima SRS koji imaju gotovo 1000 stranica, pristup razbijanja modula dokumenata i dodjeljivanja pojedinim članovima tima najpraktičniji je.

Korak # 5) Pregled SRS-a također pomaže u boljem razumijevanju postoje li posebni preduvjeti potrebni za testiranje softvera.

Korak # 6) Kao nusproizvod, navodi se popis upita kod kojih je neke funkcije teško razumjeti ili ako je potrebno dodati više informacija u funkcionalne zahtjeve ili ako se utvrde pogreške u SRS-u.

Što trebamo za početak?

  • Ispravna verzija dokumenta SRS
  • Jasne upute o tome tko će raditi na čemu i koliko vremena imaju.
  • Predložak za stvaranje testnih scenarija.
  • Ostale informacije o tome - koga kontaktirati u slučaju pitanja ili koga prijaviti u slučaju nedosljednosti dokumentacije

Tko bi pružio ove podatke?

Voditelji timova uglavnom su odgovorni za pružanje svih stavki navedenih u gornjem odjeljku. Međutim, doprinosi članova tima uvijek su važni za uspjeh cijelog ovog pothvata.

Voditelji timova često pitaju - Kakve vrste podataka? Ne bi li bilo bolje dodijeliti određeni modul nekome koga to zanima nego članu tima koji to nije? Ne bi li bilo lijepo odlučiti se za ciljni datum na temelju mišljenja tima, nego li im nanijeti odluku? Također, za uspjeh projekta važni su predlošci.

U pravilu, predlošci imaju veću stopu učinkovitosti kada su prilagođeni udobnosti i udobnosti određenog tima. Stoga treba imati na umu da su voditelji timova više od svega članovi tima. Uključivanje vašeg tima u svakodnevne odluke presudno je za nesmetano odvijanje projekta.

Je li predložak potreban za test scenarije?

Zašto predložak za testne scenarije - nije li dovoljno ako samo napravimo popis?

Sigurno jest. Međutim, softverski projekti nisu emisije 'one-man'. Oni uključuju timski rad .

Zamislite tim od 4 - 4 ako svaki od njih odluči pregledati po jedan modul specifikacije softverskih zahtjeva. Član tima A napravio je popis na listu papira. Član tima 2 koristio je excel list. Član tima 3 koristio je bilježnicu. Član tima 4 upotrijebio je riječ doc. Kako objediniti sav posao odrađen za projekt na kraju dana?

Također, kako možemo odlučiti koji je standard i kako možemo reći što je ispravno, a što nije ako nismo kreirali pravila, za početak?

To je ono što je predložak: Skup smjernica i dogovoreni format za ujednačenost i podudarnost cijelog tima.

Kako stvoriti predložak za scenarije QA testa?

Predlošci ne moraju biti složeni ili nefleksibilni.

Sve što trebaju biti učinkovit je mehanizam za stvaranje korisnog artefakta za testiranje. Nešto jednostavno poput onoga koje vidimo dolje:

predložak scenarija ispitivanja

Zaglavlje ovog predloška sadrži prostor potreban za prikupljanje osnovnih podataka o projektu, trenutnom dokumentu i referenciranom dokumentu.

Tablica u nastavku omogućit će nam izradu testnih scenarija. Uključeni stupci su:

koja je najbolja špijunska aplikacija za android

Stupac # 1) ID scenarija testa
Svaki entitet u našem procesu testiranja mora biti jedinstveno prepoznatljiv. Dakle, svakom testnom scenariju mora se dodijeliti ID. Moraju se definirati pravila koja se moraju pridržavati prilikom dodjele ovog ID-a.

Radi ovog članka slijedit ćemo konvenciju o imenovanju kao TS (prefiks koji označava Test Scenario) nakon čega slijedi ‘_’, naziv modula MI (My Info modul Orange HRM projekta), nakon čega slijedi ‘_’, a zatim pododjeljak ( Na primjer, MI za Moj info modul, Str za fotografiju i tako dalje) nakon čega slijedi serijski broj. Primjer bi mogao biti: 'TS_MI_MIM_01'.

Stupac # 2) Zahtjev
Pomaže kad bismo trebali stvoriti testni scenarij, te bismo ga mogli preslikati natrag u odjeljak SRS-ovog dokumenta odakle smo ga odabrali. Ako zahtjevi imaju ID-ove, mogli bismo to koristiti. Ako ne, brojevi odjeljaka ili čak brojevi stranica u SRS dokumentu odakle smo identificirali provjerljiv će zahtjev.

Stupac # 3) Opis scenarija ispitivanja
Jednoredna linija koja određuje 'što testirati'. Također bismo ga nazvali testnim ciljem.

Stupac # 4) Važnost
Ovo daje ideju o važnosti određene funkcije za AUT. Vrijednosti poput visoke, srednje i niske mogu se dodijeliti ovom polju. Možete odabrati i bodovni sustav, poput 1-5, 5 je najvažnije, 1 manje važno. Kakvu god vrijednost ovo polje moglo uzeti, mora se unaprijed odlučiti.

Stupac br. 5) Broj testnih slučajeva
Gruba procjena o tome koliko bismo pojedinačnih testnih slučajeva mogli na kraju napisati taj jedan testni scenarij. Na primjer, Da bismo testirali prijavu, uključujemo sljedeće situacije: Ispravite korisničko ime i lozinku. Ispravno korisničko ime i pogrešna lozinka. Točna lozinka i pogrešno korisničko ime. Dakle, potvrđivanje funkcionalnosti prijave rezultirat će u 3 testna slučaja.

Bilješka: Možete proširiti ovaj predložak ili ukloniti polja kako smatrate potrebnim.

Na primjer , možete dodati 'Reviewed by' u zaglavlje ili ukloniti datum stvaranja itd. Također u tablicu možete uključiti polje 'Created by' da biste odredili ispitivača odgovornog za određeni testni scenarij ili uklonili 'No. testnih slučajeva “. Tvoj izbor. Idite s onim što najbolje odgovara cijelom timu.

Pogledajmo sada naš Orange HRM SRS dokument i stvorimo test scenarije

Pro savjet: pogledajte sadržaj u uzorku SRS-a koji smo pružili u 1. vodičima kako biste stekli dobru ideju o tome kako će se odvijati bilo koji dokument i koliko bi posla mogao uključivati.

Odjeljak 1 je svrha dokumenta. Tamo nema provjerljivih zahtjeva.

Odjeljak 2.1 : Pregled projekta- Publika- ni tamo nema provjerljivih zahtjeva.

Odjeljak 2.2 : Hardver i hosting - Ovaj odjeljak govori o tome kako će web lokacija Orange HRM biti hostirana. Sad, jesu li ove informacije važne za nas testere? Odgovor je Da i Ne. Da, jer kada testiramo, moramo imati okruženje slično okruženju u stvarnom vremenu.

To nam daje ideju kako to treba biti. Ne, jer to nije provjerljiv zahtjev - vrsta preduvjeta da se testiranje dogodi.

Odjeljak 3: Ovdje se nalazi zaslon za prijavu i detalji vrste računa koji moramo imati za ulazak na web mjesto. Ovo je provjerljiv zahtjev. Dakle, to mora biti dio naših testnih scenarija.

Molimo pogledajte dokument scenarija ispitivanja gdje su dodani scenariji ispitivanja za nekoliko odjeljaka SRS-a. Za vježbanje, dodajte ostale scenarije na sličan način. Međutim, idem pravo na odjeljak 4 dokumenta.

Odjeljak 4: Estetski / HTML zahtjevi i smjernice - Ovaj odjeljak najbolje objašnjava kako neki zahtjevi možda neće imati smisla za testni tim u vrijeme pregleda SRS-a, ali tim bi ih trebao zabilježiti kao provjerljive zahtjeve.

Kako ih testirati i ako trebamo određenu postavku / pomoć bilo kojeg tima da to potvrdimo, detalji su koje u ovom trenutku možda nećemo znati. No, čineći ih dijelom našeg opsega testiranja, prvi je korak da ih ne propustimo.

Primjeri scenarija ispitivanja za aplikaciju OrangeHRM: (kliknite za uvećanje slike)

predložak scenarija ispitivanja

=> Molimo pogledajte i preuzmite dokument Test scenariji za više informacija.

Neke važne primjedbe u vezi s pregledom SRS-a

# 1) Nijedna informacija ne smije biti otkrivena.
#dva) Izvršite analizu izvedivosti je li određeni zahtjev točan ili nije, te može li se testirati ili ne.
# 3) Ako ne postoje zasebne performanse / zaštita ili bilo koji drugi oblik ispitnih timova, naš je posao osigurati da svi nefunkcionalni zahtjevi moraju biti uzeti u obzir.
# 4) Nisu sve informacije usmjerene na testere, pa je važno razumjeti što primijetiti, a što ne.
# 5) Važnost i br. test slučajeva za testni scenarij ne moraju biti točni i mogu se popuniti približnom vrijednošću ili mogu ostati prazni.

Da rezimiramo, SRS pregledava rezultate u:

  • Popis scenarija ispitivanja
  • Rezultati pregleda - Pogreške u dokumentaciji / zahtjevu pronađene statičkim prolaskom / provjerom SRS dokumenta
  • Popis pitanja za bolje razumijevanje - u slučaju da ih ima
  • Preliminarna ideja o tome kako bi trebalo izgledati testno okruženje
  • Identifikacija opsega testa i okvirna ideja o tome koliko bismo testnih slučajeva mogli završiti - pa koliko nam vremena treba za dokumentaciju i na kraju izvršenje.

Važne napomene:

# 1) Scenariji ispitivanja nisu vanjska isporuka (ne dijele se s poslovnim analitičarima ili razvojnim timovima), ali su važni za internu potrošnju osiguranja kvalitete. Oni su naš prvi korak prema 100-postotnom cilju pokrivenosti testom. Nakon završetka testnih scenarija proći će stručnu provjeru i nakon što se to učini, svi su objedinjeni.

Za više detalja o načinu pregleda QA dokumenata pogledajte članak: Kako izvršiti recenzije ispitne dokumentacije u 6 jednostavnih koraka.

#dva) Mogli bismo koristiti alat za upravljanje testovima poput HP ALM ili qTest za stvaranje testnih scenarija. Međutim, stvaranje testnih scenarija u stvarnom vremenu ručna je aktivnost. Po mom mišljenju prikladnije je ručno. Budući da je to korak 1, još ne moramo vaditi velike puške. Jednostavni excel listovi najbolji su način za to.

Sljedeći korak ove serije je taj - radit ćemo na stvaranju test slučajeva i ući dalje u fazu dizajniranja testova. Prije toga ćemo također ući u - Što je planiranje testa?Gdje se to uklapa u cjelokupni QA projekt? Kao i uvijek, radite s nama za najbolje rezultate.

QA trening dan 3: Kako napisati SRS dokument ispočetka.

Molimo vas da nastavite s pitanjima i komentarima. Cijenimo vašu čitateljstvo!

Preporučena literatura

^