Meny

Eksempelmal for akseptrapport med eksempler

sample template acceptance test report with examples

Prøv Instrumentet Vårt For Å Eliminere Problemer

Oversikt over godkjenningstestrapport (del III):

Forrige veiledning | NESTE veiledning

I vår forrige opplæring om “ Akseptprøvedokumentasjon med sanntidsscenarier ”Vi diskuterte Acceptance Test plan.

I denne veiledningen tar vi en grundig titt på rapportering av Acceptance Test Status, Acceptance Test Summary og Sign-Off.

Noen generiske maler er inkludert i denne opplæringen for å forbedre forståelsen din på en bedre måte. Vi vil også sveve over konseptet Acceptance Testing in Agile and Acceptance Test Driven Development.

Kort fortalt vil denne opplæringen forklare deg om Acceptance test Status Report and Summary report sammen med noen generiske maler for din klare forståelse, og pusser også opp konseptet Acceptance testing i Agile og testdrevet utvikling på en lett forståelig måte.

Godkjennelsestestmal

Hva du vil lære:

Godkjenningsteststatusrapport

Godkjenningstestrapport bør alltid oppsummere akseptstestene som utføres sammen med resultatene. Den bør rettes til alle identifiserte interessenter som er en del av Acceptance Testing Phase. Når gjennomføringen av godkjenningstestene har startet, bør fremdriften rapporteres fra dag til dag.

Generisk mal for godkjenningstestrapport:

Dato :Godkjenningstest Status Rapport Dato

Dagens detaljer om gjennomføring av godkjenningstester:

  • Antall beståtte tester
  • Antall tester mislyktes
  • Antall pågående tester

Godkjennelsestester Utførelsesdetaljer til dato:

  • Totalt antall tester
  • Antall beståtte tester
  • Antall tester mislyktes
  • Antall pågående tester
  • Antall tester som venter

Feildetaljer:

konvertere char array til int c ++
  • Antall registrerte feil
  • Hver feil skal ha detaljene nedenfor:
    • ID, sammendrag, komponent, alvorlighetsgrad
  • Totalt antall feil som er logget til nå (i godkjenningstestfasen).

Denne rapporten må gjennomgås daglig for å sikre at gjennomføringen er på rett spor og at det ikke er noe avvik fra de planlagte tidsplanene.

Akseptprøve Sammendrag Rapport

Dette er rapporten som oppsummerer statusen for hele aksepttestfasen. Dette involverer detaljer som utførte testaktiviteter, referanser til kriterier oppfylt, kravspesifikasjoner, forretningsregler, utførelsesresultater, planlagte tidsplaner, avvik osv.

Generell mal for sammendragsrapport for godkjenningstest:

Sammendrag

Avvik

Avvik

Resultater

Rapporter

Evaluering

Anbefaling

defekter alvorlighetsgraden , og bestått innvirkning påvirker anbefalingen om at produktet skal lanseres i markedet.>

Anstrengelser

Anstrengelser

Avloggingsrapport

Når produktet har bestått godkjenningstesting, vil det anbefales å gå live. Før den lanseres til produksjon, må den signeres av formelt.

Generisk mal for påloggingsrapport:

Produktnavn, versjonsversjon, byggenummer

Siste rapport

Vurdert på

Anmeldt av

Gjennomgå kommentarer

Påloggingsdato

Avlogging av

Påloggingskommentarer

Generelt sett bør noen av de ovennevnte rapportene gjennomgås av store interessenter for sin mal og må avtales om hva som må gå som informasjonen i.

Alle detaljer som blir fylt ut i rapporten, bør krysses av før de deles med interessentene. Eventuelle avvik i rapporten vil ha stor innvirkning på forretningsbeslutningen og kan resultere i produktsvikt i markedet.

Derfor skal rapportering alltid håndteres av spesialister eller seniormedlemmer i teamet.

Akseptprøving i smidig

I Agile , Akseptkriterier for hver brukerhistorie er målrettet mot aksepttester, dvs. aksepttester er avledet fra akseptkriteriene i en brukerhistorie. Hver akseptkriterium kan ha en eller flere aksepttester for å dekke scenariet.

Akseptstester er vanligvis designet av en kvalitetssikring som er fagmessig ekspertise i området. Akseptprøving i smidig starter mye tidlig sammenlignet med de andre tilnærmingene, vanligvis innenfor selve spurtene.

