Meny

Hvordan gjennomgå SRS-dokument og lage testscenarier - Opplæring i programvaretesting på et live-prosjekt - dag 2

how review srs document

Prøv Instrumentet Vårt For Å Eliminere Problemer

Dette er den andre opplæringen i vår ‘Gratis online programvaretestopplæring på et live-prosjekt’ serie. Hvis du er ny her, kan du sjekke den første introduksjonstutorialen: End to End Training Testing Training på et Live Project.

La oss nå gå inn i en detaljert analyse av hvordan en SRS-gjennomgang skjer, hva er det vi trenger å identifisere fra dette trinnet, hvilke forhåndssteg vi må ta før vi begynner, hva er utfordringene vi kan møte, etc. i en detaljert måte.

Hvordan gjennomgå SRS-dokument og lage testscenarier_

SDLCs designfase:

Den neste fasen av SDLC er 'Design' - det er her funksjonskravene oversettes til de tekniske detaljene. Utviklings-, design-, miljø- og datateamene er involvert i dette trinnet. Resultatet av dette trinnet er vanligvis et teknisk designdokument - TDD.

Inndataene er SRS-dokumentet både for opprettelse av TDD og for at QA-teamet skal begynne å jobbe med QA-aspektet av prosjektet - som er å gjennomgå SRS og identifisere testmål.

Hva du vil lære:

Hva er en SRS-gjennomgang?

SRS er et dokument som er laget av utviklingsteamet i samarbeid med forretningsanalytikere og miljø / datateam. Vanligvis vil dette dokumentet når det er ferdig, bli delt med QA-teamet via et møte der det blir arrangert en detaljert gjennomgang.

Noen ganger, for en allerede eksisterende søknad, trenger vi kanskje ikke et formelt møte og noen som veileder oss gjennom dette dokumentet. Vi kan ha den nødvendige informasjonen for å gjøre dette selv.

SRS-gjennomgang er bare å gå gjennom spesifikasjonsdokumentet for funksjonelle krav og prøve å forstå hvordan målapplikasjonen kommer til å bli.

Det formelle formatet og et utvalg ble delt med dere alle i forrige artikkel. Det betyr ikke nødvendigvis at alle SRS-er skal dokumenteres på den måten nøyaktig. Alltid, den form er sekundær til innholdet .

vanlige spørsmål om c ++ intervjuer

Noen lag vil bare velge å skrive en punktliste, noen lag inkluderer brukstilfeller, noen lag inkluderer eksempler på skjermbilder (som dokumentet vi hadde), og noen beskriver bare detaljene i avsnitt.

Før trinn til gjennomgang av spesifikasjonskrav til programvare

Trinn 1) Dokumenter går gjennom flere revisjoner, så sørg for at vi har riktig versjon av det refererte dokumentet, SRS.

Steg 2) Sett retningslinjer for hva som forventes på slutten av gjennomgangen fra hvert teammedlem. Med andre ord, bestemme hvilke leveranser som forventes fra dette trinnet - vanligvis er resultatet av dette trinnet å identifisere testscenariene. Testscenarier er ikke annet enn en linjepekepinn med 'hva du skal teste' for visse funksjoner.

Trinn 3) Sett også retningslinjer for hvordan denne leveransen skal presenteres - jeg mener malen.

Trinn 4) Bestem deg for om hvert medlem av teamet skal jobbe med hele dokumentet eller dele det mellom seg. Det anbefales på det sterkeste at alle leser alt fordi det vil forhindre kunnskapskonsentrasjon hos visse teammedlemmer.

Men i tilfelle et stort prosjekt, med SRS-dokumentene som kjører nærmere 1000 sider, er fremgangsmåten med å bryte opp dokumentmodulen klokt og tildele til individuelle teammedlemmer mest praktisk.

Trinn 5) SRS gjennomgang hjelper også til bedre forståelse om det er noen spesifikke forutsetninger som kreves for testing av programvaren.

Trinn 6) Som et biprodukt identifiseres en liste med spørsmål der noe funksjonalitet er vanskelig å forstå, eller hvis mer informasjon må innlemmes i funksjonelle krav, eller hvis feil blir gjort i SRS.

Hva trenger vi for å komme i gang?

  • Riktig versjon av SRS-dokumentet
  • Tydelige instruksjoner om hvem som skal jobbe med hva og hvor lang tid de har.
  • En mal for å lage testscenarier.
  • Annen informasjon om - hvem du skal kontakte i tilfelle et spørsmål eller hvem du skal rapportere i tilfelle dokumentasjon er uoverensstemmende

Hvem vil gi denne informasjonen?

Teamledere er generelt ansvarlige for å levere alle elementene som er oppført i delen ovenfor. Teammedlemmenes innspill er imidlertid alltid viktige for å lykkes med hele dette arbeidet.

