Drie soorten self-healing: selector, timing en intent-based

“Self-healing” klinkt als één functie. Het is er drie: selector healing, timing healing en intent-based resolution, met een groot verschil in wat ze daadwerkelijk oplossen.

In de praktijk verbergt de term drie fundamenteel verschillende technieken, en vendoren zijn zelden duidelijk over welke van de drie hun product daadwerkelijk biedt.

Selector healing: de bekendste vorm

Een element-ID verandert van submit-btn naar checkout-submit. Het systeem herkent het element via alternatieve kenmerken (tekstinhoud, positie, omliggende structuur) en werkt de locator automatisch bij. Dit is wat de meeste tools bedoelen wanneer ze "self-healing" claimen, en het is ook de eenvoudigste vorm.

Timing healing: de onderschatte meerderheid

Een test verwacht een bevestigingsbanner na een klik, maar de API-respons duurt 900 ms in plaats van 300 ms. Dat wordt vaak verkeerd toegeschreven aan "een kapotte selector", terwijl het probleem in werkelijkheid bij timing zit. Een goed systeem probeert de oorzaak van de timingfout te begrijpen en past bijvoorbeeld synchronisatie, waits of retries aan op basis van runtime-informatie.

Intent-based resolution: de zwaarste categorie

Bij een volledige redesign verandert niet één element, maar de hele opbouw van een pagina. Intent-based healing probeert te begrijpen wát een teststap probeert te bereiken, bijvoorbeeld "log in met deze gebruiker", en zoekt semantisch naar het juiste element, ook al is de onderliggende structuur volledig anders. Dit is de technisch meest geavanceerde vorm, en ook degene waar de kwaliteit tussen tools het sterkst uiteenloopt.

Self-healing is geen vervanging voor goede testautomatisering. Een test met duidelijke intentie, stabiele locators en correcte synchronisatie blijft de beste bescherming tegen onderhoudskosten. AI werkt vooral als vangnet voor wijzigingen die je niet vooraf kan voorspellen.

Hoe je een tool eerlijk evalueert

• Draai een proof-of-concept op 20 tot 30 van je eigen tests, niet op de demo-applicatie van de vendor.
• Breek ze doelbewust (hernoem klassen, verschuif elementen, vertraag een API-call) en meet welk percentage automatisch herstelt.
• Bekijk wat een herstelde wijziging oplevert. Kan je team ze reviewen, of verdwijnt de wijziging onzichtbaar in een zwarte doos?
• Vergelijk benchmarks nooit rechtstreeks tussen vendoren. Ze worden gemeten op verschillende applicaties, onder verschillende omstandigheden.

De beste aanpak is vaak een combinatie: stabiele, betekenisvolle locators (ARIA-rollen, data-testid) als eerste verdedigingslinie, met AI-gedreven fallback voor wat toch nog verandert.

Een voorbeeld uit de praktijk

Bij de evaluatie van een self-healing-tool voor een klant braken we doelbewust dertig tests op drie manieren: een klasse hernoemen, een element naar een andere plek in de DOM verplaatsen, en een API-call kunstmatig vertragen met 800ms.

De vendor claimde "95% self-healing" op basis van hun eigen demo-applicatie. Op onze eigen suite, met onze eigen mix van breekpunten, kwam de tool voor timing-gerelateerde problemen ruim onder de marketingclaim uit. Die 4 van 30 was precies het type informatie dat de knoop doorhakte: de tool werd gekozen voor selector-healing, aangevuld met eigen explicitewait-logica voor timing.

Hoe we dat soort test in de praktijk opzetten

• Gebruik altijd je eigen suite als testomgeving, nooit de demo-applicatie van de leverancier.
• Breek in verhouding tot wat er in productie ook echt gebeurt. Als jouw team zelden DOM-structuren herstructureert maar vaak klassen hernoemt, weeg dat scenario zwaarder.
• Meet apart per healingtype. Eén totaalscore verbergt precies het verschil dat de aankoopbeslissing zou moeten sturen.