Menu

Sådan gennemgår du SRS-dokument og opretter testscenarier - Software Testing Training på et live projekt - dag 2

how review srs document

Prøv Vores Instrument Til At Fjerne Problemer

hvad kan du gøre med c ++

Dette er den anden tutorial i vores 'Gratis online software testningstræning på et live projekt' serie. Hvis du er ny her, skal du tjekke den første introduktionsvejledning: Afslut til slut software-testtræning på et live-projekt.

Lad os nu gå ind i en detaljeret analyse af, hvordan en SRS-gennemgang sker, hvad er det, vi skal identificere fra dette trin, hvilke for-trin, vi skal tage, inden vi begynder, hvad er de udfordringer, vi kan stå over for osv. I en detaljeret måde.

Sådan gennemgår du SRS-dokument og opretter testscenarier_

SDLCs designfase:

Den næste fase af SDLC er 'Design' - det er her, funktionskravene oversættes til de tekniske detaljer. Dev, design, miljø og datateam er involveret i dette trin. Resultatet af dette trin er typisk et teknisk designdokument - TDD.

Input er SRS-dokumentet både til oprettelse af TDD og for QA-teamet til at begynde at arbejde med QA-aspektet af projektet - som er at gennemgå SRS og identificere testmålsætningen.

Hvad du lærer:

Hvad er en SRS-gennemgang?

SRS er et dokument, der er oprettet af udviklingsteamet i samarbejde med forretningsanalytikere og miljø / datateams. Normalt vil dette dokument, når det er afsluttet, blive delt med QA-teamet via et møde, hvor der arrangeres en detaljeret gennemgang.

Nogle gange har vi muligvis ikke brug for et formelt møde for en allerede eksisterende ansøgning og nogen der guider os gennem dette dokument. Vi har muligvis de nødvendige oplysninger til at gøre dette alene.

SRS-gennemgang er intet andet end at gennemgå dokumentet om specifikation af funktionelle krav og forsøge at forstå, hvordan målapplikationen vil være.

Det formelle format og en prøve blev delt med jer alle i den foregående artikel. Det betyder ikke nødvendigvis, at alle SRS'er skal dokumenteres nøjagtigt. Altid, den form er sekundær i forhold til indholdet .

Nogle hold vælger bare at skrive en liste med punktopstillinger, nogle hold inkluderer brugssager, nogle hold inkluderer eksempler på skærmbilleder (som det dokument, vi havde), og nogle beskriver bare detaljerne i afsnit.

Forudgående trin til gennemgang af specifikationer til softwarekrav

Trin 1) Dokumenter gennemgår flere revisioner, så sørg for, at vi har den rigtige version af det refererede dokument, SRS.

Trin 2) Lav retningslinjer for, hvad der forventes i slutningen af ​​gennemgangen fra hvert teammedlem. Med andre ord, vælg hvilke leverancer der forventes fra dette trin - resultatet af dette trin er typisk at identificere testscenarierne. Testscenarier er intet andet end en linjemarkering af 'hvad man skal teste' for visse funktioner.

Trin # 3) Opret også retningslinjer for, hvordan denne leverance skal præsenteres - jeg mener, skabelonen.

Trin # 4) Beslut om, hvorvidt hvert medlem af teamet skal arbejde på hele dokumentet eller dele det indbyrdes. Det anbefales stærkt, at alle læser alt, for det forhindrer videnkoncentration hos bestemte teammedlemmer.

Men i tilfælde af et kæmpe projekt med SRS-dokumenter, der kører tæt på 1000 sider, er fremgangsmåden med at opdele dokumentmodulet klogt og tildele til individuelle teammedlemmer mest praktisk.

Trin # 5) SRS-gennemgang hjælper også med bedre forståelse, hvis der kræves specifikke forudsætninger for test af softwaren.

Trin # 6) Som et biprodukt identificeres en liste over forespørgsler, hvor visse funktioner er vanskelige at forstå, eller hvis flere oplysninger skal integreres i funktionelle krav, eller hvis der begås fejl i SRS.

Hvad har vi brug for for at komme i gang?

  • Den korrekte version af SRS-dokumentet
  • Tydelige instruktioner om, hvem der skal arbejde med hvad, og hvor lang tid har de.
  • En skabelon til oprettelse af testscenarier.
  • Andre oplysninger om, hvem man skal kontakte i tilfælde af et spørgsmål, eller hvem man skal rapportere i tilfælde af manglende dokumentation

Hvem ville give disse oplysninger?

Teamledere er generelt ansvarlige for at levere alle de poster, der er anført i afsnittet ovenfor. Teammedlemmernes input er dog altid vigtige for succesen med hele denne bestræbelse.

