Meny

Hur man granskar SRS-dokument och skapar testscenarier - programvarutestning i ett liveprojekt - dag 2

  • Huvud
  • Programvarutestmallar
  • Hur man granskar SRS-dokument och skapar testscenarier - programvarutestning i ett liveprojekt - dag 2

how review srs document

Prova Vårt Instrument För Att Eliminera Problem

Detta är den andra självstudien i vår ”Gratis online-programvarutestning i ett liveprojekt” serier. Om du är ny här, kolla in den första introduktionshandledningen: Slut till slut utbildningsprogram för testning av programvara på ett live-projekt.

Låt oss nu gå in i en detaljerad analys av hur en SRS-genomgång händer, vad är det vi behöver identifiera från detta steg, vilka försteg vi måste ta innan vi börjar, vilka utmaningar vi kan möta, etc. i ett detaljerat sätt.

Hur man granskar SRS-dokument och skapar testscenarier_

SDLC: s designfas:

Nästa fas av SDLC är ”Design” - det är där funktionskraven översätts till de tekniska detaljerna. Dev, design, miljö och datateam är involverade i detta steg. Resultatet av detta steg är vanligtvis ett tekniskt designdokument - TDD.

Ingången är SRS-dokumentet både för skapandet av TDD och för att QA-teamet ska börja arbeta med QA-aspekten av projektet - vilket är att granska SRS och identifiera testmålet.

Vad du kommer att lära dig:

Vad är en SRS-granskning?

SRS är ett dokument som skapas av utvecklingsteamet i samarbete med affärsanalytiker och miljö / datateam. Normalt kommer detta dokument att slutföras med QA-teamet via ett möte där en detaljerad genomgång ordnas.

Ibland, för en redan existerande ansökan, behöver vi kanske inte ett formellt möte och någon som guidar oss genom detta dokument. Vi kan ha nödvändig information för att göra det själv.

SRS-granskning är inget annat än att gå igenom funktionskravspecifikationsdokumentet och försöka förstå hur målapplikationen kommer att bli.

Det formella formatet och ett exempel delades med er alla i föregående artikel. Det betyder inte nödvändigtvis att alla SRS kommer att dokumenteras exakt. Alltid, den form är sekundär till innehållet .

Vissa lag väljer bara att skriva en punktlista, vissa lag kommer att använda användningsfall, vissa lag kommer att innehålla exempel på skärmdumpar (som dokumentet vi hade) och andra beskriver bara detaljerna i stycken.

Försteg till granskning av specifikationer för programvarukrav

Steg 1) Dokument går igenom flera versioner, så se till att vi har rätt version av det refererade dokumentet, SRS.

Steg 2) Upprätta riktlinjer för vad som förväntas i slutet av granskningen från varje teammedlem. Med andra ord, bestäm vilka leveranser som förväntas från detta steg - typiskt är resultatet av detta steg att identifiera testscenarierna. Testscenarier är ingenting annat än en rad pekar på 'vad man ska testa' för viss funktionalitet.

Steg 3) Upprätta också riktlinjer för hur denna leverans ska presenteras - jag menar mallen.

Steg 4) Bestäm om varje medlem i teamet ska arbeta med hela dokumentet eller dela det med varandra. Det rekommenderas starkt att alla läser allt eftersom det förhindrar kunskapskoncentration hos vissa gruppmedlemmar.

Men i händelse av ett enormt projekt, med SRS-dokument som körs nära 1000 sidor, är metoden att bryta upp dokumentmodulen klokt och tilldela till enskilda teammedlemmar mest praktisk.

hur man kör jar-fil på Windows 10

Steg # 5) SRS-granskning hjälper också till att bättre förstå om det finns några specifika förutsättningar som krävs för testning av programvaran.

Steg # 6) Som en biprodukt identifieras en lista med frågor där vissa funktioner är svåra att förstå eller om mer information behöver integreras i funktionella krav eller om misstag görs i SRS.

Vad behöver vi för att komma igång?

  • Rätt version av SRS-dokumentet
  • Tydliga instruktioner om vem som ska arbeta med vad och hur mycket tid de har.
  • En mall för att skapa testscenarier.
  • Övrig information om vem man ska kontakta vid en fråga eller vem man ska rapportera om det inte finns någon dokumentation

Vem skulle ge denna information?

Teamledare är generellt ansvariga för att tillhandahålla alla artiklar som listas i avsnittet ovan. Teammedlemmarnas insatser är dock alltid viktiga för framgången för hela denna strävan.