Teamledere spør ofte - Hva slags innspill? Ville det ikke vært bedre å tildele en bestemt modul til noen som er interessert i det, enn til et teammedlem som ikke er det? Ville det ikke være fint å bestemme måldatoen basert på lagets mening enn å treffe en avgjørelse på dem? Også, for å lykkes med et prosjekt, er maler viktige.

hva er den beste stemmeskifteren

Som hovedregel har maler en høyere effektivitetsgrad når de er skreddersydd for det spesifikke teamets bekvemmelighet og komfort. Det bør derfor bemerkes at teamledere mer enn noe annet er teammedlemmer. Å få teamet ditt ombord på de daglige beslutningene er avgjørende for at prosjektet skal fungere greit.

Er mal påkrevd for testscenarier?

Hvorfor en mal for testscenarier - er det ikke nok hvis vi bare lager en liste?

Det er sikkert. Imidlertid er programvareprosjekter ikke 'one-man' show. De involverer teamarbeid .

Tenk deg et team på 4 - hvis hver og en av dem bestemmer seg for å gjennomgå en modul av programvarekravspesifikasjonen hver. Teammedlem A har laget en liste på et ark. Teammedlem 2 brukte et excel-ark. Teammedlem 3 brukte en notisblokk. Teammedlem 4 brukte et ord dok. Hvordan konsoliderer vi alt arbeidet som er gjort for prosjektet på slutten av dagen?

Hvordan kan vi også bestemme hvilken som er standarden, og hvordan kan vi si hva som er riktig og hva som ikke er hvis vi ikke opprettet reglene til å begynne med?

Det er hva malen er: Et sett med retningslinjer og et avtalt format for ensartethet og samsvar for hele teamet.

Hvordan lage en mal for QA-testscenarier?

Maler trenger ikke å være komplisert eller ufleksibel.

Alt de trenger å være er en effektiv mekanisme for å lage en nyttig testgjenstand. Noe enkelt som det vi ser nedenfor:

test scenarimal

Overskriften på denne malen inneholder den nødvendige plassen for å fange grunnleggende informasjon om prosjektet, det gjeldende dokumentet og det refererte dokumentet.

Tabellen nedenfor lar oss lage testscenarier. Kolonnene som er inkludert er:

Kolonne nr. 1) Testscenario-ID
Hver enhet i testprosessen vår må kunne identifiseres unikt. Så hvert testscenario må tildeles en ID. Reglene som skal følges under tildeling av denne IDen, må defineres.

Av hensyn til denne artikkelen skal vi følge navnekonvensjonen som TS (prefiks som står for Test Scenario) etterfulgt av ‘_’, modulnavn MEG (Min infomodul i Orange HRM-prosjektet) etterfulgt av ‘_’ og deretter underavsnittet ( For eksempel, MEG for min infomodul, P for fotografi og så videre) etterfulgt av serienummer. Et eksempel kan være: “TS_MI_MIM_01”.

Kolonne nr. 2) Krav
Det hjelper at når vi lager et testscenario, skal vi kunne kartlegge det tilbake til delen av SRS-dokumentet der vi valgte det. Hvis kravene har ID, kan vi bruke det. Hvis ikke seksjonsnumre eller til og med sidetall i SRS-dokumentet hvor vi identifiserte et testbart krav, vil gjøre.

Kolonne nr. 3) Testscenariobeskrivelse
En one-liner som spesifiserer 'hva du skal teste'. Vi vil også referere til det som testmål.

Kolonne nr. 4) Viktighet
Dette er for å gi en ide om hvor viktig viss funksjonalitet er for AUT. Verdier som høy, middels og lav kan tildeles dette feltet. Du kan også velge et poengsystem, som 1-5, 5 er viktigst, 1 er mindre viktig. Uansett hvilken verdi dette feltet kan ta, må det bestemmes på forhånd.

Kolonne nr. 5) Antall testtilfeller
Et grovt estimat på hvor mange individuelle testsaker vi kan ende med å skrive det ene testscenariet. For eksempel, For å teste innloggingen - inkluderer vi følgende situasjoner: Rett brukernavn og passord. Rett brukernavn og feil passord. Riktig passord og feil brukernavn. Validering av påloggingsfunksjonaliteten vil resultere i 3 testtilfeller.

Merk: Du kan utvide denne malen eller fjerne feltene etter eget ønske.

For eksempel , kan du legge til “Vurdert av” i overskriften eller fjerne datoen for opprettelsen, etc. I tabellen kan du også inkludere et felt “Opprettet av” for å angi testeren som er ansvarlig for et bestemt testscenario, eller fjerne “Nei. of Test cases ”-kolonnen. Valget er ditt. Gå med det som fungerer best for hele teamet.

La oss nå gjennomgå vårt orange HRM SRS-dokument og lage testscenarier