Teamledere spørger ofte - Hvilken type input? Ville det ikke være bedre at tildele et bestemt modul til en person, der er interesseret i det, end et teammedlem, der ikke er det? Ville det ikke være rart at beslutte på måldatoen ud fra holdets mening end at træffe en beslutning om dem? Også for et projekts succes er skabeloner vigtige.

Som hovedregel har skabeloner en højere effektivitetsgrad, når de er skræddersyet til det specifikke teams bekvemmelighed og komfort. Det skal derfor bemærkes, at teamledere mere end noget andet er teammedlemmer. At få dit team ombord på de daglige beslutninger er afgørende for, at projektet kører problemfrit.

Er skabelon påkrævet til testscenarier?

Hvorfor en skabelon til testscenarier - er det ikke nok, hvis vi bare laver en liste?

Helt sikkert. Imidlertid er softwareprojekter ikke 'one-man' shows. De involverer samarbejde .

Forestil dig et team på 4 - hvis hver enkelt af dem beslutter at gennemgå et modul af softwarekravsspecifikationen hver. Teammedlem A har lavet en liste på et ark papir. Teammedlem 2 brugte et excel-ark. Teammedlem 3 brugte et notesblok. Teammedlem 4 brugte et ord doc. Hvordan konsoliderer vi alt det arbejde, der er udført for projektet i slutningen af ​​dagen?

Hvordan kan vi også beslutte, hvilken standard der er, og hvordan kan vi sige, hvad der er rigtigt, og hvad der ikke er, hvis vi ikke oprettede reglerne til at begynde med?

hvordan man åbner torrentede filer på mac

Det er, hvad skabelon er: Et sæt retningslinjer og et aftalt format for ensartethed og overensstemmelse for hele holdet.

Hvordan oprettes en skabelon til QA-testscenarier?

Skabeloner behøver ikke at være kompliceret eller ufleksibel.

Alt, hvad de skal være, er en effektiv mekanisme til at skabe en nyttig testgenstand. Noget simpelt som det, vi ser nedenfor:

test scenarier skabelon

Overskriften på denne skabelon indeholder den nødvendige plads til at indfange grundlæggende oplysninger om projektet, det aktuelle dokument og det refererede dokument.

I nedenstående tabel kan vi oprette testscenarier. Kolonnerne inkluderet er:

Kolonne nr. 1) Testscenario-id
Hver enhed i vores testproces skal kunne identificeres entydigt. Så hvert testscenarie skal tildeles et ID. De regler, der skal følges under tildeling af dette ID, skal defineres.

Af hensyn til denne artikel vil vi følge navngivningskonventionen som TS (præfiks, der står for testscenarie) efterfulgt af '_', modulnavn MIG (Mit infomodul i Orange HRM-projektet) efterfulgt af '_' og derefter underafsnittet ( For eksempel, MIG til mit infomodul, P til fotografi og så videre) efterfulgt af et serienummer. Et eksempel ville være: “TS_MI_MIM_01”.

Kolonne nr. 2) Krav
Det hjælper, at når vi opretter et testscenarie, skal vi være i stand til at kortlægge det tilbage til det afsnit i SRS-dokumentet, hvor vi valgte det fra. Hvis kravene har ID'er, kan vi bruge det. Hvis ikke sektionsnumre eller lige sider i SRS-dokumentet, hvorfra vi identificerede et testbart krav, vil gøre.

Kolonne nr. 3) Testscenariobeskrivelse
En one-liner, der specificerer 'hvad der skal testes'. Vi vil også henvise til det som testmål.

Kolonne nr. 4) Vigtighed
Dette er for at give en idé om, hvor vigtig visse funktioner er for AUT. Værdier som høj, medium og lav kan tildeles dette felt. Du kan også vælge et punktsystem, som 1-5, 5 er vigtigst, 1 er mindre vigtigt. Uanset hvilken værdi dette felt kan tage, skal det forudbestemmes.

Kolonne nr. 5) Antal testsager
Et groft skøn over, hvor mange individuelle testsager, vi måske ender med at skrive det ene testscenarie. For eksempel, For at teste login - inkluderer vi disse situationer: Ret brugernavn og adgangskode. Ret brugernavn og forkert adgangskode. Korrekt adgangskode og forkert brugernavn. Så validering af loginfunktionen vil resultere i 3 testsager.

Bemærk: Du kan udvide denne skabelon eller fjerne felterne, som du finder passende.

For eksempel , kan du tilføje “Bedømt af” i overskriften eller fjerne oprettelsesdatoen osv. Også i tabellen kan du medtage et felt “Oprettet af” for at angive testeren, der er ansvarlig for et bestemt testscenarie, eller fjerne “Nej. af testsager ”-kolonnen. Det er dit valg. Gå med det, der fungerer bedst for hele teamet.

Lad os nu gennemgå vores Orange HRM SRS-dokument og oprette testscenarierne

