Meny

Hvordan rapportere testutførelse smart - (Last ned statusrapportmal)

how report test execution smartly

Prøv Instrumentet Vårt For Å Eliminere Problemer

Statusrapportering av programvaretest

“Avtalen om at en viss informasjon, i et bestemt format, vil bli sendt av et bestemt team / individ, med bestemte tidsintervaller, til visse medlemmer - er som et håndtrykk - en erkjennelse av at uansett hva resultatet av en oppgave er hånd, du vil bli holdt oppdatert om det, før enn senere. ”

Dette er den første delen av en IT-profesjonals ed. Vel, jeg tuller! Det er ingen ed, men hvis det var en, vil dette helt sikkert toppe listen over gjenstander i den. Er det ikke?

Rapporter testutførelse smart

Ansvarlighet og gjennomsiktighet (A & T) er avgjørende for hvert IT-prosjekt på forskjellige nivåer - prosjektnivå, teamnivå, oppgavenivå og også et individuelt nivå. Hvordan sørger vi for at disse attributtene blir oppfylt? Svaret er - kommunisere, mer formelt- Statusrapportering !

På individnivå sender vi ikke alle rapporter, hovedsakelig, EOD hver dag for å kommunisere fullførelsen (eller ikke-fullførelsen) av dine daglige oppgaver. Dette beviser at du faktisk er 'klar over hva dine plikter var å begynne med.

QA-statusrapport

Hva du vil lære:

Daglig statusrapport

Informasjonen som må være en del av den enkeltes “Daglige statusrapport” er:

  • Hva gjorde du idag?
  • Hva planlegger du å gjøre i morgen?
  • Har du møtt noen problemer i løpet av dagen? Hvis ja, hvordan løste du dem, eller er de fremdeles åpne?
  • Trenger du noen innganger for i morgen? Hvis ja, fra hvem og hva er de?

Mottakeren av denne e-posten / rapporten er generelt leder, også teammedlemmene kan i noen tilfeller være CC’ed - dette avhenger av kommunikasjonsprotokollen teamet følger.

programvare for å laste ned videoer fra nettsteder

Testrapporter

Nå er det på tide å bli spesifikk og lære mer om rapportene som Testing / QA-team sender.

Testgrupper sender ut forskjellige rapporter i forskjellige faser i STLC.

  • Testplanstatus
  • Test dokumentasjonsstatus
  • Testutførelsesstatus (Defektstatus)

Testplan : Det er nok å kommunisere med resten av prosjektgruppene, når en testplan lages eller når det gjøres en større endring i den.

Testdokumentasjon : La alle teamene vite når utformingen av testene, datainnsamlingen og andre aktiviteter har begynt, og også når de er ferdige. Denne rapporten vil ikke bare gi dem beskjed om fremdriften i oppgaven, men også signalisere teamene som trenger å gjennomgå og gi pålogging om gjenstandene, at de er neste.

Testutførelse : Utførelse er fasen av et prosjekt når testteamet er hovedfokuset - positivt og negativt - vi er både heltene og skurkene.

En typisk dag i løpet av en testsyklus gjøres ikke med mindre den daglige statusrapporten sendes ut. I noen lag kunne de bli enige om en ukentlig rapport, men å få den sendt daglig er normen.

Det er heller ikke uvanlig å ha et statusmøte hver dag (eller uke) for å presentere QA-teamets status for de berørte partene.

Derfor kan modusen til en statusrapport være:

  • E-post / dokument
  • Møte / presentasjon
  • Begge - daglig e-post og ukentlig møte eller så.

Test utførelsesstatusrapport

Daglig / ukentlig testutførelsesrapport:

Hva er det? Generelt sett er dette en kommunikasjon som sendes ut for å etablere gjennomsiktighet for QA-teamets aktiviteter i løpet av testsyklusen - inkluderer både feilinformasjon og informasjon om testkjøring.

