Testing in de praktijk

een vak apart

Geschreven door: op

Testen is een cruciaal onderdeel binnen de ontwikkeling van software. Naast alle technische mogelijkheden is het ook goed om eens praktisch naar dit onderdeel te kijken. Waar liggen hier de uitdagingen?

De programmeur

Tijdens het ontwikkelen van de software zal de programmeur uiteraard zijn eigen code testen. Verwacht hier echter niet te veel van, want hij kijkt vooral of er geen foutmelding naar voren komt en of alles werkt. Dat betekent dan nog niet dat het werkt zoals het zou moeten werken, laat staan dat dit met andere onderdelen naadloos kan samenwerken.

Iedere programmeur is anders en zal anders testen. Daar moet je van tevoren rekening mee houden in het proces, want dit is een karaktereigenschap die lastig te trainen valt. Wat je wel kunt doen is bepaalde technieken toepassen die automatische tests uitvoeren zoals unit testing. Hiermee worden er bepaalde processen afgelopen en indien het resultaat anders is dan verwacht zal er een foutmelding terugkomen. Zie dit als een stok achter de deur, maar niet als de heilige graal.

Na het opleveren van de code zal dit worden gereleased naar een testserver. Hier staat alle bestaande software met nieuwe onderdelen klaar. De klus is af, toch? Voor de projectleider begint het hier pas, want je hebt enkel gemaakt wat van je verwacht werd. Uiteraard moet de opgeleverde functionaliteit goed zijn, maar alles wat minder is dan de verwachting zal voor de klant als een teleurstelling voelen.

De projectleider

De projectleider is verantwoordelijk voor de kwaliteit en deadlines binnen het project. Binnen een groot project en grote organisaties zullen use cases ontwikkeld worden welke door een apart team worden doorgelopen en afgetest. Binnen een kleinere organisatie heb je deze luxe en overhead simpelweg niet. Niet alleen zal de projectleider tijdens het ontwikkeltraject betrokken moeten zijn bij het proces, binnen een team zal hij ook vaak de aangewezen persoon zijn om de opgeleverde functionaliteit te checken.

Het testen van de projectleider bevindt zich op een heel ander niveau dan de programmeur. Bij een ervaren ontwikkelaar mag je ervan uitgaan dat je geen foutmeldingen naar voren krijgt. Hier ligt de focus dus voornamelijk op de functionaliteit; is hetgeen wat is opgeleverd gelijk aan de verwachting van de klant? Het kan namelijk zijn dat de programmeur een andere interpretatie heeft dan de klant. Dit is een belangrijk onderdeel van de projectleider om duidelijk te krijgen voordat de software richting de klant gaat. Waar nodig kunnen er hier nog kleine aanpassingen gemaakt voordat de klant met de software geconfronteerd wordt.

In het ergste geval zullen onderdelen gedeeltelijk herbouwd moeten worden. Hier komt dan nadrukkelijk het spanningsveld tussen afspraak en kwaliteit naar voren. Stellen we de klant teleur door de deadline naar achteren te schuiven of zorgen we eerst voor een goed doorgeteste release? Soms is naar achteren schuiven zelfs geen optie en heb je echt een probleem. Bespreek dit dan met de klant, want anders ben je altijd de verliezer.

De klant

Ongetwijfeld heeft iedereen verhalen over lastige klanten. Klanten die niet lezen en klanten die zelf niets testen. Vanuit het 'klant is koning' principe verwachten ze ook niet dat ze hoeven te testen, daar betalen ze toch voor? Toch blijft het een feit dat niemand het gebruik van de software beter kent dan de klant zelf. Daarvoor is de acceptatie release, zodat de klant kan aangeven dat de software voldoet aan de eisen en de opgeleverde versie naar live kan. Een gemiste kans als de klant zelf dit niet beseft.

Ondanks de bovenstaande conclusie kan en mag je er niet vanuit gaan dat de klant verantwoordelijkheid neemt voor de release. Bij de overheid kom je er misschien nog mee weg dat een project fout is gegaan door de klant zelf, maar een ondernemer zal je hier snel op afrekenen. Hij voelt iedere fout direct in zijn eigen portemonnee.

De kwaliteit loopt een deuk op als één van de betrokken partijen niet al zijn taken uitvoert binnen het gehele proces. Uiteraard zijn hierbij de programmeur en projectleider verantwoordelijk en zouden ze altijd een goed product op moeten leveren. Het is echter enorm belangrijk dat de klant zijn rol binnen dit proces kent. Je kunt simpelweg zeggen dat een deadline gehaald moet worden, maar wellicht gaat dit ten koste van de kwaliteit. Wil je echt garantie op problemen, kom dan met wensen op het laatste moment. Dit gaat ten koste van de kwaliteit én het testen.

De conclusie

Er zijn vele boeken geschreven over het testen van software. De theorie is mooi, maar de praktijk blijkt - zeker binnen een kleinere organisatie - een stuk lastiger. Testen zit tussen het spanningsveld van de bedrijfsprocessen van de leverancier en de deadlines en het budget van de klant. Loopt het project uit, dan komt het testen onder druk. Dan is het lastig om je geduld te bewaren en dit alsnog met volle focus af te ronden en desnoods de klant later zijn release te geven.

Een van de meest voorkomende reden om van leverancier over te stappen is een gevolg van het falen van het testproces. De fouten komen dan naar voren in de acceptatierelease of, nog erger, op de live omgeving. Dan verdwijnt langzaam het vertrouwen in zowel de software als de organisatie. Je moet dan wel hele mooie software bouwen of goede klantrelatie hebben om dan leverancier te blijven.

Testen definieert uiteindelijk de klantperceptie over de kwaliteit van je product en je bedrijf. Besteed daarom veel tijd in het optimaliseren van dit proces en zorg dat de klant begrijpt waar je mee bezig bent. Misschien is dit blog een mooie eerste stap in dit proces...

Testing in de praktijk Aantal keer bekeken: 3.884