Zelfherstellende testautomatisering

Zelfherstellende testautomatisering is een functie die een test automatisch repareert wanneer het element waarnaar hij verwees verandert. Een knop krijgt een nieuwe CSS-klasse, een formulierveld wordt hernoemd, een container wordt anders opgebouwd — in plaats van te falen zoekt de tool het element dat de stap waarschijnlijk bedoelde, werkt de locator bij en gaat verder.

Het bestaat vanwege een ongemakkelijk feit over traditionele testsuites: de meeste mislukkingen zijn geen bugs. Het is de suite die reageert op een verandering in de markup die niets zegt over de vraag of de software werkt.

Waarom tests überhaupt breken

Een conventionele geautomatiseerde test richt zich op elementen via een selector: een CSS-pad, een ID, een XPath-expressie. Die selector is een uitspraak over hoe de pagina is gebouwd, niet over wat die doet.

Front-end-frameworks genereren klassennamen. Ontwerpers bouwen layouts om. Iemand zet een knop in een nieuwe div. Niets daarvan verandert of een klant een aankoop kan afronden, maar het breekt allemaal een selector. Het resultaat is een suite die voortdurend faalt om redenen waar niemand om geeft, wat het team leert rode builds te negeren — de duurste uitkomst die er in testen bestaat.

Hoe zelfherstel werkt

De implementaties verschillen, maar de aanpak is in grote lijnen steeds dezelfde:

• Meer dan één signaal vastleggen. Wanneer een stap wordt aangemaakt, slaat de tool meerdere eigenschappen van het doelelement op — tekst, positie, ARIA-rol, labels in de buurt, plek in de DOM — in plaats van één selector.
• Kandidaten scoren bij een mislukking. Wanneer de primaire selector niets vindt, worden kandidaat-elementen op de nieuwe pagina gescoord tegen de opgeslagen signalen.
• De beste match kiezen en doorgaan. Als het vertrouwen hoog genoeg is, loopt de run door en wordt de locator bijgewerkt.
• Rapporteren wat er hersteld is. Goede implementaties vertellen het je. Dat telt zwaarder dan het herstellen zelf.

Het faalgedrag dat niemand adverteert

Dit is het deel dat leveranciersmateriaal doorgaans weglaat, en het is het belangrijkste op deze pagina.

Zelfherstel kan een cosmetische wijziging niet onderscheiden van een regressie.

Het weet dat het gewenste element er niet is, en het vindt het dichtstbijzijnde dat er wél is. Het kan niet weten of de knop is verplaatst omdat een ontwerper de layout opruimde, of omdat iemand het verkeerde component heeft uitgeleverd. In het tweede geval neemt het herstel een test die had moeten falen en laat hem slagen.

Een onterecht geslaagde test is aanzienlijk erger dan een onterecht gefaalde. Een mislukking wordt onderzocht; een geslaagde test wordt vertrouwd.

De praktische verdediging is om herstel te behandelen als een melding en niet als een oplossing. Bekijk wat er is hersteld, minstens wekelijks. Als je tool stilletjes herstelt en je geen logboek toont, is dat een reden om naar een andere tool te kijken.

Waarom testen op basis van beschrijvingen het minder nodig heeft

Zelfherstel is een reparatie voor een probleem dat ontstaat door tests aan markup te binden. Tools die werken vanuit een beschrijving in gewone taal zitten om te beginnen niet aan markup vast.

‘Controleer of de bestelling in het besteloverzicht staat’ bevat geen selector. Er is niets om te breken en dus niets om te herstellen — de AI interpreteert die bedoeling tegen hoe de pagina er vandaag uitziet. Een herontwerp dat een selector-gebaseerde suite zou verwoesten is voor een beschreven test gewoon een andere pagina om te lezen.

Dat is geen claim van superioriteit in alle richtingen. Locator-gebaseerde tools met zelfherstel zijn deterministischer: ze doen elke run hetzelfde, en als ze hun gedrag veranderen, laten ze het weten. Beschreven tests beslissen elke keer opnieuw. De afweging is herhaalbaarheid tegenover veerkracht, en wat je wilt hangt ervan af of je interface stabiel is.

Voor de concrete versie van deze vergelijking, zie Testmode versus Testim — Testims op ML gebaseerde slimme locators zijn de bekendste implementatie van de zelfherstel-aanpak.

Vragen die je een leverancier moet stellen

• Welk deel van de runs bevat een herstel, bij de suite van een typische klant?
• Kan ik per run een logboek zien van alles wat er hersteld is?
• Kan herstel worden ingesteld om te waarschuwen in plaats van automatisch door te gaan?
• Wat gebeurt er als het vertrouwen laag is — faalt het, of gokt het?
• Blijft een herstelde locator bestaan, of wordt hij elke run opnieuw beoordeeld?

De antwoorden scheiden serieuze implementaties van een vinkje op een functievergelijking.

Waar je verder kunt lezen

Tools met volwassen zelfherstel: Testim, Autify, mabl, Katalon, Functionize, Testsigma, Virtuoso QA.

Voor het onderliggende alternatief — tests die zich nooit aan de markup binden — zie testautomatisering in gewone taal, en het overzicht van AI-testtools voor het hele veld.