Hoe haal je in een testtraject het maximale resultaat uit de beschikbare middelen
Performancetesten is een vak apart. Voor een kersverse projectmanager is dat helaas niet altijd vanzelfsprekend. Vaak wordt te lichtzinnig gedacht over performance en is het de laatste horde die genomen moet worden in een traject. Problemen worden pas laat zichtbaar of er wordt niet adequaat gereageerd. Wat kun je doen om die situatie te verbeteren?
Eigenlijk dient performance gezien te worden als de kers op de taart. Pas als alle onderliggende bouwstenen op hun plaats liggen wordt duidelijk of de software geschikt is voor je gebruikers. Bedenk dat performance niet het resultaat is van een test, maar een eigenschap inherent aan de applicatie zelf. Vraag een willekeurige tester naar verhalen uit de praktijk en hij geeft je legio voorbeelden van situaties waarin te weinig aandacht is geschonken aan performance. Omdat commentaar achteraf niet altijd op prijs wordt gesteld bestaat de kans dat er geen lering wordt getrokken uit missers en dat is natuurlijk helemaal zonde. Vandaar dat ik hier enkele tips en voorbeelden wil geven om het beste te halen uit de beschikbare middelen om daarmee de kans op verrassingen zo klein mogelijk te maken.
Begin met performance in een vroeg stadium
Dit is de spreekwoordelijke open deur voor performancetesters. Wanneer er al tijdens een eerste testrun zulke kritieke fouten optreden dat delen van de applicatie herschreven moeten worden, vragen veel testers zich af waarom deze niet in een eerder stadium zijn gevonden. Op het moment van constateren is dit nooit prettig, maar dit soort situaties kunnen tot op zekere hoogte worden voorkomen door ontwikkelaars meer te betrekken bij het testen. Enkele bekende voorbeelden:
- Capaciteit van aanwezige hardware die onverwacht niet lijkt te voldoen vanwege gebrek aan aandacht voor multi-threading tijdens de ontwikkeling
- Een applicatie die tijdens de eerste minuten van een test bezwijkt wegens verkeerde (fout)afhandeling van service calls
- Klantgegevens die verwisseld worden door gebruik van non thread-safe functies (!)
Meestal blijkt achteraf dat de foutsituatie prima nagespeeld kan worden bij lage belasting in een ontwikkel-omgeving en geld bespaard had kunnen worden. Stimuleer ontwikkelaars daarom altijd om een bijdrage te leveren aan het testtraject en mee te denken over performance.
Zorg voor goede documentatie
Hoewel documentatie sinds de introductie van Agile software development een wat nare bijsmaak heeft gekregen, denk ik dat het besparen op een testplan een verkeerde bezuiniging is. Door vooraf meer tijd te besteden aan de teststrategie kunnen vervelende situaties verderop in het traject namelijk voorkomen worden. Vraag je testers om hun plan te verdedigen voor de teams om blinde vlekken en gaten in kennis weg te nemen. Sommige kennis is namelijk verspreid over de organisatie maar kan het verschil maken tussen een geslaagde of waardeloze test. Een goede tester komt hier zelf mee, maar denk bijvoorbeeld aan:
- beperkingen in test- of acceptatieomgevingen ten opzichte van productie en hoe hiermee om te gaan
- gewenste ondersteuning tijdens tests en de noodzaak deze vooraf aan te vragen
- gedeelde infrastructurele componenten en de invloed hiervan op testscenario’s
Het ontbreken of over het hoofd zien van een essentieel onderdeel in de teststrategie kan zomaar op enkele weken vertraging komen te staan. Een dure les dus.
Stel verzamelen van testdata niet uit
Als de teststrategie bekend is volgt daaruit de soort en hoeveelheid benodigde testdata. Stel het verzamelen hiervan (en dus ook het opstellen van de teststrategie) niet uit tot na de ontwikkeling. Dit hoeft niet alleen een verantwoordelijkheid te zijn van de tester, want die wordt soms pas in een laat stadium betrokken.
Over testdata zijn boeken volgeschreven, maar als het gaat om performancetesten komen de volgende ‘adders’ vaak voor. Meestal is het een direct gevolg van de grote hoeveelheid data die nodig is. Onderstaande situaties zijn in 9 van de 10 gevallen te vermijden door eerder aandacht te schenken aan testdata.
- Er is te weinig testdata aanwezig of bestaande data is verlopen
- De testdata is niet binnen afzienbare tijd op te leveren vanwege gebrek aan automatisering
- Er moet data worden gekoppeld uit verschillende bronnen wat vertraging oplevert
Communiceer meer en beter tijdens testuitvoer
Het trekken van onjuiste conclusies of het invalideren van een test is zo gebeurd. Bijvoorbeeld doordat twee teams elkaar in de wielen rijden omdat ze op hetzelfde moment actief zijn op een testomgeving en een gedeelde component overbelasten. Of wat te denken van het verwijderen van elkaars testdata? Dit lijken voor de hand liggende zaken, maar komen in grotere organisaties helaas vaak genoeg voor. Ook de oplossing is voor de hand liggend, maar wordt niet altijd geïmplementeerd omdat het belang hiervan niet wordt onderkend. Weet van elkaar wie, wat en wanneer test en maak hier duidelijke afspraken over. Stel indien dit nog niet het geval is een sleutelfiguur aan binnen je organisatie met kennis van de omgeving die de algehele testcoördinatie op zich neemt en zicht houdt op de verschillende teams én de gedeelde componenten. Daarmee voorkom je een hoop ongelukken.
Tot zover mijn opgeheven vingertje. Neem deze tips ter harte en zorg dat je nooit meer voor verrassingen komt te staan. Of toch …?
- Vincent van Hijkoop