Software Testing Status Reporting
” de overeenkomst dat een bepaalde informatie, in een bepaald formaat, door een bepaald team/individu, op bepaalde intervallen van tijd, aan bepaalde leden zal worden verzonden – is als een handdruk – een erkenning dat het niet uitmaakt wat de uitkomst van een taak bij de hand, u zou worden gehouden over het, vroeger dan later.”
dit is het eerste deel van de eed van een IT-professional. Nou, ik maak een grapje! Er is geen eed, maar als er een was, zou dit zeker bovenaan de lijst van items in het. Is het niet?
verantwoording en transparantie (A & T) zijn essentieel voor elk IT – project op verschillende niveaus-projectniveau, teamniveau, taakniveau en ook een individueel niveau. Hoe zorgen we ervoor dat aan deze eigenschappen wordt voldaan? Het antwoord is – communiceren, formeler-Statusrapportage!
op individueel niveau sturen we niet allemaal dagelijks rapporten, meestal EOD, om de vervulling (of niet-vervulling) van uw dagelijkse taken te communiceren. Dit bewijst dat je eigenlijk “bewust” bent van wat je taken waren om mee te beginnen.
dagelijks statusrapport
de informatie die deel moet uitmaken van het “dagelijks statusrapport” van een individu is::
- wat heb je vandaag gedaan?
- Wat bent u van plan morgen te doen?
- heeft u tijdens uw dag problemen gehad? Zo ja, hoe heb je ze opgelost of zijn ze nog steeds open?
- heeft u input nodig voor morgen? Zo ja, van wie en wat zijn zij?
de ontvanger van dit e – mail/rapport is over het algemeen de manager, ook de teamleden kunnen in sommige gevallen GECC ‘ ed worden-dit hangt af van het communicatieprotocol dat het team volgt.
testrapporten
nu is het tijd om specifieke rapporten te krijgen en alles te leren over de rapporten die test – /QA-teams verzenden.
testteams zenden verschillende rapporten uit in verschillende fasen van het STLC.
- Status testplan
- Status testdocumentatie
- Status testuitvoering (Defectstatus))
testplan: het is voldoende om te communiceren met de rest van de projectteams, wanneer een testplan wordt gemaakt of wanneer er een grote verandering in wordt aangebracht.
testdocumentatie: laat alle teams weten wanneer met het ontwerpen van de tests, het verzamelen van gegevens en andere activiteiten is begonnen en ook wanneer deze zijn voltooid. Dit rapport zal hen niet alleen laten weten over de voortgang van de taak, maar ook de teams die nodig hebben om te beoordelen en tekenen op de artefacten, dat ze de volgende zijn.
testuitvoering: uitvoering is de fase van een project waarin het testteam de primaire focus is – positief en negatief-we zijn zowel de helden als de schurken.
een typische dag tijdens een testcyclus wordt niet gedaan, tenzij het dagelijkse statusrapport wordt verzonden. In sommige teams konden ze het eens worden over een wekelijks rapport, maar het dagelijks versturen is de norm.
het is ook niet ongewoon om elke dag (of week) een Statusvergadering te houden om de status van het QA-team aan de betrokken partijen te presenteren.
daarom kan de modus van een statusrapport:
- e – mail/document
- vergadering / presentatie
- beide-dagelijkse e-mail en wekelijkse vergadering of zo.
Testuitvoeringsstatusrapport
Dagelijks / Wekelijks Testuitvoeringsrapport:
Wat is het? Over het algemeen is dit een mededeling die wordt verzonden om transparantie te creëren voor de activiteiten van het QA – team van de dag tijdens de testcyclus-inclusief zowel Defectinformatie als testcase run-informatie.
naar wie moet het gaan? – Normaal gesproken zijn het ontwikkelingsteam, het Milieuondersteuningsteam, de Business Analist en het projectteam de ontvangers/deelnemers aan de vergadering. Het testplan is de beste plek voor u om deze informatie te vinden.
wat bevat een Testuitvoeringsstatusrapport? – 10 punten
- Aantal Test cases gepland voor die dag
- Aantal testcases uitgevoerd – die dag
- Aantal testcases uitgevoerd algehele
- Aantal Defecten aangetroffen die dag/en hun respectieve staten
- Aantal Defecten aangetroffen zo ver/en hun respectieve staten
- Aantal kritische Gebreken – nog open
- Milieu-onderbrekingen als
- Showstoppers als
- Bijlage van de uitvoering van de test-blad / de Link naar de Test Management tool waar de testcases zijn geplaatst
- Attachment naar het bugrapport / link naar het Defect / Test / Management tool gebruikt voor incidentmanagement
de bovenstaande 10 punten, als u goed merkt is de ruwe gegevens. Het rapporteren van de feiten is één ding en het rapporteren van een aantal ‘slimme’ feiten is een ander. Hoe verfijnen we deze informatie?
- geeft de algemene status weer met een kleurindicator. Bijvoorbeeld, groen – op tijd, Oranje-iets achter, maar kan absorberen de vertraging, rood-vertraagd.
- omvatten enkele eenvoudige metrics zoals Pass % van testgevallen tot nu toe, defectdichtheid, % van ernstige defecten; door dit te doen ben je niet alleen het geven van nummers, bent u eigenlijk het verstrekken van een glimp van de kwaliteit van het product dat u test.
- als een significante fase is voltooid – markeer dat.
- als er een kritisch defect is dat alle/een deel van toekomstige uitvoering zal blokkeren – markeer dat.
- als u een presentatie gebruikt, zorg er dan voor dat u enkele grafieken toevoegt om een betere impact te hebben.
bijvoorbeeld, de onderstaande grafiek is een weergave van het aantal open defecten, module-wise:
afgezien van deze, kunt u ook optioneel omvatten:
- Wat zijn de volgende activiteiten?
- hebt u input nodig van een van de andere teams en zo ja, wat?
tot slot enkele aanwijzingen om het proces te helpen:
- wees beknopt en tegelijkertijd compleet
- zorg ervoor dat de resultaten die u rapporteert accuraat zijn
- gebruik opsommingstekens om het rapport zeer leesbaar te maken
- controleer de juiste datum, onderwerp, lijst en bijlagen.
- als het rapport te groot is en te veel factoren heeft om te rapporteren: plaats het op een gemeenschappelijke locatie als een bestand en stuur een link in de e-mail in plaats van het bestand zelf. (Zorg ervoor dat de ontvangers toegangsrechten hebben tot deze locatie en het bestand)
- als het een Statusvergadering is – Wees voorbereid op de presentatie, kom op tijd en het belangrijkste, houd een gelijkmatige toon (wees niet te trots op de defecten – ze zijn in het algemeen “slecht nieuws”).
statusrapport voor monster
statusrapport voor QA-tests:
volgens deze richtlijnen kwamen we tot het onderstaande statusrapport.
voor het gemak van onze lezers hebben we 3 bladen opgenomen met verschillende niveaus van informatie die ze kunnen overbrengen.
fiche 1-geeft een samenvatting van de algemene status van het project.
datablad 2-gaat meer over de individuele details van de status van de TestCASE.
Sheet 3-is een voorbeeld van een bugrapport.
Download dit voorbeeld statusrapport XLS-sjabloon met alle drie de bladen. (Klik met de rechtermuisknop op de link en selecteer ‘Koppeling opslaan als..’om te downloaden)
over auteur – Dit is een artikel van STH teamlid Swati Seela. U kunt meer over haar weten op onze Software Testing cursus pagina.
