Software Testing status Reporting
” avtalet att en viss information, i ett visst format, kommer att skickas av ett visst team/individ, vid vissa tidsintervall, till vissa medlemmar – är som ett handslag – ett erkännande att oavsett vad resultatet av en uppgift till hands, du skulle hållas postat om det, förr än senare.”
Detta är den första delen av en IT-professionell ed. Jag skojar! Det finns ingen ed, men om det fanns en, skulle det säkert toppa listan över objekt i den. Eller hur?
ansvarighet och transparens (a & T) är avgörande för varje IT – projekt på olika nivåer-projektnivå, teamnivå, Uppgiftsnivå och även en individnivå. Hur ser vi till att dessa attribut uppfylls? Svaret är-kommunicera, mer formellt-statusrapportering!
på individnivå skickar vi inte alla rapporter, mestadels, EOD varje dag för att kommunicera prestationen (eller icke-prestationen) av dina dagliga uppgifter. Detta bevisar att du faktiskt ” är ” medveten om vad dina uppgifter skulle börja med.
daglig statusrapport
informationen som måste ingå i en individs ”dagliga statusrapport” är:
- Vad gjorde du idag?
- vad planerar du att göra imorgon?
- mötte du några problem under din dag? Om ja, hur löste du dem eller är de fortfarande öppna?
- behöver du några ingångar för imorgon? Om ja, från vem och vad är de?
mottagaren av detta e – postmeddelande/rapport är i allmänhet chef, även teammedlemmarna kan CC ’ ed i vissa fall-detta beror på kommunikationsprotokollet laget följer.
testrapporter
nu är det dags att bli specifik och lära sig allt om de rapporter som test/QA-team skickar.
testteam skickar ut olika rapporter i olika faser i STLC.
- Testplanstatus
- Testdokumentationsstatus
- Testkörningsstatus (felstatus)
testplan: det räcker att kommunicera med resten av projektgrupperna, när en testplan skapas eller när en större förändring görs i den.
testdokumentation: låt alla team veta när utformningen av testerna, datainsamlingen och andra aktiviteter har börjat och även när de är färdiga. Denna rapport kommer inte bara att låta dem veta om framstegen i uppgiften utan också signalera de lag som behöver granska och tillhandahålla signoff på artefakterna, att de är uppe nästa.
test Execution: utförande är fasen i ett projekt när testteamet är det primära fokuset – positivt och negativt – vi är både hjältarna och skurkarna.
en typisk dag under en testcykel görs inte om inte den dagliga statusrapporten skickas ut. I vissa lag kunde de komma överens om en veckorapport, men att skicka den dagligen är normen.
det är inte heller ovanligt att ha ETT Statusmöte varje dag (eller vecka) för att presentera QA-lagets status för de berörda parterna.
därför kan läget för en statusrapport vara:
- e-post/dokument
- Möte/presentation
- båda – daglig e-post och veckomöte eller så.
Testkörningsstatusrapport
Daglig/Veckovis Testkörningsrapport:
Vad är det? I allmänhet är detta en kommunikation som skickas ut för att skapa öppenhet för QA – teamets aktiviteter under dagen under testcykeln-inkluderar både Defektinformation och Testfallsinformation.
vem ska det gå till? – Normalt sett är utvecklingsteamet, miljösupportteamet, Affärsanalytikern och projektteamet mottagare/mötesdeltagare. Testplanen är det bästa stället för dig att hitta denna information.
vad innehåller en Testkörningsstatusrapport? – 10 poäng
- antal testfall planerade för den dagen
- antal testfall utförda – den dagen
- antal testfall utförda totalt
- antal fel som uppstått den dagen/och deras respektive tillstånd
- antal fel som hittills uppstått/och deras respektive tillstånd
- antal kritiska fel – fortfarande öppen
- miljö stilleståndstider – om någon
- Showstoppers-om någon
- bilaga av testkörningsbladet / länk till testhanteringsverktyget där testfallen är placerade
- bilaga felrapport / länk till fel / Test / verktyg som används för incidenthantering
ovanstående 10 poäng, om du märker noga är rådata. Rapportering fakta är en sak och rapportera några ’smarta’ fakta är en annan. Hur förfinar vi denna information?
- visar den totala statusen med en färgindikator. Till exempel, grön – i tid, Orange – något bakom men kan absorbera fördröjningen, röd – försenad.
- inkludera några enkla mätvärden som Pass % av testfall hittills, defektdensitet, % av allvarliga defekter; genom att göra detta ger du inte bara siffror, du ger faktiskt en glimt av kvaliteten på den produkt du testar.
- om en betydande fas är klar – markera det.
- om det finns en kritisk defekt som kommer att blockera alla/en del av framtida utförande – markera det.
- om du använder en presentation, se till att inkludera några grafer för att få bättre effekt.
till exempel är nedanstående Graf en representation av antalet öppna defekter, modulmässigt:
bortsett från dessa kan du också valfritt inkludera:
- vilka aktiviteter planeras nästa?
- behöver du några ingångar från något av de andra lagen och i så fall vad?
slutligen, några tips för att hjälpa processen längs:
- var kortfattad samtidigt komplett
- se till att resultaten du rapporterar är korrekta
- använd punktpunkter för att göra rapporten mycket läsbar
- dubbelkontroll för att inkludera rätt datum, ämne, lista och bilagor.
- om rapporten är för stor och har för många faktorer att rapportera: placera den på en gemensam plats som en fil och skicka en länk i e-postmeddelandet istället för själva filen. (Se till att mottagarna har åtkomstbehörigheter till den här platsen och filen)
- om det är ett Statusmöte – var beredd på presentationen, kom i tid och viktigast av allt, behåll en jämn ton (var inte för stolt över defekterna – de är i allmänhet ”dåliga nyheter”).
Provstatusrapport
QA-Teststatusrapport:
efter dessa riktlinjer kom vi fram till statusrapporten nedan.
för att underlätta för våra läsare har vi inkluderat 3 ark som förmedlar olika nivåer av information som de kan förmedla.
blad 1 – är en sammanfattning av projektets övergripande status.
blad 2 – handlar mer om den enskilda detaljerna i Testfallets status.
blad 3 – är ett exempel felrapport.
ladda ner denna Exempelstatusrapport XLS Mall med alla tre ark. (Högerklicka på länken och välj ’ Spara länk som..’för att ladda ner)
om Författare-detta är en artikel av STH-teammedlem Swati Seela. Du kan veta mer om henne på vår sida för programvarutestning.