Pro Tips: sjekk ut innholdsfortegnelsen i SRS-prøven vi ga i 1. veiledning for å få en god ide om hvordan ethvert dokument kommer til å flyte og hvor mye arbeid det kan innebære.

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

Avsnitt 2.1 : Prosjektoversikt - Publikum - ingen testbare krav der heller.

Avsnitt 2.2 : Maskinvare og hosting - Denne delen snakker om hvordan Orange HRM-nettstedet skal vert. Er denne informasjonen viktig for oss testere? Svaret er Ja og Nei. Ja, for når vi tester, må vi ha et miljø som ligner sanntidsmiljøet.

Dette gir oss en ide om hvordan det må være. Nei, for det er ikke et testbart krav - en slags forutsetning for at testingen skal skje.

programvare for kunstig intelligens for pc gratis nedlasting

Seksjon 3: Det er en påloggingsskjerm her og detaljene for kontotypen vi trenger for å komme inn på nettstedet. Dette er et testbart krav. Så det må være en del av testscenariene våre.

Se testscenariedokumentet der testscenarier for noen få seksjoner av SRS er lagt til. For øvelse, legg til resten av scenariene på en lignende måte. Imidlertid går jeg rett til seksjon 4 i dokumentet.

Seksjon 4: Estetiske / HTML-krav og retningslinjer - Denne delen forklarer best hvordan noen krav kanskje ikke gir mening for testteamet på tidspunktet for SRS-gjennomgangen, men teamet bør notere dem som testbare krav.

Hvordan vi kan teste dem, og hvis vi trenger spesifikke oppsett / noe teamets hjelp til å validere det, er detaljer som vi kanskje ikke vet på dette tidspunktet. Men å gjøre dem til en del av vårt testomfang er det første trinnet for å sikre at vi ikke savner dem.

Eksempel på testscenarier for OrangeHRM-applikasjon: (klikk for å forstørre bildet)

test scenarimal

=> Se og last ned testscenariedokumentet for mer informasjon.

Noen viktige observasjoner angående SRS-gjennomgang

#1) Ingen informasjon skal etterlates avdekket.
#to) Utfør mulighetsanalyse av om et bestemt krav er riktig eller ikke, og også om det kan testes eller ikke.
# 3) Med mindre det foreligger en egen ytelse / sikkerhet eller noen annen form for testteam, er det vår jobb å sørge for at alle ikke-funksjonelle krav må tas i betraktning.
# 4) Ikke all informasjon er rettet mot testerne, så det er viktig å forstå hva du skal merke og hva ikke.
# 5) Viktigheten og nei. av testsaker for et testscenario trenger ikke å være nøyaktig og kan fylles ut med en omtrentlig verdi eller kan stå tomme.

For å oppsummere, resulterer SRS gjennomgang i:

  • Test liste over scenarier
  • Gjennomgangsresultater - Dokumentasjon / Kravfeil funnet ved statisk gjennomgang / verifisering av SRS-dokumentet
  • En liste med spørsmål for bedre forståelse - i tilfelle noen
  • Den foreløpige ideen om hvordan testmiljøet skal være
  • Test omfangsidentifikasjon og en grov ide om hvor mange testtilfeller vi kan ende med å ha - så hvor lang tid vi trenger for dokumentasjon og til slutt gjennomføring.

Viktige punkter å merke seg:

#1) Testscenarier er ikke eksterne leveranser (deles ikke med forretningsanalytikere eller Dev-team), men er viktige for internt QA-forbruk. De er vårt første skritt mot et 100% testdekningsmål. Når testscenarier er fullført, gjennomgås en fagfellevurdering, og når det er gjort, blir de alle konsolidert.

For mer informasjon om hvordan QA-dokumenter blir gjennomgått, sjekk ut artikkelen: Hvordan utføre testdokumentasjonsanmeldelser i 6 enkle trinn.

#to) Vi kan bruke et testadministrasjonsverktøy som HP ALM eller qTest for å lage testscenariene. Imidlertid er testscenariene i sanntid en manuell aktivitet. Etter min mening er det mer praktisk manuelt. Siden det er trinn 1, trenger vi ikke å hente ut de store våpnene ennå. Enkle Excel-ark er den beste måten å gjøre det på.

Det neste trinnet til denne serien er at - vi vil jobbe med å lage testsaker og komme videre inn i testdesignfasen. Før det vil vi også komme inn på - Hva er testplanlegging?Hvor det passer inn i hele QA-prosjektet? Som alltid, samarbeid med oss ​​for de beste resultatene.

QA-treningsdag 3: Hvordan skrive et SRS-dokument fra bunnen av.

Vennligst hold spørsmålene og kommentarene dine kommende. Vi setter stor pris på lesertallet ditt!

Anbefalt lesing

^