Testen enkel tot het einde van het project uitstellen, kan ertoe leiden dat problemen pas aan het licht komen in een fase waarin alles al met elkaar verweven is. Een nuttigere aanpak is om het verwachte gedrag vooraf te bespreken en afgeronde onderdelen doorlopend te controleren. Zo wordt de opleverdag niet de eerste dag waarop alles echt wordt uitgeprobeerd.
01Maak het verwachte gedrag gezamenlijk expliciet
De zin "er komt een rapportscherm" kan voor iedereen iets anders betekenen. Welke periode wordt gebruikt, hoe ziet een leeg resultaat eruit, wie mag het rapport exporteren? Wanneer de antwoorden op deze vragen worden omgezet in testscenario's, kunnen ontwikkelaar, ontwerper en klant hetzelfde resultaat beoordelen. Vroege duidelijkheid helpt om later herhaald werk te verminderen.
02Test ook de mislukte flows
Een gebruiker kan verkeerde gegevens invoeren, zijn sessie kan verlopen, of hij kan nogmaals op opslaan drukken. Het testplan mag zich niet beperken tot iemand die de juiste stappen volgt; het moet ook deze situaties omvatten. Blijft ingevoerde informatie behouden, is de foutmelding begrijpelijk, ontstaat een handeling niet per ongeluk dubbel? De betrouwbaarheid van een product wordt zichtbaar in precies dit soort kleine momenten.
03Controleer de overgangen tussen teams
Wanneer verschillende ontwikkelaars parallel aan hetzelfde project werken, volstaat het niet dat elke module op zich werkt. Ook de informatie, gebruikersrol en dataindeling die van het ene scherm naar het andere worden doorgegeven, moeten consistent zijn. Het brede ontwikkelteam en het professionele testteam van Paradigma7 behandelen deze overgangen als onderdeel van het opleverplan. Onze manier van parallel werken hebben we beschreven in ons artikel over een wereldwijd team. Snelheid wordt niet gewonnen door controlestappen weg te laten.
04Presenteer het opleverbewijs begrijpelijk
Een testresultaat mag niet enkel bestaan uit het woord "geslaagd". Vastgelegd moet worden welk scenario in welke versie is getest, wat de impact is van een eventueel openstaand probleem, en wat het resultaat van een hertest was. Zo kan de klant zien welke scope daadwerkelijk is afgerond. Testen verminderen risico's; ze bieden echter geen garantie dat er nooit een fout zal optreden, maar wel zichtbare kwaliteit en een traceerbaar proces. De plaats van testbewijs in het opleverpakket hebben we beschreven in ons artikel over sleutelklare software. Bij onze maatwerksoftware-ontwikkeling is testen op deze manier in elke fase aanwezig.
05Korte checklist
- Is voor elke belangrijke taak het verwachte gedrag omgezet in een geschreven scenario?
- Zijn mislukte flows getest, zoals foutieve invoer, een verlopen sessie en dubbelklikken?
- Zijn data-overdracht en rolrechten tussen modules samen getest?
- Zijn de testresultaten vastgelegd samen met het versienummer?
- Is de impact van openstaande problemen aan de klant uitgelegd?
Geschreven door
Het Paradigma7-team
Product, engineering en operations
We zijn een op Ankara gebaseerd team dat software voor Europa bouwt. Niets hier is theorie: dit zijn de processen die we werkelijk op klantprojecten uitvoeren.
Over ons