Teamledare frågar ofta - Vilken typ av insatser? Skulle det inte vara bättre att tilldela en viss modul till någon som är intresserad av den än till en lagmedlem som inte är det? Skulle det inte vara trevligt att bestämma måldatumet baserat på lagets åsikt än att fatta ett beslut på dem? Dessutom är mallar viktiga för att ett projekt ska lyckas.

I allmänhet har mallar högre effektivitet när de skräddarsys för det specifika teamets bekvämlighet och komfort. Det bör därför noteras att teamledare mer än någonting är teammedlemmar. Att få ditt team ombord på de dagliga besluten är avgörande för att projektet ska fungera smidigt.

Krävs mall för testscenarier?

Varför en mall för testscenarier - räcker det inte om vi bara gör en lista?

Visst är det. Mjukvaruprojekt är emellertid inte 'enmansvis'. De involverar lagarbete .

hur man öppnar .eps-filer

Föreställ dig ett team på 4 - om var och en av dem bestämmer sig för att granska en modul av programvarukravsspecifikationen vardera. Teammedlem A har gjort en lista på ett pappersark. Teammedlem 2 använde ett excel-ark. Teammedlem 3 använde ett anteckningsblock. Teammedlem 4 använde ett ord doc. Hur konsoliderar vi allt arbete som utförts för projektet i slutet av dagen?

Hur kan vi också bestämma vilken som är standarden och hur kan vi säga vad som är rätt och vad som inte är om vi till att börja med inte skapade reglerna?

Det är vilken mall som är: En uppsättning riktlinjer och ett överenskommet format för enhetlighet och samstämmighet för hela laget.

Hur skapar jag en mall för QA-testscenarier?

Mallar behöver inte vara komplicerad eller oflexibel.

Allt de behöver vara är en effektiv mekanism för att skapa en användbar testartefakt. Något enkelt som det vi ser nedan:

testscenarimall

Rubriken i den här mallen innehåller det utrymme som krävs för att fånga grundläggande information om projektet, det aktuella dokumentet och det refererade dokumentet.

I tabellen nedan kan vi skapa testscenarier. Kolumnerna ingår:

Kolumn 1) Testscenario-ID
Varje enhet i vår testprocess måste kunna identifieras unikt. Så varje testscenario måste tilldelas ett ID. Reglerna som ska följas vid tilldelning av detta ID måste definieras.

För denna artikel kommer vi att följa namngivningskonventionen som TS (prefix som står för testscenario) följt av '_', modulnamn MIG (Min infomodul i Orange HRM-projektet) följt av '_' och sedan underavsnittet ( Till exempel, MIG för min infomodul, P för fotografi och så vidare) följt av ett serienummer. Ett exempel skulle vara: “TS_MI_MIM_01”.

Kolumn 2) Krav
Det hjälper att när vi skapar ett testscenario ska vi kunna kartlägga det tillbaka till avsnittet i SRS-dokumentet där vi valde det. Om kraven har ID kan vi använda det. Om inte sektionsnummer eller jämna sidnummer i SRS-dokumentet varifrån vi identifierade ett testbart krav kommer att göra.

Kolumn 3) Beskrivning av testscenario
En one-liner som anger 'vad man ska testa'. Vi skulle också hänvisa till det som testmålet.

Kolumn 4) Betydelse
Detta för att ge en uppfattning om hur viktigt vissa funktioner är för AUT. Värden som hög, medel och låg kan tilldelas detta fält. Du kan också välja ett punktsystem, som 1-5, 5 är viktigast, 1 är mindre viktig. Oavsett vilket värde detta fält kan ta måste det förutbestämas.

Kolumn 5) Antal testfall
En grov uppskattning av hur många enskilda testfall vi kan sluta skriva det enda testscenariot. Till exempel, För att testa inloggningen inkluderar vi följande situationer: Rätt användarnamn och lösenord. Rätt användarnamn och fel lösenord. Rätt lösenord och fel användarnamn. Validering av inloggningsfunktionen resulterar i tre testfall.

Notera: Du kan utöka den här mallen eller ta bort fälten efter eget gottfinnande.

Till exempel , kan du lägga till 'Granskad av' i rubriken eller ta bort datumet för skapandet etc. Du kan också ta med fältet 'Skapat av' för att ange testaren som är ansvarig för ett visst testscenario eller ta bort 'Nej. av testfall ”kolumn. Valet är ditt. Gå med det som fungerar bäst för hela teamet.

