Onderhoudbaarheid software in de teststrategie

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 IfSQhet 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.

Ook interessant?

Soorten onderhoud van software

De 4 soorten onderhoud van software

Onderhoud is het wijzigen of aanvullen van een bestaand informatiesysteem en kan ad-hoc of planmatig worden uitgevoerd. Ad-hoc onderhoud vindt ...
Meer Lezen
De scope van testen in onderhouden

De scope van software testen in onderhoud

Wanneer software is aangepast moet er vastgesteld worden wat er getest moet worden en met welke diepgang. Er zijn verschillende ...
Meer Lezen
"Meet met Greet" met Graham Bolton

“Meet met Greet” met Graham Bolton

In deze "Meet met Greet" praat ik met Graham Bolton. Graham is software quality expert en performance specialist. Hij is ...
Meer Lezen
Onderhoud software

Beoordelen onderhoudbaarheid van software

Uit een productrisico analyse (PRA) kan naar voren komen dat het beoordelen van de onderhoudbaarheid van de software moet worden ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!