In dit artikel gaan we in op de wijze waarop het beoordelen van de onderhoudbaarheid van software kan worden opgenomen in een teststrategie. Uitgangspunt hierbij is het gebruiken van de IfSQ standaard. Lees voor meer achtergrondinformatie eerst ons artikel over “beoordelen onderhoudbaarheid software”.

Het beoordelen van de onderhoudbaarheid op basis van de IfSQ standaard kan op verschillende manieren en momenten in het ontwikkeltraject plaatsvinden:

• Statisch analyse
  Door het uitvoeren van een geautomatiseerde statische analyse op de source code of broncode. Hierbij wordt de software niet uitgevoerd. Er zijn diverse tools beschikbaar die door ontwikkelaars gebruikt kunnen worden voor het uitvoeren van een statische analyse.
• Code reviews
  Code review is het toetsen van geschreven software. Het toetsen van deze software gebeurt door ontwikkelaars (en liefst samen met testers) die elkaars programmeercode lezen en beoordelen.
  
• Code inspectie
  Het door een externe partij laten beoordelen van de source code op basis van de IfSQ level-2 standaard.

Wanneer je de hiervoor genoemde mogelijkheden kunt inzetten is afhankelijk van de volgende situaties:

1. Ontwikkeltesten vallen binnen de scope van de teststrategie
2. Ontwikkeltesten vallen niet binnen de scope en de source code is niet beschikbaar
3. Ontwikkeltesten vallen niet binnen de scope, maar de source code is wel beschikbaar

Ontwikkeltesten vallen binnen de scope van de teststrategie

In deze situatie kun je zowel statische analyse als code reviews gebruiken. Het is hierbij zaak dat er samen met de ontwikkelaars wordt gekeken naar welke analysetool het beste te gebruiken is. Vervolgens moet er worden vastgesteld welke defect indicatoren met de tool kunnen worden gecontroleerd. De overblijvende defect indicatoren kunnen dan meegenomen worden als onderdeel van de code review.

Tip!
Zorg ervoor dat testers betrokken worden bij het uitvoeren van code reviews. Testers hebben altijd een andere invalshoek en daarnaast geeft het ze inzicht in hoe er is gebouwd. Deze informatie kunnen ze vervolgens gebruiken bij het opstellen van testgevallen.

Ontwikkeltesten vallen niet binnen de scope en de source code is niet beschikbaar

In deze situatie is het verstandig om in gesprek te gaan met de opdrachtgever. De resultaten van de productrisico analyse (PRA) geven namelijk aan dat onderhoudbaarheid belangrijk wordt gevonden.

Er kunnen zich nu 3 situaties voordoen:

• Er is contractueel met de leverancier afgesproken dat zij de onderhoudbaarheid van de ontwikkelde software moeten aantonen en hierover moeten rapporteren. Je kunt in de teststrategie dan opnemen dat deze rapportage (en de gehanteerde werkwijze) wordt getoetst aan IfSQ level-2
• Er is contractueel niets afgesproken. De opdrachtgever moet dan alsnog zorgen dat de leverancier de onderhoudbaarheid gaat aantonen of dat alsnog de source code tijdig beschikbaar komt voor beoordeling door het testteam.
• In overleg met de opdrachtgever kan besloten worden dat onderhoudbaarheid niet zal worden meegenomen omdat het niet mogelijk is om de source code beschikbaar te krijgen. Er blijft dan natuurlijk wel een risico bestaan. Hierover moet nadrukkelijk worden gerapporteerd in de eindrapportage van het testen.

Ontwikkeltesten vallen niet binnen de scope, maar de source code is wel beschikbaar

Dit wordt al iets lastiger. Uiteraard kun je ook hier een statische analyse tool en reviews gebruiken. Voorwaarde is daarbij wel dat testers in het team een statische analyse tool moeten kunnen inrichten en gebruiken. En wanneer je wilt beoordelen op basis van IfSQ Level-2 moeten de testers ook beschikken over programmeer kennis en ervaring.

Een andere mogelijkheid is om het beoordelen uit te besteden aan een externe partij die gespecialiseerd is in het beoordelen van software code op basis van de IfSQ standaarden.