Sådan rapporteres Testudførelse Smart- [Hent Statusrapportskabelon]

statusrapportering

“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 er ved hånden, vil 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 dette helt sikkert øverst på listen over varer i den. Er det ikke?

ansvarlighed og gennemsigtighed (a & T) er afgørende for ethvert 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-kommunikation, mere formelt-statusrapportering!

på individuelt niveau sender vi ikke alle rapporter, for det meste, EOD hver dag for at kommunikere opfyldelsen (eller ikke-opfyldelsen) af dine daglige opgaver. Dette går for at bevise, at du faktisk “er” klar over, hvad dine opgaver var at starte med.

daglig statusrapport

de oplysninger, der skal være en del af en persons “daglige statusrapport”, er:

• Hvad har du lavet i dag?
• hvad planlægger du at gøre i morgen?
• har du haft problemer i løbet af din dag? 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 ‘ ed i nogle tilfælde-dette afhænger af den kommunikationsprotokol, teamet følger.

testrapporter

nu er det tid til at blive specifik og lære alt om de rapporter, som test – /kvalitetsteam sender.

Testhold sender forskellige rapporter i forskellige faser i STLC.

• Testplanstatus
• Testdokumentationsstatus
• Testudførelsesstatus (fejlstatus)

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 af den.

Testdokumentation: lad alle holdene vide, hvornår design af testene, dataindsamling og andre aktiviteter er begyndt, og også når de er færdige. Denne rapport vil ikke kun lade dem vide om opgavens fremskridt, men også signalere de hold, der skal gennemgå og give signoff på artefakterne, at de er næste gang.

Testudførelse: udførelse er fasen af et projekt, hvor testteamet er det primære fokus – positivt og negativt – vi er både helte og skurke.

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 at få den sendt dagligt er normen.

det er heller ikke ualmindeligt at have et statusmøde hver dag (eller uge) for at præsentere KVALITETSSTYRINGSHOLDETS status for de berørte parter.

derfor kan tilstanden af 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 meddelelse, der sendes ud for at skabe gennemsigtighed i KVALITETSSIKRINGSTEAMETS aktiviteter i løbet af testcyklussen – inkluderer både Defektinformation og Test case run-information.

Hvem skal det gå til? – Normalt er udviklingsholdet, 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

1. antal planlagte testsager for den pågældende dag
2. antal udførte testsager – den pågældende dag
3. antal udførte testsager samlet
4. antal fejl, der opstod den pågældende dag/og deres respektive tilstande
5. antal fejl, der er opstået indtil videre/og deres respektive tilstande
6. antal kritiske defekter – stadig åben
7. miljø driftsstop – hvis nogen
8. visstoppere – hvis nogen
9. vedhæftning af testudførelsesarket / link til teststyringsværktøjet, hvor testcases er placeret
10. vedhæftning til fejlrapporten / linket til defekt / Test / styringsværktøjet, 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 samlede 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 Pass % af testtilfælde hidtil, defektdensitet, % af alvorlige defekter; ved at gøre dette giver du ikke bare tal, du giver faktisk et glimt af kvaliteten af det produkt, du tester.
• hvis en betydelig fase er afsluttet – fremhæv det.
• hvis der er en kritisk fejl, der vil blokere alle/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 er nedenstående graf en repræsentation af antallet af åbne defekter, modulvis:

bortset fra disse kan du også valgfrit inkludere:

• Hvad er de planlagte aktiviteter næste?
• har du brug for input fra nogen af de andre hold, og hvis ja, hvad?

endelig et par pointers til at hjælpe processen sammen:

• vær kortfattet på samme tid komplet
• sørg for, at de resultater, du rapporterer, er nøjagtige
• brug punktopstillinger til at gøre rapporten meget læsbar
• 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, Oprethold en jævn tone (vær ikke for stolt af manglerne – de er generelt “dårlige nyheder”).

prøve statusrapport

kvalitetstest statusrapport:

efter disse retningslinjer ankom vi nedenstående statusrapport.

for at gøre det lettere for vores læsere har vi inkluderet 3 ark, der formidler forskellige niveauer af information, som de kan formidle.

ark 1 – er en oversigt over projektets samlede status.
ark 2 – er mere om den enkelte detalje af Test case status.
ark 3-er en prøve fejlrapport.

Hent Denne skabelon med alle tre ark. (Højreklik på linket og vælg ‘Gem link som..’at hente)

om Forfatter – dette er en artikel af STH teammedlem Sati Seela. Du kan få mere at vide om hende på vores kursusside.