We just need your compliance

Ik ben een Muse fan en bij het horen van dit nummer van hun laatste album moest ik meteen denken aan datgene wat ik vaak ben tegengekomen in IT-projecten en teams:

De innige wens om te voldoen aan dat wat wordt gevraagd

En soms lijkt dat helemaal logisch: zo zijn er vaak tal van hard-gestelde kaders die door in- of externe instanties worden gesteld aan softwareontwikkeling. Denk daarbij aan:

• ISO standaarden zoals de ISO 9000 serie of ISO 9126
• Security richtlijnen en eisen
• Eisen gesteld vanuit b.v. De Nederlandse Bank
• Eisen gesteld vanuit de eigen interne audit of risk afdeling

Ik begrijp dat er bepaalde eisen zijn aan, bijvoorbeeld gegevensbescherming en beveiliging, en dat er controle moet zijn op mogelijke fraude. Er moet dus voldaan worden aan die richtlijnen en ook gecontroleerd worden of er daadwerkelijk aan is voldaan. En dit moet ook aantoonbaar zijn.

Toch zie ik veel discussie ontstaan over ‘hoe’ we omgaan met de compliance regels. Maar al te vaak is er, meestal door een interne audit afdeling met ongetwijfeld goede bedoelingen, een ridicule compliance kerstboom opgetuigd waarin precies is beschreven hoe een team of teamlid zijn werk dient te doen in deze. Voorbeelden:

• Gij zult een Master Testplan schrijven conform sjabloon X
• Gij zult elke testcase vastleggen in Jira
• Voor iedere user story moet er tenminste 1 testcase zijn
• Gij zult tool X gebruiken voor testsoort Y
• Er moeten tenminste 3 testomgevingen zijn (OTA)
• Een ontwikkelaar heeft geen toegang tot de A omgeving
• Een tester heeft geen toegang tot de O omgeving
• Software die van T naar A gaat moet eerst een akkoord hebben van manager Y
• Van elke test moet een bewijs worden geleverd middels een screenshot

De vraag is of al deze vaak zelfopgelegde ‘dwangbuisregels’ daadwerkelijk iets toevoegen. Ze zijn namelijk geen één-op-één vertaling van de echte compliance-eisen, maar een suboptimale, beperkende vertaling door een interne risk- of auditafdeling.

Moet je als team of teamlid hier dan in meegaan? Nee! Ga de discussie aan waarbij meestal bijvoorbeeld een vraag als: ‘Kun je me uitleggen hoe deze interne regel zich verhoudt tot de compliance eisen vanuit De Nederlandse Bank?’ al voldoende is om de interne regel op losse schroeven te zetten. Als voorbeeld: De Nederlandse Bank eist helemaal niet dat je alle testcases in Jira moet vastleggen (met een screenshot). Zij eisen wel dat er moet worden aangetoond wat er is getest, waarom, wanneer, door wie en met welk resultaat. Goede testers leggen deze informatie ook vast omdat ze de waarde er van inzien, niet alleen uit compliance overwegingen, maar ook voor zichzelf.

Een andere manier is meer ludiek en heb ik meermaals met succes gebruikt: neem je testen op via een video-capturing tool en geef deze 16Gb per dag aan de auditor met de melding: ‘hierbij precies de bewijsvoering van alle testen van vandaag. Morgen einde dag zal ik die van morgen geven’.  In mijn ervaring waren 2 dagen genoeg om deze eis van tafel te krijgen.

Ergo: laat je professionaliteit leidend zijn. Jij weet wat je doet, waarom je zaken doet, hoe je dat het beste kan doen en hoe je de zaken hoort te documenteren om te voldoen aan de echte compliance eisen. Laat je niet in de hoek zetten door onzinnige, overbodige en nutteloze extra documentatie en werkzaamheden. Die tijd kun je ook besteden aan meer testen. Hiermee help je niet alleen jezelf, maar ook je team en kun je beter en sneller kwalitatief hoogwaardige software opleveren aan je klanten.

‘Leadership’ is onderdeel van de training Agile-United Certified Specialist in Agile Testing. Wil je hier als software tester meer over weten of beter in worden, kijk dan op onze site.

Naar het overzicht