.
Bakgrund
Under de senaste 15 åren har jag deltagit i ett antal prestandatester och frapperats av den skiftande kvalitén rörande de skriftliga rapporterna av testernas resultat.
Prestandatestare har olika fallenhet för framställan av en prestandatestrapport, detta kan vi inte ändra på.
Min erfarenhet är dock att själva slutrapporten av prestandatesterna i många fall kan förbättras med mycket små medel, se längre ned ”De tio budorden vid framtagning av prestandatestrapport”.
Jag har inte föreslagit en exakt mall om de olika avsnitten i en prestandarapport, här är det de olika omständigheterna som spelar in. Exempelvis är det skillnad på en rapport som tas fram för applikationer som prestandatestas kontinuerligt varje månad jämfört med en applikation som efter flera månaders utvecklingsarbete skall prestandatestas.
En gammal kollega inom prestandatestområdet menade att om du efter ett dygn efter rapportens framställande öppnar den och upplever ljuv musik när du läser den, då vet du att mottagaren kommer att få en bra rapport.
Och visst är det så, du ger något till din uppdragsgivare och vet att han/hon kommer att uppskatta rapporten, det kallas yrkesstolthet.
Likheter mellan besiktningsprotokoll av bilar och rapport för prestandatester.
Vissa likheter finns i framtagningen av en besiktningsrapport och prestandatestrapport.
• Du vill genom kontroll, ok det är lagstadgat :), få reda på konditionen på din bil.
• Resultaten är baserade på ett antal tester av de verktyg besiktningsmannen förfogar över.
• Analysen av resultaten är besiktningsprotokollet.
• Sammanfattningen, som är muntlig och skriftlig, utgörs av en noggrann skala allt från körförbud till inga anmärkningar.
• Visst finns det olikheter, rekommendation är väl snarast ersatt med direktiv, exempelvis är körförbud ingen rekommendation utan snarast att betrakta som ett verkställande direktiv :).
De tio budorden vid framtagning av prestandatestrapport
1. Dela upp i tre delar, sammanfattning, analysen av testerna, resultaten av testerna, förklara uppdelningen.
Kommentarer: Förklara i början av rapporten att den är uppdelad på detta sätt. Resultaten av testerna tillsammans med dagbok/kommentarer till testerna finns i kapitlet resultatet av testerna. Analysen, här är det egentliga arbetet att tyda siffrorna från de olika mätarna. Sammanfattningen, här tas resultatet från analysen och jämförs med uppdragsbeskrivningen/målet med prestandatesterna. Observera att det naturligtvis finns flera kapitel i prestandatestrapport, exempelvis avgränsningar, prestandamål, etc. etc.
2. Sammanfattningens resultat skall kunna refereras till vilka analyser som gjordes och som i sin tur till refererar till resultaten av testerna.
Kommentar: Tangerar mycket punkt 1, det skall poängteras att det inte får finnas några lösa referenser. Allt material i rapporten har syfte att vara underlag för sammanfattningen och rekommendation.
3. Resultat i form av grafer/ eller tabeller läggs i kapitlet resultat av testerna.
Kommentar: Om det är en tabell/graf som är oerhört viktig för rekommendationen, lägg en direkt referens till denna och kommentera.
4. Fokusera alltid på uppdragsbeskrivningen, dvs. vad är det uppdragsgivaren vill ha svar på.
Kommentar: Det händer att uppdragsgivaren har angivet exakt vad prestandamålen är, men i de flesta fall ligger snarare uppdragsbeskrivningen att exempelvis ”applikationen skall klara av dagens trafik på webben”. Då är det viktigt att i uppdraget ange på vad detta innebär i prestandamål, detta görs med fördel tillsammans med uppdragsgivaren.
5. En rekommendation skall alltid göras, oavsett storleken på uppdraget.
Kommentar: Du kan och skall alltid ange en rekommendation, jfr med bilprovningen om besiktningsmannen skulle säga jag vet inte…, du har betalat för testen och vet inte vad rekommendationen är .. Däremot kan en rekommendation alltid vara med vissa förbehåll. Jfr med bilprovningen, ”din bil blev godkänd, men det är värt att notera visst glapp i övre styrleden höger sida som du bör åtgärda närmaste tiden”.
6. Stavfel och uppenbar dålig svenska, skall och kan undvikas.
Kommentar; Det är ju uppenbart, en slarvig hopsatt prestandatestrapport ger ett intryck av att kanske testerna också var slarviga. En prestandatestrapport, skall kunna läsas av både tekniker och beslutsfattare som inte är tekniskt lagda. Det finns bra stavningsprogram och lämna gärna till en kollega som får läsa igenom rapporten.
7. Underlaget till prestandatestrapporten består naturligtvis av dokumenterade resultat med kommentarer.
Kommentar: Kanske helt självklart, men ibland dokumenterar vi inte händelser i rapporten, vi tycker att den händelsen visste ju alla om. Och så kommer det direkt i sammanfattningen utan att vi förklarat att just dessa siffror berodde på …
8. Om du vill berätta att det var mycket omkörningar, berätta inte detta genom att ta med diagram som är oväsentliga för resultaten.
Kommentar: Det är inte ovanligt att man efter ett antal prestandatester av olika anledningar finner att testerna utfördes under felaktiga förutsättningar, ex du var inte ensam i målmiljön. Det enda riktiga är att göra om dessa, ta då inte med resultaten av de felaktiga testerna i rapporten. Nämn detta dock i analysen, och ev. även i sammanfattningen.
9. Förklara innebörden i de begrepp du använder.
Kommentar: Allt sedan prestandatester började bli vanliga för IT-system använder prestandatestare ibland olika namn på samma begrepp. Innan vi inom prestandatestsfären fått en sådan ”begreppskalender”, skriv vad du menar med de olika begreppen, använd med fördel referens till en bilaga av begrepp i din rapport.
10. Blanda inte begreppen, använd samma enheter i rapporten.
Kommentar: Det är lätt hänt att man som prestandatestare blir ”hemmablind” och använder olika namn på samma sak. För den som skall läsa rapporten skapar det onödig förvirring och drar ner betyget.