Pro Tip: tjek indholdsfortegnelsen i SRS-prøven, vi leverede i 1. vejledning, for at få en god idé om, hvordan ethvert dokument vil flyde, og hvor meget arbejde det kan involvere.

Afsnit 1 er formålet med dokumentet. Ingen testbare krav der.

Afsnit 2.1 : Projektoversigt - Publikum - heller ikke testbare krav der.

Afsnit 2.2 : Hardware og hosting - Dette afsnit taler om, hvordan Orange HRM-webstedet skal hostes. Er disse oplysninger vigtige for os testere? Svaret er ja og nej. Ja, for når vi tester, skal vi have et miljø, der svarer til realtidsmiljøet.

Dette giver os en idé om, hvordan det skal være. Nej, for det er ikke et testbart krav - en slags forudsætning for, at testen kan ske.

Afsnit 3: Der er en login-skærm her og detaljerne om den type konto, vi skal bruge for at komme ind på siden. Dette er et testbart krav. Så det skal være en del af vores testscenarier.

Se testscenariedokumentet, hvor testscenarier for nogle få afsnit af SRS er tilføjet. For øvelse skal du tilføje resten af ​​scenarierne på en lignende måde. Jeg går dog lige til afsnit 4 i dokumentet.

Afsnit 4: Æstetiske / HTML-krav og retningslinjer - Dette afsnit forklarer bedst, hvordan nogle krav måske ikke giver mening for testteamet på tidspunktet for SRS-gennemgangen, men holdet bør notere dem som testbare krav.

Hvordan man tester dem, og hvis vi har brug for en specifik opsætning / et teams hjælp til at validere det, er detaljer, som vi muligvis ikke kender på dette tidspunkt. Men at gøre dem til en del af vores testomfang er det første skridt til at sikre, at vi ikke går glip af dem.

Eksempel på testscenarier til OrangeHRM-applikation: (klik for at forstørre billedet)

test scenarier skabelon

=> Se og download testscenariedokumentet for mere information.

Nogle vigtige bemærkninger vedrørende SRS-gennemgang

# 1) Ingen oplysninger skal efterlades afdækket.
#to) Udfør gennemførlighedsanalyse af, om et bestemt krav er korrekt eller ej, og også om det kan testes eller ej.
# 3) Medmindre der findes en separat præstation / sikkerhed eller nogen anden form for testteam, er det vores opgave at sikre, at alle ikke-funktionelle krav skal tages i betragtning.
# 4) Ikke alle oplysninger er målrettet mod testerne, så det er vigtigt at forstå, hvad man skal bemærke, og hvad ikke.
# 5) Vigtigheden og nej. af testsager til et testscenarie behøver ikke at være nøjagtige og kan udfyldes med en omtrentlig værdi eller kan stå tomme.

Sammenfattende resulterer SRS-gennemgang i:

  • Test scenarieliste
  • Gennemgangsresultater - Dokumentation / krav til fejl fundet ved statisk at gennemgå / verificere SRS-dokumentet
  • En liste med spørgsmål til bedre forståelse - i tilfælde af nogen
  • Den foreløbige idé om, hvordan testmiljøet skal være
  • Testomfangsidentifikation og en grov idé om, hvor mange testsager vi måske ender med at have - så hvor lang tid vi har brug for til dokumentation og til sidst udførelse.

Vigtige punkter at bemærke:

hvordan man finder sikkerhedsnøgle til routeren

# 1) Testscenarier er ikke eksterne leverancer (deles ikke med forretningsanalytikere eller Dev-teams), men er vigtige for internt QA-forbrug. De er vores første skridt mod et 100% testdækningsmål. Testscenarier, når de er færdige, gennemgår en peer review, og når det er gjort, konsolideres de alle.

For flere detaljer om, hvordan QA-dokumenter gennemgås, se artiklen: Sådan udføres testdokumentationsanmeldelser i 6 enkle trin.

#to) Vi kunne bruge et teststyringsværktøj som f.eks HP ALM eller qTest for at oprette testscenarierne. Imidlertid er oprettelse af testscenarier i realtid en manuel aktivitet. Efter min mening er det mere bekvemt manuelt. Da det er trin 1, behøver vi ikke bringe de store kanoner frem endnu. Enkle Excel-ark er den bedste måde at gøre det på.

Det næste trin til denne serie er, at - vi vil arbejde på at skabe testcases og komme længere ind i testdesignfasen. Før det vil vi også komme ind på - Hvad er testplanlægning?Hvor passer det ind i hele QA-projektet? Arbejd som altid med os for at få de bedste resultater.

QA-træningsdag 3: Sådan skriver du et SRS-dokument fra bunden.

Hold dine spørgsmål og kommentarer kommende. Vi værdsætter din læserskare et ton!

Anbefalet læsning

^