acceptance testing documentation with real time scenarios
Dokumentation for acceptprøvning (del II):
Forrige vejledning | NÆSTE vejledning
Denne tutorial er fortsættelsen af vores tidligere tutorial, hvor vi diskuterede, hvad der er Acceptance-test, hvornår det skal gøres, hvem der gør det, dets betydning, typer, proces, indvirkning på forskellige teams osv.
venstre sammenføjning mod venstre ydre sammenføjning
Dokumenter spiller en meget vigtig rolle i Acceptance Testing, og eventuelle problemer med hensyn til dokumentet har en enorm negativ indvirkning. Når en ordentlig kontrol ikke udøves, kan det endda føre til produktets svigt.
=> Klik her for en komplet testplan-selvstudieserie
I denne vejledning lærer vi mere om de forskellige dokumenter, der er involveret i Acceptance Testing, dvs. Acceptance Test Plan, Test Plan Review Checklist, Acceptance Test Template, eksempler baseret på realtidsscenarier, hvordan man identificerer og skriver accept test osv. .
Hvad du vil lære:
- Accept Test Test Plan
- Accept test test skabelon
- Gennemgang af Accept Test Test Plan
- Accept test
- Gennemgang af accepttest
- Konklusion
- Anbefalet læsning
Accept Test Test Plan
Som enhver anden testplan inkluderer accepttestplanen også nogle komponenter som rækkevidde, tilgang, testmiljø, ressourcer, ansvar, referencer for accepttest, adgangskriterier, udgangskriterier, værktøjer osv.
Det eneste, der adskiller Acceptance-testplan fra en almindelig testplan, er dens faktorer, der resulterer i forretningsbeslutning. Acceptance Test Plan er en af de vigtige dokumenter, der giver vejledning i, hvordan man udfører accept test for et bestemt projekt.
Accept test test planen skal gennemgås og godkendes inden Acceptance Test udførelse. Alle de efterfølgende ændringer skal igen gennemgås og godkendes og skal være i sporet.
Accept testtest gennemgang foretages normalt af ledere / forretningsanalytikere / kunder.
Nøglepunkter, der skal overvejes ved udformningen af Acceptance Test Plan:
- Det bør være Detaljeret og specifik. Skal kun omfatte, hvad der er nødvendigt for testning, og hvilke oplysninger der er nødvendige for, at teamet kan udføre test.
- Det bør være Klar og kortfattet . Ingen tvetydighed. Hvis der overhovedet er noget, der kan føre til forvirring, så uddyb det, men hold det kort og effektivt.
- Hver eneste komponent i dokumentet skal skrives ved kun at holde forretningskravene i tankerne.
- Pålidelig og tilpasningsdygtig - Den skal opdateres efter behov i de fremtidige udgivelser.
- Konsekvent - Det burde ikke have flere ændringer i fremtiden.
- Følg skabelonen fra organisationen eller kunden.
Accept test test skabelon
Her vil vi se på en fælles skabelon til Acceptance Test Plan, som kan finjusteres yderligere i henhold til projektkravene.
Titel
Objektiv
Revisionshistorik / ændringslog
< Dette skal være i tabelform med nedenstående oplysninger:
- Dato - Datoen for ændring af dokumentet.
- Ændret af - Hvem har ændret indholdet af dokumentet.
- Formål - Hvorfor blev dokumentet ændret.
- Version - Aktuel version af dokumentet efter ændringer (går som 1.0, 1.1, 1.2, 1.3, ... for en bestemt udgivelse. Næste udgivelse starter fra 2, 2.1, 2.2, 2.3, ..., Listen fortsætter).
- Godkendt af - Hvem har godkendt de foretagne ændringer (betyder implicit, at dokumentet er gennemgået og godkendt).
Den allerførste række i denne tabel skal være de dokumentoprettede detaljer. Derefter følger detaljerne om de foretagne ændringer
Indholdsfortegnelse
Referencer
Anvendelsesområde
Introduktion
Test emner
Funktioner, der skal testes
Funktioner, der ikke skal testes
Nærme sig
Test miljøoplysninger
Indgangskriterier
Test - Hvis der ikke er skrevet nogen separate acceptprøver
Hver test skal omfatte:
- Test nr.
- En beskrivelse af hvad der testes ( Eksempel : Kontroller, om en bruger er i stand til at oprette en konto med succes).
- Forretningskrav, som denne test kortlægger ( Sporbarhedsmatrix ) - Meget vigtigt.
- Forudsætninger:
- Produktets tilstand, før testen påbegyndes (brugeren skal registreres med succes, men ikke aktivere kontoen, brugeren skal have haft adgang til produktet for mindst 30 dage siden osv.)
- Eventuelle serverbetingelser - Skulle serveren være nede i et stykke tid.
- Test trin: Detaljeret nummereret flow ( Eksempel: se nedenunder
- Åbn applikationen.
- Forsøg på at logge ind med gyldige legitimationsoplysninger med Husk mig afkrydsningsfeltet valgt).
- forventet resultat : Hvad er trinets forventede opførsel>
Acceptstest - Hvis der er skrevet separate accepttest
Udgangskriterier
Ressourcer
Roller og ansvar
Værktøjer
Forretningsbeslutningsfaktorer
Procedure for afmelding
Kontaktpunkt
Accept testplan betragtes som Master Test Plan for fasen .
Gennemgang af Accept Test Test Plan
Når planen er klar, skal den gennemgås for fuldstændighed, tvetydighed, klarhed, kvalitet osv. Ingen tvivl om, at hele indholdet i Acceptance-testplanen skal gennemgås grundigt for korrekt information, men det skal blive gennemgået i forhold til nogle få andre punkter, lad os også sige, at tjeklistepunkter.
Lad os her kategorisere indholdet og se tjeklisten peger mod dem.
| Kategori | Tjeklistepoint |
|---|---|
| Accept test | Er testene nummererede Er forudsætningerne nummererede Er testtrinnene klare at forstå Er testtrinene færdige Er det forventede resultat afsluttet Er der noget åbent spørgsmål i testene (hvis nogen, opfølgning og afslutning) Er henvisningen til accepttest (hvis skrevet separat) gyldig og eksisterende Er sporbarheden korrekt Er der noget forretningskrav, der er gået glip af til at dække til test |
| Titel | Er titlen, der matcher projekttitlen som henvist overalt Er titlen efter Projektets navngivningskonventioner |
| Revisionshistorik, indholdsfortegnelse | Spores alle versionændringer korrekt i henhold til planen Har hver versionændring gennemgået korrekt gennemgang og er nævnt Er versionskonventionen korrekt Overholder indholdsfortegnelsen det faktiske indhold i planen Er sidetallet for hvert indhold korrekt Er sidetallet opdateret, hvis de ændringer, der er foretaget i planen, ændrer indholdet af sidens nummer |
| Referencer | Er referencerne eksisterende og gyldige Matcher de med omfanget Er de komplette og overvejes til identifikation af test |
| Testgenstande, funktioner, der skal testes, funktioner, der ikke skal testes | Er de nummererede Omfatter hver funktion / modul / undermodul Kan den planlagte tidsplan dække alle de identificerede testemner inden for |
| Indgangskriterier, udgangskriterier | Er de nummererede Er hvert eneste kriterium nævnt i detaljer |
| Test miljøoplysninger | Har det alle de krævede konfigurationer nævnt Er versionen for hver konfiguration specifik eller nyeste, der skal overvejes Findes de virtuelle computere, miljø (hvis ikke, nævnt mulig dato for tilgængelighed) Nævnes legitimationsdelingsmetoden for bestemt miljøadgang |
| Ressourcer, roller og ansvar | Er ansvaret for hver rolle nummereret Kan ansvaret opnås Er den identificerede ressource i stand til at håndtere nævnte ansvarsområder |
| Værktøjer | Er alle værktøjerne nævnt Er alle værktøjerne nummererede Er alle værktøjerne versioneret Har noget af værktøjet brug for licens, eller er den eksisterende licens gyldig i løbet af fasen Er vejledningen til brug af værktøjet korrekt og tilstrækkelig |
| Forretningsbeslutningsfaktorer | Har alle de nævnte faktorer Er alle faktorer nummererede |
| Procedure for afmelding | Er proceduren gyldig Er proceduren acceptabel Er proceduren klar at forstå |
| Kontaktpunkt | Er ressourcen identificeret som kontaktpunkt tilgængelig i organisationen i løbet af fasen Er den identificerede ressource i stand til at håndtere fasen |
Enhver testplan, der opfylder ovenstående tjekliste-dokument, vil også tjene som et stærkt dokument til interne revisioner.
Accept test
Acceptanstest var tidligere kendt som Functional tests. For at gøre navnet mere egnet til Acceptance-testfasen og tjene formålet blev det omdøbt til Accept test. Nogle gange betegnes det også som Kundetest.
Acceptstest stammer altid fra brugerhistorier, acceptkriterier og brugssager. Disse er black-box systemtest og repræsenterer kun de forretningstest, der skal verificeres. Disse skal hovedsageligt være beregnet til produktadfærd, -brug og -flow.
De designede accepttest kan også tages i betragtning for systemtestfasen i regressionscyklusser for at få tillid til produktet, inden det overgives til accepttestfasen.
Nøglepunkter, der skal huskes, før du skriver acceptprøver:
- Hold alle referencedokumenterne på plads: Specifikation af softwarekrav, dokument om forretningskrav, brugssager, brugerhistorier, datamatrix (i tilfælde af involveret logik) osv.
- Fokuser kun på forretningskrav (testbare forretningskrav).
- Ryd tidligst al tvivl og forespørgsler om forretningskravene.
- Sørg for, at der i det mindste ikke er ændringer i kravene til den aktuelle udgivelse.
Generel og enkel skabelon til skrivning af accepttest:
Denne skabelon kan igen justeres i henhold til projektets behov og med mere information at medtage.
Lad os nu tage nogle almindelige scenarier og se, hvordan Acceptance test-scenarier kan skrives på dem.
Sag 1: Håndtering af brugerkonto
Dette er scenariet, hvor brugerne har lov til at oprette, se, opdatere og deaktivere deres konto. Generelt er det en CRUD-handling (Opret, læs, opdater og slet). Så direkte får vi 4 store scenarier til test.
Sammen med dette har vi i realtid håndtering af brugerkonti mange områder, når det kommer til visning og opdatering.
Fortsætter med at skrive acceptprøver:
Test 1: Registrering / Tilmeld / Opret konto, kontroller om en bruger er i stand til at:
- Opret kontoen.
- Aktivér kontoen.
- Aktivér kontoen kun en gang (her skal aktiveringslinket testes for 2ndSelvom dette er negativ test, er det et af de vigtigste verifikationspunkter, der skal overvejes).
Test 2: For at få adgang til og se kontooplysninger skal du kontrollere, om en bruger er i stand til at:
- Log ind på kontoen.
- Se forskellige sektioner i profilen (hvis profilsektionen er kategoriseret, skal hver kategori kunne ses).
- Kontroller, at de data, der vises i profilen, er korrekte i henhold til brugerens input.
Test 3: For at opdatere kontooplysninger skal du kontrollere, om en bruger er i stand til at:
- Opdater kontooplysninger (profil):
- Opdater hver eneste kategori af profilen.
- Kontroller, at opdateringsoplysningerne afspejles korrekt i profilen.
- Kontroller, om brugeren ikke er i stand til at opdatere oplysninger i profilen (i nogle applikationer har fornavn, efternavn, brugernavn osv. Ikke tilladelse til at opdatere. Selvom dette er negativ test, er det et af de vigtigste verifikationspunkter tages op til overvejelse).
- Annuller opdateringsflowet (selvom dette er negativ test, er det også et af de vigtigste verifikationspunkter, der skal overvejes).
Test 4: Hvis deaktivering af konto er tilladt, skal du kontrollere, om en bruger er i stand til at:
- Deaktiver kontoen.
- Annuller deaktiveringsflow (selvom dette er negativ test, er det et af de vigtigste verifikationspunkter, der skal overvejes).
- Få adgang til konto efter annullering af deaktivering.
Test 5: Hvis der kræves verifikationer for en e-mail-adresse eller telefonnumre, skal du kontrollere, om en bruger er i stand til at:
udefineret henvisning til klassefunktion c ++
- Opdater e-mail-adresse til den anden gyldige.
- Bekræft ”opdateret e-mail-adresse.
- Bekræft, hvis opdateret og 'verificeret' e-mail-adresse overvejes yderligere - Send nogle e-mails fra applikationen og kontroller, om den er ankommet til den opdaterede e-mail-adresse. Den gamle skal ikke modtage e-mails.
- Tilføj det nye telefonnummer.
- Bekræft tilføjet telefonnummer gennem opkald.
- Bekræft tilføjet telefonnummer via SMS.
- Kontroller, at det tilføjede og 'bekræftede' telefonnummer afspejler på kontoen.
- Opdater telefonnummeret.
- Bekræft opdateret telefonnummer via Call.
- Bekræft ”opdateret telefonnummer via SMS.
- Bekræft, hvis opdateret og 'bekræftet' telefonnummer afspejles i kontoen.
Sag 2: Indkøbsprodukt
Indkøb af produktet har normalt den generelle strøm.
Her vises nogle generelle scenarier, som slutbrugerne ser på:
Forudsætning: Brugeren skal være logget ind på applikationen.
Test 1: Produktdetaljer, kontroller om en bruger er i stand til at:
- Se siden med produktoplysninger.
- Se alle underafsnit på siden Produktoplysninger (beskrivelse, funktion, brandinformation osv.).
- Vælg produktets mængde, farve, størrelse osv. Som tilgængelig på siden Produktoplysninger.
- Naviger til kategorien, underkategorisider fra siden Produktdetaljer (hvis tilgængelig på siden Produktdetaljer).
- Naviger til det andet produkts detaljeringsside (hvis det er relevant afsnit om produkter).
- Se kommentarer og vurderinger på produktet.
- Sorter produktets kommentarer baseret på vurderinger.
- Se den samlede vurdering af produktet.
- Tilføj kommentar til produktet.
- Opdater hans / hendes kommentar til produktet.
- Slet hans / hendes kommentar til produktet (hvis det findes).
Test 2: Læg i kurv, kontroller om en bruger er:
- Kan tilføje produktet i indkøbskurven:
- Gennem siden Produktoplysninger.
- Gennem siden med produktlister.
- I stand til at tilføje den nødvendige mængde til vognen (1 til maks. Grænse indstillet).
- Kan ikke tilføje produktet til indkøbskurven, hvis det ikke er på lager.
Test 3: Kontroller, om en bruger er i stand til at:
- Se produktet i kurven med prisoplysninger for ekstra mængde.
- Opdater mængde (1 til maks. Grænse indstillet).
- Fjern produktet fra kurven.
- Naviger tilbage til shopping.
- Fortsæt til kassen.
- Se Tom indkøbskurv, når der ikke er tilføjet noget produkt,
Test 4: Kontroller, om en bruger er i stand til at: på siden Kontodetaljer:
- Fortsæt med de eksisterende forsendelsesoplysninger.
- Opdater leveringsadresse.
- Tilføj ny leveringsadresse.
- Fortsæt med det eksisterende telefonnummer.
- Opdater telefonnummer for ordren.
- Tilføj nyt telefonnummer til ordren.
- Naviger tilbage til siden Kurv.
- Naviger til siden Betalings.
Test 5: På betalingssiden skal du kontrollere, om en bruger er i stand til at:
- Kontroller rigtigheden af det beløb, der skal faktureres.
- Behandle ordren med alle de tilgængelige muligheder (en mulighed for hver separat ordre).
- Behandle transaktion med succes. Gå til siden med ordrebekræftelse.
- Transaktionsfejl (selvom dette er negativ test, bør det betragtes som et større scenarie).
- Anvend kuponer:
- Gyldige kuponer - Succes. Bekræft her ændringen i det beløb, der skal faktureres.
- Ugyldige kuponer - Fejl
- Udløbne kuponer - Fejl.
- Naviger tilbage til siden Kontooplysninger.
Gennemgang af accepttest
Gennemgang af accepttest er en vigtig opgave, da den skal være korrekt og til-punktet med hensyn til forretningskravene. Da disse kan udføres af kunder selv og / eller slutbrugere, er det meget nødvendigt at være komplet, ikke tvetydig, korrekt og detaljeret nok til at nogen kan forstå og udføre.
Gennemgang af accepttest skal udføres af forretningsanalytikere, kunder, og eventuelle gennemgangskommentarer bør indarbejdes i høj prioritet.
På det individuelle testniveau skal gennemgangen foretages mod nedenstående:
- Om testen dækker forretningskravet eller ej.
- Er forudsætningerne klare?
- Er testtrinene lette at forstå og detaljerede?
- Er det forventede resultat korrekt og klart?
- Er det kortlagt til forretningskravene til sporbarhed?
- Er testen komplet nok til at dække det specifikke flow eller brug?
- Er den særlige test påkrævet som en del af accepttesten.
- Er der et verifikationspunkt, der ikke er nødvendigt for accepttest.
- Er det rent funktionelt, eller er ethvert GUI dækket indeni (det skal kun være funktionelt).
- Er de specielle inputdata nødvendige? Hvis ja, er der angivet oplysninger?
I det store og hele skal hele Acceptance tests suite-gennemgangen omfatte:
- Tovejs sporbarhed: Forretningskrav til test OG test til forretningskrav.
- Er hver eneste forretningskrav dækket?
- Er ethvert forretningskrav dækket af en eller flere tests?
- Er forretningsreglerne dækket?
- Behandles den specielle datasag?
- Hvor mange prøver er der skrevet for at dække hvert krav eller regel?
- Kan testene grupperes sammen og klassificeres for strømme.
- Bliver testene sekventeret korrekt, så udførelsen er effektiv?
Konklusion
I en nøddeskal, som tidligere nævnt, spiller dokumenter en meget drastisk rolle i accepttest.
Derfor skal enhver acceptstest, der er skrevet, være velstruktureret og være i overensstemmelse med brugen, så den holder acceptstesterne til at være interesserede i, hvad de tester, og hvordan de gør det. Dette ville igen automatisk medføre succes.
=> Besøg her for en komplet testplan-tutorial-serie
Forrige vejledning | NÆSTE vejledning
Hold øje med og hold øje med den kommende tutorial om Acceptance Testing for at vide mere om Acceptance Testing Reports sammen med nogle generiske skabeloner. Fortæl os også, hvis du har spørgsmål.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Positiv testning: Betydning og fordele forklaret med virkelige testscenarier
- Test af Primer eBook Download
- TimeShiftX frigivet for at forenkle Time Shift-test
- Hvad er acceptantestning (En komplet guide)
- Eksempelskabelon til acceptrapport med eksempler
- Er du en manuel eller automatiseringstestekspert? Arbejd deltid for os!
- Load Testing med HP LoadRunner-vejledninger