acceptance testing documentation with real time scenarios
Dokumentasjon for godkjenningstesting (del II):
Forrige veiledning | NESTE veiledning
Denne opplæringen er en fortsettelse av vår forrige opplæring der vi diskuterte hva som er akseptatestesting, når det må gjøres, hvem som gjør det, dets betydning, typer, prosess, innvirkning på forskjellige team, etc.
hvordan åpne bin-filer på Windows 7
Dokumenter spiller en veldig viktig rolle i Acceptance Testing, og eventuelle problemer med hensyn til dokumentet har en enorm negativ innvirkning. Når en riktig kontroll ikke utøves, kan det til og med føre til svikt i produktet.
=> Klikk her for fullstendig testplanopplæringsserie
I denne opplæringen vil vi lære mer om de forskjellige dokumentasjonene som er involvert i Acceptance Testing, dvs. Acceptance Test Plan, Test Plan Review Checklist, Acceptance Test Template, eksempler basert på sanntidsscenarier, hvordan man identifiserer og skriver aksepttester osv. I detalj .
Hva du vil lære:
- Akseptprøveplan
- Godkjenningstestplanmal
- Gjennomgang av godkjenningstestplan
- Aksept tester
- Gjennomgang av godtakelsestester
- Konklusjon
- Anbefalt lesing
Akseptprøveplan
Som alle andre testplaner, inkluderer akseptplanen også noen komponenter som omfang, tilnærming, testmiljø, ressurser, ansvar, godkjenningstestreferanser, inngangskriterier, utgangskriterier, verktøy osv.
Det eneste som skiller akseptplanen fra en vanlig testplan, er dens faktorer som resulterer i forretningsbeslutning. Acceptance Test Plan er en av de viktigste dokumentasjonene som gir veiledning om hvordan du utfører akseptanstesting for et bestemt prosjekt.
Akseptprøveplanen må gjennomgås og godkjennes før utførelsen av aksepttesten. Alle de påfølgende endringene må gjennomgå en godkjenningsprosess og må være i sporet.
Godkjenningstestplan gjennomgang gjøres vanligvis av ledere / forretningsanalytikere / kunder.
Nøkkelpunkter som skal vurderes når du utformer en godkjenningstestplan:
- Det bør være Detaljert og spesifikk. Må bare inkludere det som er nødvendig for testing og hvilken informasjon som er nødvendig for teamet for å utføre testing.
- Det bør være Klar og konsis . Ingen tvetydighet. Hvis det i det hele tatt er noe som kan føre til forvirring, så utfør det, men hold det kort og effektivt.
- Hver komponent i dokumentet skal skrives ved å bare ha forretningskravene i tankene.
- Pålitelig og tilpasningsdyktig - Den bør oppdateres etter behov i fremtidige utgivelser.
- Konsistent - Det skal ikke ha flere endringer i fremtiden.
- Følg malen gitt av organisasjonen eller kunden.
Godkjenningstestplanmal
Her vil vi ta en titt på en felles mal for Acceptance Test Plan som kan finjusteres videre i henhold til prosjektkravene.
Tittel
Objektiv
Revisjonshistorikk / Endringslogg
< Dette skal være i tabellform med informasjonen nedenfor:
- Dato - Datoen da dokumentet ble endret.
- Modifisert av - Hvem har endret innholdet i dokumentet.
- Hensikt - Hvorfor ble dokumentet endret.
- Versjon - Gjeldende versjon av dokumentet etter endringer (går som 1.0, 1.1, 1.2, 1.3, ... for en bestemt utgivelse. Neste utgivelse starter fra 2, 2.1, 2.2, 2.3, ..., Listen fortsetter).
- Godkjent av - Hvem har godkjent endringene som er gjort (implisitt betyr at dokumentet er gjennomgått og godkjent).
Den aller første raden i denne tabellen skal være dokumentopprettede detaljer. Deretter følger detaljene i endringene.>
Innholdsfortegnelse
Referanser
omfang
Introduksjon
Test elementer
Funksjoner som skal testes
Funksjoner som ikke skal testes
Nærme seg
Testmiljødetaljer
Oppføringskriterier
Tester - Hvis det ikke er skrevet noen separate godkjenningstester
Hver test må inneholde:
- Test nr.
- En beskrivelse av hva som testes ( Eksempel : Kontroller om en bruker er i stand til å opprette en konto med hell).
- Forretningskrav som denne testen tilordnes ( Sporbarhetsmatrise ) - Veldig viktig.
- Forutsetninger:
- Produktets tilstand før testen startes (brukeren skal registreres, men ikke aktivere kontoen, brukeren burde ha fått tilgang til produktet for minst 30 dager siden osv.)
- Eventuelle serverforhold - Skulle serveren være nede i noen tid.
- Teststrinn: Detaljert nummerert flyt ( Eksempel: se nedenfor
- Åpne applikasjonen.
- Forsøk å logge på med gyldig legitimasjon med Husk meg avkrysningsruten valgt).
- forventet resultat : Hva er trinnets forventede oppførsel>
Akseptprøver - Hvis det er skrevet separate akseptprøver
Utgangskriterier
Ressurser
Roller og ansvar
Verktøy
Forretningsbeslutningsfaktorer
Avloggingsprosedyre
Kontaktpunkt
Akseptprøveplan regnes som Master Test Plan for Phase .
Gjennomgang av godkjenningstestplan
Når planen er klar, må den gjennomgås for fullstendighet, tvetydighet, klarhet, kvalitet osv. Ingen tvil om at hele innholdet i godkjenningstestplanen må gjennomgås grundig for riktig informasjon, men det må bli vurdert mot noen få andre punkter, så la oss si sjekklistepoeng.
La oss kategorisere innholdet og se sjekklisten peker mot dem.
Kategori | Sjekklistepoeng |
---|---|
Aksept tester | Er testene nummererte Er forutsetningene nummererte Er teststrinnene klare å forstå Er teststrinnene fullført Er forventet resultat fullført Er det noen åpne spørsmål i testene (hvis noen, følg opp og fullfør det) Er henvisningen til godkjenningstester (hvis den er skrevet separat) gyldig og eksisterende Er sporbarheten riktig Er det noe forretningsmessig krav som er gått glipp av å dekke for test |
Tittel | Er tittelen som samsvarer med prosjektets tittel som referert overalt Er tittelen som følger prosjektets navnekonvensjoner |
Revisjonshistorikk, innholdsfortegnelse | Spores alle versjonsendringer riktig for planen Har hver versjonsendring gjennomgått riktig gjennomgang og er nevnt Er versjonskonvensjonen riktig Samsvarer innholdsfortegnelsen med det faktiske innholdet i planen Er sidetallet for hvert innhold riktig Er sidetallet oppdatert hvis endringene som er gjort i planen endret sidetallet på innholdet |
Referanser | Er referansene eksisterende og gyldige Samsvarer de med omfanget Er de fullstendige og vurderes for identifikasjon av tester |
Testelementer, funksjoner som skal testes, funksjoner som ikke skal testes | Er de nummerert Kommer hver funksjon / modul / undermodul under omfang Kan den planlagte tidsplanen dekke alle de identifiserte testelementene i |
Inngangskriterier, utgangskriterier | Er de nummerert Er hvert kriterium nevnt i detalj |
Testmiljødetaljer | Har den alle de nødvendige konfigurasjonene nevnt Er versjonen for hver konfigurasjon spesifikk eller siste som skal vurderes Har VM-er, miljø (hvis ikke, nevn mulig dato for tilgjengelighet) Er referansedelingsmetoden for bestemt miljøtilgang nevnt |
Ressurser, roller og ansvar | Er ansvaret for hver rolle nummerert Kan ansvaret oppnås Er den identifiserte ressursen i stand til å håndtere nevnte ansvarsområder |
Verktøy | Er alle verktøyene nevnt Er alle verktøyene nummererte Er alle verktøyene versjonert Trenger noe av verktøyet lisens eller den eksisterende lisensen gyldig i løpet av fasen Er veiledningen til bruken av verktøyet riktig og tilstrekkelig |
Forretningsbeslutningsfaktorer | Har alle faktorene nevnt Er alle faktorene nummerert |
Avloggingsprosedyre | Er prosedyren gyldig Er prosedyren akseptabel Er prosedyren klar å forstå |
Kontaktpunkt | Er ressursen identifisert som kontaktpunkt tilgjengelig i organisasjonen i løpet av fasen Er den identifiserte ressursen i stand til å håndtere fasen |
Enhver testplan som tilfredsstiller ovennevnte sjekkliste-dokument vil også tjene som et sterkt dokument for interne revisjoner.
Aksept tester
Akseptstester var tidligere kjent som Funksjonstester. For å gjøre navnet mer egnet for godkjenningstestfasen og for å tjene formålet, ble det omdøpt til Aksept tester. Noen ganger blir det også betegnet som Kundetester.
Akseptprøver er alltid avledet fra brukerhistorier, akseptkriterier og brukstilfeller. Dette er systemtester i svart boks og representerer bare de forretningstestene som må bekreftes. Disse bør hovedsakelig være ment for produktadferd, bruk og flyt.
De utformede aksepttestene kan også tas i betraktning for systemtestfasen i regresjonssyklusene for å få tillit til produktet før det overleveres til godkjenningstestfasen.
Viktige punkter som skal huskes før du skriver aksepttester:
- Hold alle referansedokumentene på plass: Spesifikasjon av programvarekrav, Dokument om forretningskrav, Brukstilfeller, brukerhistorier, datamatrise (i tilfelle logikk involvert) etc.
- Fokuser bare på forretningskrav (testbare forretningskrav).
- Fjern all tvil, spørsmål om forretningskravene tidligst.
- Forsikre deg om at det ikke er noen endringer i kravene til den nåværende utgivelsen i det minste.
Generell og enkel mal for å skrive aksepttester:
Denne malen kan igjen justeres i henhold til prosjektets behov og med mer informasjon å inkludere.
La oss nå ta noen vanlige scenarier og se hvordan Acceptance test-scenarier kan skrives på dem.
Sak 1: Brukerkontohåndtering
Dette er scenariet der brukerne får lov til å opprette, vise, oppdatere og deaktivere kontoen sin. Generelt er det en CRUD-operasjon (Opprett, Les, Oppdater og Slett). Så direkte får vi 4 store scenarier å teste.
Sammen med dette har vi i sanntid håndtering av brukerkontoer mange områder når det gjelder visning og oppdatering.
Fortsetter å skrive aksepttester:
Test 1: Registrering / Registrering / Opprett konto, verifiser om en bruker er i stand til å:
- Opprett kontoen.
- Aktiver kontoen.
- Aktiver kontoen bare en gang (her må aktiveringskoblingen testes for 2ndSelv om dette er negativ testing, er det et av de viktigste bekreftelsespunktene som skal vurderes).
Test 2: For å få tilgang til og se kontoinformasjon, sjekk om en bruker er i stand til å:
- Logg inn på kontoen.
- Se forskjellige seksjoner i profilen (Hvis profilseksjonen er kategorisert, bør hver kategori være synlig).
- Bekreft at dataene som vises i profilen er korrekte i henhold til brukerens innspill.
Test 3: For å oppdatere kontoinformasjon, sjekk om en bruker er i stand til å:
- Oppdater kontoinformasjon (profil):
- Oppdater hver kategori i profilen.
- Kontroller at oppdateringsinformasjonen gjenspeiles riktig i profilen.
- Bekreft om brukeren ikke er i stand til å oppdatere informasjon i profilen (I noen applikasjoner får ikke fornavn, etternavn, brukernavn osv. Oppdatering. Selv om dette er negativ testing, er det et av de viktigste bekreftelsespunktene å bli vurdert).
- Avbryt oppdateringsflyten (selv om dette er negativ testing, er det også et av de viktigste bekreftelsespunktene som skal vurderes).
Test 4: Hvis deaktivering av konto er tillatt, må du kontrollere om en bruker er i stand til å:
- Deaktiver kontoen.
- Avbryt deaktiveringsflyt (selv om dette er negativ testing, er det et av de viktigste bekreftelsespunktene som skal vurderes).
- Få tilgang til kontoen etter kansellering av deaktivering.
Test 5: Hvis det kreves bekreftelser for en e-postadresse eller telefonnumre, må du kontrollere om en bruker er i stand til å:
hva er integrasjonstesting med eksempel
- Oppdater e-postadressen til den andre gyldige.
- Bekreft ”oppdatert e-postadresse.
- Bekreft om oppdatert og “bekreftet” e-postadresse vurderes videre - Send noen e-postmeldinger fra applikasjonen og se etter ankomst til den oppdaterte e-postadressen. Den gamle skal ikke motta e-post.
- Legg til det nye telefonnummeret.
- Bekreft tilført telefonnummer gjennom Ring.
- Bekreft tilført telefonnummer via SMS.
- Bekreft at det tilførte og 'bekreftede' telefonnummeret gjenspeiler i kontoen.
- Oppdater telefonnummeret.
- Bekreft oppdatert telefonnummer gjennom Ring.
- Bekreft ”oppdatert telefonnummer via SMS.
- Bekreft om oppdatert og 'bekreftet' telefonnummer gjenspeiles i kontoen.
Sak 2: Innkjøpsprodukt
Innkjøp av produktet har vanligvis den generelle flyten.
Her er noen generelle scenarier som sluttbrukere ser på:
Forutsetning: Brukeren skal være logget på applikasjonen.
Test 1: Produktdetaljer, verifiser om en bruker er i stand til å:
- Se siden med produktdetaljer.
- Vis alle underseksjonene på siden med produktdetaljer (beskrivelse, funksjon, merkeinformasjon, etc.).
- Velg mengden av produktet, farge, størrelse osv. Som er tilgjengelig på siden Produktdetaljer.
- Naviger til kategori, underkategorisider fra siden Produktdetaljer (hvis tilgjengelig på siden Produktdetaljer).
- Naviger til informasjonssiden til det andre produktet (hvis relevant produktdel er angitt).
- Se kommentarer og rangeringer på produktet.
- Sorter produktets kommentarer basert på rangeringer.
- Se total vurdering av produktet.
- Legg til kommentar på produktet.
- Oppdater hans / hennes kommentar til produktet.
- Slett hans / hennes kommentar til produktet (hvis gitt).
Test 2: Legg i handlekurven, bekreft om en bruker er:
- Kunne legge produktet i handlekurven:
- Gjennom siden for produktdetaljer.
- Gjennom produktlistesiden.
- Kunne legge til nødvendig mengde i handlekurven (1 til maks. Satt grense).
- Kan ikke legge produktet i handlekurven hvis det ikke er på lager.
Test 3: Kontroller om en bruker er i stand til å:
- Se produktet i handlekurven med prisdetaljer for ekstra mengde.
- Oppdater mengde (1 til maks. Grense satt).
- Fjern produktet fra handlekurven.
- Naviger tilbake til shopping.
- Fortsett til kassen.
- Se Tom handlevogn når det ikke er lagt til noe produkt,
Test 4: Kontroller om en bruker er i stand til å:
- Fortsett med eksisterende forsendelsesdetaljer.
- Oppdater leveringsadresse.
- Legg til ny leveringsadresse.
- Fortsett med det eksisterende telefonnummeret.
- Oppdater telefonnummeret for bestillingen.
- Legg til nytt telefonnummer for bestillingen.
- Naviger tilbake til handlekurven.
- Naviger til Betalingssiden.
Test 5: Kontroller om en bruker er i stand til å:
- Bekreft riktigheten av beløpet som skal faktureres.
- Behandle bestillingen med alle tilgjengelige alternativer (ett alternativ for hver enkelt ordre).
- Behandle transaksjonen vellykket. Gå til siden for ordrebekreftelse.
- Transaksjonsfeil (selv om dette er negativ testing, bør det betraktes som et hovedscenario).
- Bruk kuponger:
- Gyldige kuponger - suksess. Bekreft her endringen i beløpet som skal faktureres.
- Ugyldige kuponger - Feil
- Utløpte kuponger - Feil.
- Naviger tilbake til siden Kontoinformasjon.
Gjennomgang av godtakelsestester
Gjennomgang av akseptattester er en viktig oppgave, siden den må være riktig og til punktet med hensyn til forretningskravene. Ettersom disse kan utføres av kunder selv og / eller sluttbrukere, er det veldig nødvendig å være fullstendig, ikke tvetydig, korrekt og detaljert nok til at noen kan forstå og utføre.
Gjennomgang av godkjennelsestester må gjøres av forretningsanalytikere, kunder, og eventuelle kommentarer om gjennomgangen bør innarbeides i høy prioritet.
På individuelt testnivå bør gjennomgangen gjøres mot nedenstående:
- Om testen dekker forretningskravet eller ikke.
- Er forutsetningene klare?
- Er teststrinnene enkle å forstå og detaljerte?
- Er det forventede resultatet riktig og klart?
- Er det kartlagt til forretningskravene for sporbarhet?
- Er testen fullstendig nok til å dekke den spesielle strømmen eller bruken?
- Er den spesifikke testen som kreves som en del av akseptanstesten.
- Er det noe verifiseringspunkt som ikke er nødvendig for akseptatestesting.
- Er det rent funksjonelt, eller er GUI dekket i det (det skal bare være funksjonelt).
- Er spesielle inndata nødvendige? Hvis ja, er det gitt opplysninger?
I det hele tatt bør hele gjennomgangen av Acceptance tests suite omfatte:
- Toveis sporbarhet: Forretningskrav til tester OG tester til forretningskrav.
- Er alle forretningskrav dekket?
- Er alle forretningskrav dekket av en eller flere tester?
- Er forretningsregler dekket?
- Behandles den spesielle datasaken?
- Hvor mange tester skrives for å dekke hvert krav eller regel?
- Kan testene grupperes og klassifiseres for strømmer.
- Blir testene ordnet slik at utførelsen er effektiv?
Konklusjon
I et nøtteskall, som nevnt tidligere, spiller dokumenter en veldig drastisk rolle i aksepttesting.
Derfor bør enhver godkjenningstest som er skrevet være godt strukturert og strømme over bruken, slik at den holder akseptantene til å være interessert i hva de tester og hvordan de gjør det. Dette vil igjen føre til suksess.
=> Besøk her for komplett testplanopplæringsserie
Forrige veiledning | NESTE veiledning
Hold deg oppdatert og se på den kommende opplæringen for godkjenningstesting for å vite mer om godkjenningstestrapporter sammen med noen generiske maler. Gi oss også beskjed hvis du har spørsmål.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Positiv testing: Betydning og fortjenester forklart med virkelige testscenarier
- Testing Primer eBook Download
- TimeShiftX Utgitt for å forenkle Time Shift-testing
- Hva er akseptantesting (en komplett guide)
- Eksempelmal for akseptrapport med eksempler
- Er du en manuell eller automatiseringstestekspert? Jobb deltid for oss!
- Lastetesting med HP LoadRunner-opplæringsprogrammer