Låt oss nu granska vårt Orange HRM SRS-dokument och skapa testscenarier

Proffstips: kolla in innehållsförteckningen i SRS-provet som vi gav i första handledning för att få en god uppfattning om hur alla dokument kommer att flöda och hur mycket arbete det kan innebära.

Sektion 1 är syftet med dokumentet. Inga testbara krav där.

Avsnitt 2.1 : Projektöversikt - Publik - inga testbara krav där heller.

Avsnitt 2.2 : Maskinvara och webbhotell - Detta avsnitt talar om hur Orange HRM-webbplatsen kommer att vara värd. Är denna information viktig för oss testare? Svaret är Ja och Nej. Ja, för när vi testar måste vi ha en miljö som liknar realtidsmiljön.

Detta ger oss en uppfattning om hur det måste vara. Nej, för det är inte ett testbart krav - en slags förutsättning för att testningen ska ske.

Avsnitt 3: Det finns en inloggningsskärm här och detaljerna om vilken typ av konto vi behöver för att komma in på webbplatsen. Detta är ett testbart krav. Så det måste vara en del av våra testscenarier.

Se testscenariedokumentet där testscenarier för några avsnitt av SRS har lagts till. För övning, lägg till resten av scenarierna på ett liknande sätt. Men jag går direkt till avsnitt 4 i dokumentet.

Avsnitt 4: Estetiska / HTML-krav och riktlinjer - Detta avsnitt förklarar bäst hur vissa krav kanske inte är vettiga för testteamet vid tidpunkten för SRS-granskningen, men teamet bör göra en anteckning om dem som testbara krav.

Hur vi testar dem och om vi behöver specifika inställningar / något teams hjälp för att validera det är detaljer som vi kanske inte känner till just nu. Men att göra dem till en del av vårt testomfång är det första steget för att se till att vi inte missar dem.

Exempel på testscenarier för OrangeHRM-applikation: (klicka för att förstora bilden)

testscenarimall

bästa gratis systemrenare windows 10

=> Se och ladda ner testscenariedokumentet för mer information.

Några viktiga observationer angående SRS-granskning

# 1) Ingen information får lämnas ut.
#två) Utför genomförbarhetsanalys om ett visst krav är korrekt eller inte och även om det kan testas eller inte.
# 3) Om det inte finns en separat prestanda / säkerhet eller någon annan form av testteam, är det vårt jobb att se till att alla icke-funktionella krav måste beaktas.
# 4) Inte all information riktar sig till testarna, så det är viktigt att förstå vad man ska notera och vad inte.
# 5) Vikten och nej. av testfall för ett testscenario behöver inte vara korrekta och kan fyllas i med ett ungefärligt värde eller kan lämnas tomma.

Sammanfattningsvis resulterar SRS-granskning i:

  • Testa listan över scenarier
  • Granskningsresultat - Dokumentation / krav på fel som hittats genom att statiskt gå igenom / verifiera SRS-dokumentet
  • En lista med frågor för bättre förståelse - om det finns några
  • Den preliminära idén om hur testmiljön ska vara
  • Testomfattningsidentifiering och en grov uppfattning om hur många testfall vi kan få - så mycket tid vi behöver för dokumentation och så småningom utförande.

Viktiga punkter att notera:

# 1) Testscenarier är inte externa leveranser (delas inte med affärsanalytiker eller Dev-team) utan är viktiga för intern QA-konsumtion. De är vårt första steg mot ett 100% testtäckningsmål. Testscenarier när de är färdiga genomgår en peer review och när det är gjort konsolideras de alla.

För mer information om hur QA-dokument granskas, kolla in artikeln: Hur man utför testdokumentationsgranskningar i sex enkla steg.

#två) Vi kan använda ett testhanteringsverktyg som HP ALM eller qTest för att skapa testscenarierna. Men testscenarier i realtid är en manuell aktivitet. Enligt min mening är det bekvämare manuellt. Eftersom det är steg 1 behöver vi inte ta fram de stora kanonerna än. Enkla Excel-ark är det bästa sättet att göra det.

Nästa steg till denna serie är att - vi kommer att arbeta med att skapa testfall och komma längre in i testdesignfasen. Innan det kommer vi också in i - Vilken testplanering är?Var passar det in i hela QA-projektet? Arbeta som alltid med oss ​​för bästa resultat.

QA-träningsdag 3: Hur man skriver ett SRS-dokument från grunden.

Vänligen behåll dina frågor och kommentarer. Vi uppskattar din läsekrets massor!

Rekommenderad läsning

^