Det utføres veldig ofte, da hver sprint vil ha nye brukerhistorier som kommer og forbedringer / fortsettelse av de tidligere historiene.

Akseptstesting utføres på to forskjellige stadier i Agile:

  • Når funksjonen er opprettet og i sin innledende fase - grunnleggende.
  • Når funksjonen er integrert og stabilisert med produktets andre funksjoner.

Hver brukerhistorie her må gjennomgå godkjennelsestest og skal bestås for vurdering. Eventuelle feil i godkjennelsestesten bør betraktes som en høy prioritet og løses umiddelbart, dette vil igjen ha akseptantesten for å utføre den.

Historiepoeng blir gitt til hver brukerhistorie basert på suksessen til Acceptance-testresultatene for hvert av akseptkriteriene. Akseptprøving definerer også fullføringen på User Story-nivå, og sier at Akseptkriteriene for historien er oppfylt.

Hvem utfører akseptattesting i smidig?

Vanligvis utfører produktsjefer, fagemneekspertise (kan være kunde- og / eller betatestere) akseptattesting i et smidig miljø. Noen ganger involverer QA også denne aktiviteten sammen med deres vanlige regresjonsoppgaver.

Fordelene med aksepttesting i smidig

Det er flere fordeler med akseptattesting i smidig.

Fordelene er:

  • Tettere samarbeid mellom produktsjef og teamet.
  • Bygger tillit på User Story-nivået.
  • Hjelper med å utlede flere scenarier for å dekke hvert akseptkriterium.
  • Økt sannsynlighet for å improvisere løsningene på produktet gjennom akseptkriterier i brukerhistorier.

Ulemper

Selv om det er flere fordeler, er det også visse ulemper.

Ulempene inkluderer:

  • Ikke alle historiene kan vurderes for aksepttesting. Bare funksjonelle historier som skal dekkes - Historisk visning kan komme ned.
  • Ikke alle akseptkriteriene kan vurderes for aksepttesting. Bare funksjonelle kriterier skal dekkes - Acceptance Criteria klok dekning i brukerhistorien kan komme ned.
  • Siden interessenter fra forskjellige bakgrunner er involvert og ettersom historiemessig akseptanstesting utføres direkte, er det ganske vanskelig for alle å være på samme side (i utgangspunktet å forstå nivået i den enkelte brukerhistorien).
  • Siden frigjøringsvarigheten er mindre sammenlignet med andre tilnærminger, er det ganske vanskelig å imøtekomme akseptattesting i sprints.

Akseptstestdrevet utvikling (ATDD)

Dette er en av Agile-utviklingspraksiser der hele teamet i samarbeid drøfter hvert av akseptakriteriene i User Story og bygger sterke aksepttester rundt dem.

Dette er fordi forskjellige perspektiver fra hvert av teammedlemmene vil gi en ny måte å tenke på hvert av akseptkriteriene og vil komme med et stort antall aksepttester som dekker flere scenarier. Noen ganger, ATDD kalles også Story Test Driven Development (STDD).

Egentlig skjer ATDD før utviklingen starter. Så, utviklerne, i denne tilnærmingen, vil vite hva som faktisk forventes og hvordan de skal oppnå det. Hele teamet vil dele en felles forståelse av funksjonen og hva som bygges.

Dette beskriver hvordan produktet blir bygget og i sin tur vil gi en god ide om hvordan produktet faktisk vil fungere før det overleveres for testing. Derfor blir det betegnet som ' Akseptprøvedrevet utvikling ”.

Konklusjon

Akseptprøving i en hvilken som helst tilnærming har det felles målet om å bygge kundetillit og tilfredshet med produktet som er utviklet før det går live. Dette oppnås kun når det ikke er / færre lave alvorlighetsdefekter i produktet som ikke hindrer noen av funksjonene.

I et nøtteskall:

  • Akseptprøver er bestått.
  • Mangler er i akseptable nivåer.
  • Flytmessig / scenarimessig dekning oppnådd.
  • Produktet og dets løsninger godtas.
  • Kunden er trygg nok på produktet.
  • Alle produktdokumentene er oppdatert for å matche de nyeste funksjonene.
  • Resultat for lagets innsats.
  • Godt å gå videre med produksjonslanseringen.

Forrige veiledning | NESTE veiledning

Håper du ville ha fått enorm kunnskap fra disse Acceptance Testing Tutorials. Del gjerne tankene dine og legg frem spørsmålene dine i kommentarfeltet nedenfor.

Anbefalt lesing

^