Testen wat niet te testen is

Stel: je hebt in je bedrijf een onderdeel van een applicatie, wat niet getest kan worden. Om wat voor reden dan ook. Zou je er dan tegen zijn als iemand zou zeggen: "Ik ga dit testen"? Nee, niemand zou tegen zijn. Toch is mijn ervaring dat een traject om het niet testbare testbaar te krijgen bijna altijd verloopt van obstakel naar obstakel. Hoe komt dat?

Standaarden

In de IT en in het testvak zijn er veel standaarden, die gebruikt worden om product en proces te verbeteren. Agile, Scrum, Devops, TMap, ISTQB en vul zelf maar verder aan. De ene standaard besteed meer aandacht aan testen dan de anderen. Maar geen enkele besteed aandacht aan het uitbreiden van testdekking. En dat is geen commentaar op de standaarden. Een standaard kan niet alle problemen opvatten en oplossen. Maar het heeft wel een groot nadeel. Het maakt het zo ongeveer officieel dat het testbaar maken van het ontestbare geen onderdeel is van een verbetertraject. En dat maakt het moeilijker een ingang te vinden om dit toch te bereiken.

Normalisering

In veel gevallen is het feit dat iets niet getest wordt al jaren aan de gang. En het is daarmee binnen een bedrijf normaal geworden. Het is een onderdeel geworden van het bedrijfsproces en daarmee van het bedrijf. Een al jarenlang geaccepteerd risico. De nadelen is men al aan gewent en zijn daarmee al van hoog tot laag in het bedrijf geaccepteerd. Daarmee vervalt vaak het belang om het probleem op te lossen. Er is niemand die er nog over klaagt. Zelfs managers niet. Niet testen is in dit geval de norm geworden, de meetlat waarlangs wordt gemeten. Waarmee de reden om te veranderen eigenlijk afwezig is.

Ervaring

Een onderdeel is niet zomaar "ontestbaar" verklaart. Vaak zijn er pogingen gedaan, die mislukt zijn. Mensen hebben er ooit veel tijd in gestoken. Of hebben eens in de zoveel tijd een poging gedaan. Zeggen dat het toch kan veranderen, kan daarmee tegenwerking oproepen. In het beste geval heeft een persoon het gevoel, dat zijn of haar kennis of ervaring in twijfel wordt getrokken. In het slechtste geval wordt het gezien als een directe aanval op iemands  jarenlange werk.

Onbekendheid

Als iets niet getest wordt, maar het is wel mogelijk, is de oplossing vaak onbekend gebied. Het kan een samenwerking zijn tussen personen, die nog nooit hebben samengewerkt. Een tool op een hele andere manier inzetten of zelf een heel nieuw tool invoeren. Of een andere manier van omgaan met testdata. En er zijn nog veel meer mogelijkheden. Maar in mijn ervaring is er altijd een "dat kennen we niet" element. Dit heeft twee nadelen: 

1. Niet iedereen is altijd bereid om iets nieuws te leren
2. Iets nieuws leren of toepassen kost tijd, die je oplossing in eerste instantie vaak duurder maken qua tijd en geld

Gevolg

Officieel zal je bijna nooit te horen krijgen dat je geen poging mag doen om dat wat niet te testen is, toch te testen. Maar er zijn twee zaken, die je in mijn ogen goed moet beseffen

1. Het initiatief op dit traject zal bijna altijd van jou afkomen. Zelfs als mensen niet tegenwerken, zullen ze je vaak niet kunnen geloven (als het kon, was het toch al eerder gelukt?). Of hebben ze gewoon andere prioriteiten (zaken die wel met zekerheid haalbaar zijn).
2. Pas ontzettend op dat je mensen niet tegen je in het harnas jaagt. Je zal je omgeving zeker niet altijd blij maken, omdat je tegen de norm in gaat. Maar probeer te voorkomen dat mensen werkelijk het gevoel hebben dat je hun kennis en ervaring in twijfel trekt.

Waarom toch doen?

Ik heb een hele eenvoudige mening: alles kan getest worden. De vraag is niet: kan je het testen, maar: wegen de testkosten op tegen de baten. Als men werkelijk geloofd dat iets niet getest kan worden, heeft men iets over het hoofd gezien.

Daarnaast, en waarschijnlijk belangrijker voor het overtuigen: hoewel vaak geaccepteerd, zijn de gevolgen vaak wel degelijk ernstig. Ontevreden klanten, terugdraaien van opleveringen in productie, teams die steeds opnieuw onderbroken worden door blocking bugs, slechte relatie tussen development en een of meer afdelingen. Regelmatig ontstaat er zelfs een neerwaartse spiraal: het oplossen van een bug in het niet testbare ondereel veroorzaakt al vrij snel 1 of meer nieuwe.

Als een probleem een van deze gevolgen heeft (en vaak is dat wel degelijk bekend), is het vaak de investering waard om op te lossen. Het is geen makkelijk traject, geen snel traject. En je moet maar net de juiste persoon zijn of vinden om dit onderdeel testbaar te maken. Maar als het lukt, zijn de voordelen ook vrij snel zichtbaar. Juist omdat de negatieve gevolgen dat ook waren. Als men al jarenlang iets slechts gewent is, valt het echt wel op als dat opeens verdwijnt. En dat kan een volgend traject "Testen wat niet te testen is" een stuk eenvoudiger maken.