sample template acceptance test report with examples
Oversigt over acceptrapport (del III):
Forrige vejledning | NÆSTE vejledning
I vores tidligere tutorial om “ Acceptationsprøvningsdokumentation med realtidsscenarier ”Vi diskuterede Acceptance Test plan.
I denne vejledning vil vi se nærmere på rapportering af Acceptance Test Status, Acceptance Test Summary og Sign-Off.
Nogle generiske skabeloner er inkluderet i denne vejledning for at forbedre din forståelse på en bedre måde. Vi vil også svæve over begrebet Acceptance Testing i Agile og Acceptance Test Driven Development.
Kort fortalt vil denne tutorial forklare dig om Acceptance test Status Report og Summary rapport sammen med nogle generiske skabeloner til din klare forståelse og børster også konceptet Acceptance testing i Agile og test-driven udvikling på en let forståelig måde.
Hvad du vil lære:
- Statusrapport om accepttest
- Resumérapport om accepttest
- Acceptantestning i smidig
- Hvem udfører test af accept i smidig?
- Fordele ved acceptprøvning i smidig
- Ulemper
- Acceptance Test Driven Development (ATDD)
- Konklusion
- Anbefalet læsning
Statusrapport om accepttest
Accept testrapport bør altid opsummere de accept test, der udføres sammen med deres resultater. Det bør rettes til alle de identificerede interessenter, der er en del af Acceptance Testing-fasen. Når udførelsen af accepttest er startet, skal status rapporteres dagligt.
Generisk skabelon til statusrapport om accepttest:
Dato :Acceptance Test Status Report Date
Dagens detaljer om udførelse af accepttest:
- Antal beståede tests
- Antal test mislykkedes
- Antal igangværende tests
Accept-test Udførelsesdetaljer indtil dato:
- Samlet antal tests
- Antal beståede tests
- Antal test mislykkedes
- Antal igangværende tests
- Antal afventende tests
Fejldetaljer:
hvordan man udpakker 7z-filer på mac
- Antal registrerede mangler
- Hver defekt skal have nedenstående detaljer:
- ID, resumé, komponent, sværhedsgrad
- Det samlede antal fejl, der er logget indtil nu (i Acceptance Testing Phase).
Denne rapport skal gennemgås dagligt for at sikre, at udførelsen er på rette spor, og at der ikke er nogen afvigelse fra de planlagte tidsplaner.
Resumérapport om accepttest
Dette er rapporten, der opsummerer status for hele accepttestfasen. Dette involverer detaljer som testaktiviteter, referencer til opfyldte kriterier, kravspecifikationer, forretningsregler, udførelsesresultater, planlagte tidsplaner, afvigelser osv.
Generisk skabelon til oversigtsrapport om accepttest:
Resumé
Afvigelser
Resultater
Evaluering
Henstilling
Indsats
Sign-off-rapport
Når produktet har bestået acceptstest, anbefales det at gå live. Før den lanceres til produktion, skal den underskrives formelt.
Generisk skabelon til afmeldingsrapport:
Produktnavn, frigivelsesversion, build-nummer
Seneste rapport
Bedømt den
Anmeldt af
Gennemgå kommentarer
Tilmeldingsdato
Sign-Off af
Sign-Off-kommentarer
Generelt skal enhver af de ovennævnte rapporter gennemgås af større interessenter for dens skabelon og skal være aftalt om, hvad der skal gå som informationen indeni.
Alle detaljer, der bliver udfyldt i rapporten, skal krydstjekkes, før de deles med interessenterne. Eventuelle uoverensstemmelser i rapporten vil have stor indflydelse på forretningsbeslutningen og kan resultere i produktsvigt på markedet.
Derfor skal rapportering altid håndteres af specialister eller seniormedlemmer i teamet.
Acceptantestning i smidig
I Adræt , Acceptkriterier for hver brugerhistorie er målrettet mod accepttest, dvs. accepttest er afledt af acceptkriterierne i en brugerhistorie. Hver acceptkriterium kan have en eller flere acceptstests, der dækker scenariet.
Acceptantest er normalt designet af en kvalitetssikring, der er fagmæssig ekspertise i området. Acceptantestning i Agile starter meget tidligt sammenlignet med de andre tilgange, normalt inden for selve sprinten.
Det udføres meget ofte, da hver sprint vil have nye brugerhistorier, der kommer op og også forbedringer / fortsættelse af de tidligere historier.
Acceptantest udføres på to forskellige stadier i Agile:
- Når funktionen oprettes og i sin indledende fase - grundlæggende.
- Når funktionen er integreret og stabiliseret med produktets andre funktioner.
Hver brugerhistorie her skal gennemgå acceptstest og skal videregives til overvejelse. Eventuelle fejl i accepttesten skal betragtes som en høj prioritet og løses med det samme, dette vil igen have acceptstesten til at udføre den.
Historiepunkter gives til hver brugerhistorie baseret på succesen med Acceptance-testresultater for hvert af acceptkriterierne. Acceptance Testing definerer også færdiggørelsen på User Story-niveau og angiver, at acceptkriterierne for historien er opfyldt.
Hvem udfører test af accept i smidig?
Normalt udfører produktadministratorer, fagemneekspertise (kan være kunde- og / eller betatestere) accepttest i et smidigt miljø. Nogle gange involverer QA også denne aktivitet sammen med deres regelmæssige regressionsopgaver.
Fordele ved acceptprøvning i smidig
Der er flere fordele ved Acceptance Testing i Agile.
Fordelene er:
- Tættere samarbejde mellem Product Manager og teamet.
- Opbygger tillid på User Story niveau.
- Hjælper med at udlede flere scenarier til at dække hvert acceptkriterium.
- Øget sandsynlighed for at improvisere produktets løsninger gennem acceptkriterier i brugerhistorier.
Ulemper
Selvom der er flere fordele, er der også visse ulemper.
Ulemper inkluderer:
- Ikke alle historierne kan overvejes til accepttest. Kun funktionelle historier, der skal dækkes - Historisk dækning kan komme ned.
- Ikke alle acceptkriterier kan overvejes til accepttest. Kun funktionelle kriterier skal dækkes - Acceptkriterier klog dækning inden for brugerhistorien kan komme ned.
- Da interessenter fra forskellige baggrunde er involveret, og da historisk vis accepttest udføres direkte, er det ret svært for alle at være på samme side (dybest set for at forstå niveauet i den enkelte brugerhistorie).
- Da frigivelsesvarigheden er mindre sammenlignet med andre tilgange, er det ret vanskeligt at imødekomme accepttest i sprints.
Acceptance Test Driven Development (ATDD)
Dette er en af Agile-udviklingspraksis, hvor hele teamet sammen diskuterer hvert af acceptkriterierne i User Story og bygger stærke accepttests omkring dem.
Dette skyldes, at forskellige perspektiver fra hvert af teammedlemmerne giver en ny måde at tænke på hvert af acceptkriterierne og vil ankomme med et stort antal accepttest, der dækker flere scenarier. Sommetider, ATDD kaldes også Story Test Driven Development (STDD).
Faktisk sker ATDD inden udviklingen starter. Så udviklerne ved denne tilgang vil vide, hvad der faktisk forventes, og hvordan man opnår det. Hele teamet deler en fælles forståelse af funktionen og hvad der bygges.
Dette beskriver, hvordan produktet bygges og til gengæld giver en retvisende ide om, hvordan produktet rent faktisk vil fungere, inden det afleveres til test. Derfor betegnes det som “ Acceptanstestdrevet udvikling ”.
Konklusion
Acceptantestning i en hvilken som helst af tilgangerne har det fælles mål at opbygge kundernes tillid og tilfredshed med produktet, der er udviklet inden det går i live. Dette opnås kun, når der ikke er / færre defekter med lav sværhedsgrad i produktet, der ikke hæmmer nogen af funktionerne.
I en nøddeskal:
- Accept test er bestået.
- Mangler er i acceptable niveauer.
- Flowmæssig / Scenariomæssig dækning opnået.
- Produkt og dets løsninger accepteres.
- Kunden er sikker nok på produktet.
- Alle produktdokumenterne opdateres til at matche de nyeste funktioner.
- Resultat for holdets indsats.
- Godt at gå videre med produktionsstart.
Forrige vejledning | NÆSTE vejledning
Håber du ville have fået enorm viden fra disse Acceptance Testing Tutorials. Du er velkommen til at dele dine tanker og fremsætte dine spørgsmål i kommentarfeltet nedenfor.
Anbefalet læsning
- Eksempel på fejlrapport
- Eksempel på testcase-skabelon med eksempler på testcase [Download]
- ISTQB-testcertificeringseksempler på spørgsmålspapirer med svar
- Sådan skriver du softwaretest ugentlig statusrapport
- Sådan skriver du en effektiv testoversigtsrapport [Download af prøverapport]
- Hvad er acceptantestning (En komplet guide)
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Funktionel testning mod ikke-funktionel testning