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.

Simuleren tijdens testen: het kan teweinig en het kan teveel zijn

Simulaties, emulaties, stubs en drivers. Binnen de testwereld krijgen ze een steeds grotere rol. Ze vormen een groep krachtige tools binnen het testen, met een zeer waardevolle toevoeging. En tegelijkertijd vormen ze een heel, heel groot gevaar.

Voor deze blog gebruik ik het woord 'simuleren' of 'simulatie' voor alles waarbij je een applicatie, proces, apparaat, interface, e.d., zoals gebruikt in productie, vervangt door een hulpmiddel. Dit kan een stuk code zijn, maar ook een softwareprogramma, dat als simulatie is ingericht.

Ik hecht een groot belang aan goede simulaties. Simulaties kunnen op verschillende manieren het testen verbeteren. Je kan het mogelijk maken om het onmogelijke te testen. Meestal situaties, die in de praktijk vrijwel onhaalbaar zijn. Zo kan je in het netwerk zaken simuleren, die in het echt moeilijk te vinden zijn. Trage netwerken, haperende netwerken, onderdelen, die uitvallen. Maar denk ook bijvoorbeeld aan GPS testen. Om goed te testen, is een gps coördinaat met een '-' waardevol. Ik denk niet dat veel werkgevers een reis naar het westen of zuiden, om dit te testen, zullen goedkeuren.

Daarnaast is het een krachtig tool om afhankelijkheid van externe leveranciers of beperkte databases op te lossen. Als je zelf kan bepalen welke gegevens je binnenkrijgt, kan je eenvoudig veel meer varianten testen. En testen op meerdere varianten in gegevens geeft vaak een betrouwbaardere test.

Als laatste kan het tijdwinst opleveren. Ik heb zelf testen geschreven, waarbij je langer met de voorbereiding bezig was, dan met de test. Vaak zijn dit tijdgebonden testen, waarbij de gegevens binnen een bepaalde periode moeten vallen. Denk aan een route, die door een monteur gereden moet worden. Hiervoor moeten misschien wel 20 afspraken ingevoerd zijn, om dit goed te kunnen testen. Als je deze invoer snel kan simuleren, in plaats van werkelijk invoeren, heeft dat grote voordelen.

Dus waarom zou je het laten? Nou, volledig laten hoeft wat mij betreft nooit. Dit kan er zelfs toe leiden, vooral als het gaat om testen van situaties of varianten, dat je test niet genoeg dekking heeft om betrouwbaar te zijn.  Het kan echter ook teveel zijn. Als je volledig gaat vertrouwen op simulaties, test je de werkelijkheid niet meer. Want hoe goed een simulatie ook is, er is altijd een kans dat de simulatie verschilt van de werkelijkheid.

Simulaties moet je gebruiken om je test aan te vullen of om een deel van je test te vervangen. Maar als je iets in de werkelijkheid kan testen, doe dat altijd minimaal 1 keer. Ik zie geen enkel bezwaar om, als je 10 testen hebt voor een interface, er 9 te simuleren en 1 echt uit te voeren. Ook kan je ervoor kiezen om een speciale "niet-simulatie" test uit te voeren. Denk hierbij bijvoorbeeld aan een ketentest, waarbij over het algemeen simulatie bewust niet wordt gebruikt.

Aan de andere kant: als je situaties alleen via simulatie kan testen, ontwijk de simulatie niet. Kan je iets niet in de werkelijkheid testen, heb de moed om te kijken of het via simulatie wel kan. Er kan vaak veel meer dan je denkt. Zeker als je zelf kan programmeren of de mogelijkheid hebt een ontwikkellaar in te zetten. Zoek eens op het internet, als je denkt dat iets onmogelijk is. Regelmatig zal je verrast worden, omdat er vaak andere mensen zijn met hetzelfde probleem. En de oplossing daarom allang aangeboden wordt.