how report test execution smartly
Software Testing Status Rapportering
”Aftalen om, at en bestemt information i et bestemt format vil blive sendt af et bestemt team / individ med bestemte tidsintervaller til bestemte medlemmer - er som et håndtryk - en anerkendelse af, at uanset hvad resultatet af en opgave på hånd, ville du blive holdt opdateret om det, før end senere. ”
Dette er den første del af en it-professionel ed. Nå, jeg laver sjov! Der er ingen ed, men hvis der var en, ville det helt sikkert toppe listen over emner i den. Er det ikke?
Ansvarlighed og gennemsigtighed (A & T) er afgørende for hvert it-projekt på forskellige niveauer - projektniveau, teamniveau, opgaveniveau og også et individuelt niveau. Hvordan sørger vi for, at disse attributter er opfyldt? Svaret er - kommunikere, mere formelt- Statusrapportering !
På individuelt niveau sender vi ikke alle rapporter, hovedsageligt EOD hver dag for at kommunikere gennemførelsen (eller manglende gennemførelse) af dine daglige opgaver. Dette beviser, at du faktisk “er” klar over, hvad dine pligter var at starte med.
Hvad du vil lære:
Daglig statusrapport
De oplysninger, der skal være en del af en persons 'Daglige statusrapport' er:
flet sorteringskode i c ++ med rekursion
- Hvad lavede du i dag?
- Hvad planlægger du at gøre i morgen?
- Stod du over for problemer i løbet af dagen? Hvis ja, hvordan løste du dem, eller er de stadig åbne?
- Har du brug for input til i morgen? Hvis ja, fra hvem og hvad er de?
Modtageren af denne e-mail / rapport er generelt manager, også teammedlemmerne kan CC'es i nogle tilfælde - dette afhænger af kommunikationsprotokollen, som teamet følger.
Testrapporter
Nu er det tid til at blive specifik og lære alt om de rapporter, som Test / QA-hold sender.
Testhold sender forskellige rapporter ud i forskellige faser i STLC.
- Testplan status
- Test dokumentations status
- Testudførelsesstatus (Defektstatus)
Testplan : Det er nok at kommunikere med resten af projektteamene, når der oprettes en testplan, eller når der foretages en større ændring i den.
Testdokumentation : Lad alle holdene vide, hvornår design af test, dataindsamling og andre aktiviteter er begyndt, og også når de er færdige. Denne rapport fortæller dem ikke kun om opgavens forløb, men signalerer også de hold, der har brug for at gennemgå og give afsked på artefakterne, at de er næste gang.
Testudførelse : Udførelse er den fase af et projekt, når testteamet er det primære fokus - positivt og negativt - vi er både heltene og skurkene.
En typisk dag under en testcyklus udføres ikke, medmindre den daglige statusrapport sendes ud. I nogle hold kunne de blive enige om en ugentlig rapport, men det er normen at have den sendt dagligt.
Det er heller ikke ualmindeligt, at der afholdes et statusmøde hver dag (eller uge) for at præsentere QA-holdets status for de berørte parter.
Derfor kan tilstanden til en statusrapport være:
- E-mail / dokument
- Møde / præsentation
- Begge - daglig e-mail og ugentligt møde eller deromkring.
Testudførelsesstatusrapport
Daglig / ugentlig testudførelsesrapport:
Hvad er det? Generelt er dette en kommunikation, der sendes for at skabe gennemsigtighed for QA-teamets aktiviteter i løbet af testcyklussen - inkluderer både fejlinformation og testkørselsinformation.
Hvem skal det gå til? - Normalt er udviklingsteamet, miljøstøtteteamet, forretningsanalytikeren og projektteamet modtagere / mødedeltagere. Testplanen er det bedste sted for dig at finde disse oplysninger.
Hvad indeholder en testudførelsesstatusrapport? - 10 point
- Antal testsager, der er planlagt den dag
- Antal eksekverede testsager - den dag
- Antal testsager, der er udført samlet
- Antal defekter, der er fundet den dag / og deres respektive stater
- Antal defekter hidtil / og deres respektive tilstande
- Antal kritiske fejl - stadig åben
- Driftsstop for miljøet - hvis der er nogen
- Showstoppers - hvis nogen
- Vedhæftning af testudførelsesarket / link til Test Management værktøj hvor testsagerne er placeret
- Vedhæftet fil til fejlrapporten / linket til det defekt / test / styringsværktøj, der bruges til hændelsesstyring
Ovenstående 10 point, hvis du bemærker nøje, er rådataene. Rapportering af fakta er en ting, og rapportering af nogle 'smarte' fakta er en anden . Hvordan forfiner vi disse oplysninger?
- Viser den overordnede status med en farveindikator. For eksempel, Grøn - til tiden, orange - lidt bagud, men kan absorbere forsinkelsen, rød - forsinket.
- Inkluder nogle enkle målinger som Bestået% af testtilfælde hidtil, mangletæthed,% af alvorlige mangler; ved at gøre dette giver du ikke bare tal, du giver faktisk et glimt af kvaliteten af det produkt, du tester.
- Hvis en væsentlig fase er afsluttet - fremhæv det.
- Hvis der er en kritisk defekt, der vil blokere hele / en del af fremtidig udførelse - fremhæv det.
- Hvis du bruger en præsentation, skal du sørge for at medtage nogle grafer for at få en bedre effekt.
For eksempel, nedenstående graf er en repræsentation af antallet af åbne fejl modulvis :
Bortset fra disse kan du også vælge:
- Hvad er de aktiviteter, der planlægges næste gang?
- Har du brug for input fra et af de andre hold, og i så fald hvad?
Endelig et par tip til at hjælpe processen:
- Vær kortfattet på samme tid komplet
- Sørg for, at de resultater, du rapporterer, er korrekte
- Brug punktpunkter for at gøre rapporten meget læselig
- Dobbeltkryds for at inkludere den rigtige dato, emne, liste og vedhæftede filer.
- Hvis rapporten er for stor og har for mange faktorer til at rapportere: placer den på en fælles placering som en fil og send et link i e-mailen i stedet for selve filen. (Sørg for, at modtagerne har adgangstilladelser til denne placering og filen)
- Hvis det er et statusmøde - Vær forberedt på præsentationen, ankom til tiden og vigtigst af alt, hold en jævn tone (vær ikke for stolt af manglerne - de er generelt 'dårlige nyheder').
Eksempel på statusrapport
QA-teststatusrapport:
Efter disse retningslinjer ankom vi nedenstående statusrapport.
For at gøre det lettere for vores læsere har vi inkluderet 3 ark, der overfører forskellige informationsniveauer, som de kan formidle.
Ark 1 - er en oversigt over projektets overordnede status.
Ark 2 - handler mere om den individuelle detalje i testsagens status.
Ark 3 - er en stikprøverapport.
start et java-projekt i formørkelse
Download dette Eksempel på statusrapport Xls-skabelon med alle tre ark. (Højreklik på linket og vælg 'Gem link som ..' for at downloade)
Om forfatter - Dette er en artikel af STH-teammedlem Swati Seela. Du kan vide mere om hende på vores Software testkursus side .
Del dine kommentarer og spørgsmål med os nedenfor.
Anbefalet læsning
- Hvordan man skriver softwaretest ugentlig statusrapport
- Sådan opdateres TestLink Test Case Execution Status eksternt via Selen - Tutorial # 3
- Sådan skriver du en effektiv testoversigtsrapport (Download af prøverapport)
- Eksempel på fejlrapport
- Eksempelskabelon til acceptrapport med eksempler
- Standard Template Library (STL): En kort introduktion
- Oprettelse af generik og testuites - Selen Tutorial # 22
- Eksempel på testcase-skabelon med eksempler på testcase (Download)