Hvem skal det gå til? - Normalt er utviklingsteamet, miljøstøtteteamet, forretningsanalytikeren og prosjektgruppen mottakere / møtedeltakere. Testplanen er det beste stedet å finne denne informasjonen.

Hva inneholder en testutførelsesstatusrapport? - 10 poeng

  1. Antall testsaker planlagt den dagen
  2. Antall utførte testsaker - den dagen
  3. Antall testsaker utført samlet
  4. Antall feil som ble påført den dagen / og deres respektive stater
  5. Antall feil hittil / og deres respektive stater
  6. Antall kritiske feil - fremdeles åpen
  7. Driftsstopp for miljøet - hvis noen
  8. Showstoppers - hvis noen
  9. Vedlegg av testutførelsesarket / lenke til Test Management verktøy der prøvesakene er plassert
  10. Vedlegg til feilrapporten / lenken til defekt / test / styringsverktøyet som brukes til hendelsesbehandling

Ovennevnte 10 poeng, hvis du merker nøye er rådataene. Å rapportere fakta er en ting og å rapportere noen ‘smarte’ fakta er en annen . Hvordan avgrenser vi denne informasjonen?

  • Viser totalstatusen med en fargeindikator. For eksempel, Grønn - i tide, oransje - litt bak, men kan absorbere forsinkelsen, rød - forsinket.
  • Inkluder noen enkle beregninger som bestått% av testtilfellene så langt, mangeltetthet,% av alvorlige mangler; ved å gjøre dette gir du ikke bare tall, du gir faktisk et glimt av kvaliteten på produktet du tester.
  • Hvis en betydelig fase er fullført, fremhev det.
  • Hvis det er en kritisk mangel som kommer til å blokkere hele / en del av fremtidig utførelse - fremhev det.
  • Hvis du bruker en presentasjon, må du sørge for å ta med noen grafer for å få en bedre innvirkning.

For eksempel, grafen nedenfor er en representasjon av antall åpne mangler, modulmessig :

Åpne feilrapport

Bortsett fra disse kan du også inkludere:

  • Hva er aktivitetene planlagt neste gang?
  • Trenger du noen innspill fra noen av de andre lagene, og i så fall hva?

Til slutt noen tips for å hjelpe prosessen:

  • Vær kortfattet samtidig komplett
  • Forsikre deg om at resultatene du rapporterer er nøyaktige
  • Bruk punktpunkter for å gjøre rapporten veldig lesbar
  • Dobbeltsjekk for å inkludere riktig dato, emne, liste og vedlegg.
  • Hvis rapporten er for stor og har for mange faktorer å rapportere: plasser den på et felles sted som en fil og send en lenke i e-posten i stedet for selve filen. (Pass på at mottakerne har tilgangstillatelser til denne plasseringen og filen)
  • Hvis det er et statusmøte - Vær forberedt på presentasjonen, ankom i tide og viktigst av alt, hold en jevn tone (ikke vær for stolt av manglene - de er generelt 'dårlige nyheter').

Eksempel på statusrapport

QA Testing Status Report:

Etter disse retningslinjene kom vi til statusrapporten nedenfor.

Test statusrapport

For å gjøre det lettere for våre lesere, har vi tatt med 3 ark som formidler forskjellige nivåer av informasjon de kan formidle.

Ark 1 - er en oppsummering av prosjektets overordnede status.
Ark 2 - handler mer om den enkelte detalj i testsakens status.
Ark 3 - er et eksempel på en feilrapport.

beste python ide mac os x

Last ned dette Eksempel på statusrapport Xls-mal med alle tre arkene. (Høyreklikk på lenken og velg ‘Lagre lenke som ..’ for å laste ned)

Om forfatteren - Dette er en artikkel av STH-teammedlem Swati Seela. Du kan vite mer om henne på vår Programvare testkurs side .

Del dine kommentarer og spørsmål med oss ​​nedenfor.

Anbefalt lesing

^