Fragment

1 Het testbeleid
1.1 In het kort
Elke organisatie heeft een eigen kijk op kwaliteit. Vaak wordt deze kijk beïnvloed door cultuur, specifieke normen en richtlijnen. In de context van softwareontwikkeling wordt er gekeken naar de mate waarin het softwareproduct of dienst voldoet aan de specificaties, verwachtingen en behoeften van de opdrachtgever en gebruikers. Het gaat dan niet alleen om de afwezigheid van fouten, maar ook of er wordt voldaan aan bepaalde standaarden, waardevolle criteria en normen. In de regel ligt de focus vaak op het voldoen aan de verwachtingen van de opdrachtgever en gebruikers. Maar het is ook zeker van belang dat er rekening wordt gehouden met de behoeften en verwachtingen van de leverancier, om zo een succesvolle en duurzame samenwerking te garanderen.

Om een beter begrip te krijgen van elkaars verwachtingen en eisen, kan een testbeleid als stevige basis dienen. In het test-beleid staat op hoofdlijnen beschreven hoe de opdrachtgever en leverancier zich bezighouden met mensen, middelen en processen ten aanzien van het testen in diverse situaties. Het beleid geeft vorm en inhoud aan de belangrijkste doelstellingen, namelijk het creëren van een gedeeld begrip over de testfilosofie, richting en kaders in de algemene projectaanpak. Het testbeleid geeft als het ware een overkoepelend kader voor hoe testen bij projecten en in een samenwerking wordt geïmplementeerd. Het is van belang dat het testbeleid wordt gevolgd bij het plannen, uitvoeren en beheren van testactiviteiten binnen een samenwerking. Het zorgt namelijk voor consistentie en uniformiteit, zodat iedereen dezelfde benadering volgt. Organisaties kunnen veel effectiever omgaan met risico’s en beter prioriteit geven aan het testen van de belangrijkste functies en scenario's. Het testbeleid bevordert transparantie en het nemen van verantwoordelijkheid. Het is daarmee een integraal onderdeel van de kwaliteitsborging - ook wel quality assurance genoemd - en risicobeheer in het software-ontwikkelingsproces. Bij een goede implementatie zal het testbeleid enorm bijdragen aan kostenbeheersing, door efficiënter gebruik te maken van middelen en vroegtijdige foutdetectie.

1.2 Tot een testbeleid komen
Om tot een solide testbeleid te komen zijn er twee benaderingen te volgen, namelijk top-down en bottom-up. In de top-down benadering worden op strategisch niveau kwaliteitseisen vastgesteld voor processen, diensten en producten. Bij de bottom-up benadering ontstaat er onder medewerkers juist de behoefte aan een toetsingskader, een soort van kapstok om de processen en structuren te waarborgen. Beide benaderingen dienen als voeding voor het komen tot een testbeleid. Bij relevante belanghebbenden, zoals opdrachtgevers, managers en software developers wordt informatie en feedback verzameld, om ervoor te zorgen dat het testbeleid aansluit bij de behoeften van alle betrokkenen. Daarnaast is het van belang om een goed begrip te krijgen van de eigen bredere organisatiedoelen. Dit kan door te identificeren hoe kwaliteit en testen hierin passen.

Het opstellen van een testbeleid is een proces dat zorgvuldige overweging en afstemming vereist. Het is van belang om het testbeleid regelmatig te evalueren en bij te werken. Zo blijf je als organisatie relevant en kun je flexibel inspelen op veranderingen in klantwensen en de complexe wereld van softwareontwikkeling. Een omgeving met een flexibele aanpak is per definitie risicogebaseerd. Een logisch gevolg hiervan is dat ook het testen afgestemd is op risico’s. Door gedurende het ontwikkeltraject diverse risicogebaseerde tests toe te passen, kunnen onderkende project- en productrisico’s in een vroeg stadium worden afgedekt. Dit draagt enorm bij aan de foutreductie. Het integreren van de volgende richtlijnen in het testbeleid kan helpen bij het creëren van een gestructureerde aanpak voor het testen van software. Tevens bevordert het een cultuur van kwaliteit en samenwerking binnen de organisatie.

• Testvormen specificeren in de specifieke ontwikkelingsfasen;
• Prioritering van testvormen aangeven op basis van het eerder bepaalde gewicht, de risico’s en complexiteit van de software;
• Frequentie van testuitvoering aangeven per testvorm;
• Gebruik van tools en technologieën specificeren bij uitvoering van bepaalde testvormen;
• Rapportage en documentatievereisten specificeren, inclusief welke informatie en aan wie moet worden gerapporteerd;
• Aangeven van samenwerkings- en communicatierichtlijnen, inclusief kennisdeling;
• Onderhoud van testscripts beschrijven qua update frequentie om relevant te blijven;
• Validatie van testresultaten specificeren zodat eventuele bevindingen correct worden geïdentificeerd in een vroeg stadium;
• Inzet van testomgevingen specificeren voor het opzetten en beheer ervan;
• Compliance en regulering borgen, zoals AVG of ISO-standaarden.

Het kan zijn dat sommige van deze richtlijnen je nu nog onbekend voorkomen, of dat je niet precies weet hoe je ze moet toepassen. De volgende hoofdstukken van dit boek zullen je hierin verder begeleiden. ×