RPA inzetten voor softwaretesten: Een strategische aanpak

Ineffectieve softwaretestautomatisering is berucht om releases te vertragen terwijl ongelooflijke hoeveelheden bronnen worden geconsumeerd.

Elke zo vaak bevat mijn nieuwsfeed een artikel dat "De Top 10 Life Hacks" aanbiedt. Dit zijn tips en trucs over hoe gewone huishoudproducten op onverwachte manieren te gebruiken om je leven te verbeteren – "...en tip nummer 7 zal je verblinden!!!"

Eerlijk gezegd, ik ben erin getrap. Eerlijk gezegd, zijn er momenten dat ik aangenaam verrast ben. Bijvoorbeeld, wie wist dat je door vervelende plastic blisterverpakkingen kunt snijden met een blikopener, of een toiletpapierrol kunt gebruiken om verpakkingspapier te voorkomen van uitlepen?

Ik probeerde de twee "hacks" hierboven en raad wat? Ze "soort van" werkten... voor een tijdje. De blikopener sneed door de naad waar het plastic gesmolten was, maar faalde om door de lengte van de verpakking te snijden. De toiletpapierrol hield het verpakkingspapier een tijdje, maar uiteindelijk verzwakte het karton en ravelde het verpakkingspapier uit. Niet verrassend, schaar gebruiken voor de plastic blisterverpakkingen en een klein stukje tape voor het verpakkingspapier werkte veel, veel beter.

In een zeer gelijkaardige veen, overwegen veel organisaties nu RPA te gebruiken voor het automatiseren van softwaretesten: een "tech hack" voor softwaretesten, van een soort. Echter, net als de toiletpapierrol geen duurzame oplossing bood voor het voorkomen dat mijn verpakkingspapier uitliep, is RPA geen duurzame oplossing voor softwaretestautomatisering... en de wijzigingen die vereist zijn om de RPA-tool duurzaam te maken voor de taak van softwaretestautomatisering zouden, nou ja, een hack zijn.

Als je al een RPA-tool in je organisatie hebt en je kijkt om te beginnen met testautomatisering, kan je RPA-tool een logische keuze lijken. Het is meestal relatief makkelijk om een aantal fundamentele testscenario's te automatiseren (bijv. een nieuwe gebruiker aanmaken en een transactie voltooien), validatie toevoegen, en geloven dat je op de weg bent naar testautomatisering.

Echter, het is belangrijk te erkennen dat succesvolle – en duurzame – testautomatisering veel meer vereist dan de capaciteit om door applicatiepaden te klikken. Om boven het teleurstellende gemiddelde van de industrie voor testautomatisering van <20% te stijgen, moeten teams ook in staat zijn een effectieve geautomatiseerde testsuite te construeren en te stabiliseren. RPA-tools zijn meestal niet ontworpen om dit mogelijk te maken. Als resultaat zul je testautomatisering-roadblocks tegenkomen zoals vertraging wachten op de vereiste testdata en testomgevingen, inconsistentie resultaten die vertrouwen in de automatiseringsinitiatief ondermijnen, en "opgeblazen" testsuites die aanzienlijke bronnen consumeren maar geen duidelijke, actionable feedback leveren.

Voor een snel overzicht van het verschil in scope tussen RPA-tools en testautomatisering-tools, vergelijk de volgende definities van Gartner:

RPA-tools "voeren 'if, then, else' statements uit op gestructureerde data, typisch gebruikmakend van een combinatie van user interface (UI) interacties, of door te verbinden met API's om client servers, mainframes of HTML-code aan te sturen. Een RPA-tool werkt door een proces in de RPA-tooltaal af te beelden voor de software 'robot' om te volgen, met runtime toegewezen om het script uit te voeren door een control dashboard."

Testautomatisering-tools "staan een organisatie toe om geautomatiseerde functionele tests te ontwerpen, ontwikkelen, onderhouden, managen, uitvoeren en analyseren... Ze bieden breedte en diepgang van producten en features over de software development life cycle (SDLC). Dit omvat testontwerp en -ontwikkeling; testcase-onderhoud en hergebruik; en testmanagement, testdatamanagement, geautomatiseerde testen en integratie, met een sterke focus op ondersteuning voor continuous testing."

De behoefte aan deze additionele testcapaciteiten wordt duidelijk wanneer je overweegt enkele van de kernverschillen tussen:

• Automatiseren van takenreeksen in productieomgevingen om een duidelijk gedefinieerd pad door een proces succesvol uit te voeren zodat je sneller werk kunt voltooien, en
• Automatiseren van realistische bedrijfsprocessen in testomgevingen om te zien waar een applicatie faalt zodat je geïnformeerde beslissingen kunt maken over of een applicatie te riskant is om te releasen

Wat betekenen deze verschillen voor softwaretesten?

• Automatisering moet uitvoeren in een testomgeving die typisch incompleet, evoluerend en geconstraineerd is
• Het managen van stateful, veilige, compliant testdata wordt een enorme uitdaging
• Effectief testcase-ontwerp is essentieel voor succes
• Falen moeten inzicht geven in zakelijk risico

Om het in meer concrete termen te zetten, laten we het voorbeeld overwegen van het testen van een online reisdienst. Stel je wilt de functionaliteit controleren die een gebruiker toestaat zijn prepaid hotelreservering te verlengen. Eerst moet je beslissen hoeveel tests vereist zijn om de applicatielogica grondig te oefenen – en welke datacombinaties elk nodig zou hebben.

Dan moet je een manier hebben om alle benodigde data te verkrijgen en te provisioneren om de applicatie in de staat te brengen waar het testscenario uitgevoerd kan worden. In dit geval heb je (minimaal) een bestaand gebruikersaccount met een bestaande prepaid reservering voor een datum in de toekomst – en je kunt geen echte productiedata gebruiken, vanwege privacyregelgeving zoals de AVG.

Vervolgens heb je een manier nodig om de vereiste reeks reacties op te roepen van het verbonden hotelreserveringssysteem (een kamer is beschikbaar/niet beschikbaar), de creditcard (transactie goedgekeurd/geweigerd) etc. – maar zonder daadwerkelijk een kamer te reserveren of een creditcard te belasten.

Je zou het proces moeten automatiseren, natuurlijk. Dit omvat inloggen, de bestaande reservering ophalen, aangeven dat je het wilt wijzigen, en dan de lengte van de verlenging specificeren.

Eenmaal het complete proces geautomatiseerd is, moet je een aantal validaties op verschillende checkpoints configureren. Werden de juiste details naar het hotel gestuurd in het juiste berichtformaat? Wurde de reservering bijgewerkt in je gebruikersdatabase? Wurde betaaldata correct naar de creditcard-provider gestuurd? Wurden eventuele accountcredits toegepast? Kreeg de gebruiker een passend bericht als de reservering niet verlengd kon worden? Wat als de creditcard geweigerd werd? En als de creditcard geweigerd werd, herstelde je systeem de oorspronkelijke reserveringslengte in plaats van extra nachten toe te voegen die niet daadwerkelijk betaald waren?

Stel je nu voor dat je bedrijf besloot een $10 wijzigingsfee toe te voegen voor alle prepaid reserveringen. Kon je deze nieuwe vereiste eenvoudig in je bestaande geautomatiseerde tests schuiven – of moest je elk test substantieel herschrijven om deze kleine wijziging te accommoderen?

Zelfs dit eenvoudige voorbeeld blootstelt enkele van de vele softwaretestcomplexiteiten die RPA-tools gewoon niet ontworpen zijn om aan te pakken. RPA-tools zijn gebouwd om specifieke taken binnen een reeks te automatiseren. Softwaretestautomatisering-tools zijn ontworpen om de veerkracht van een bredere reeks taken te meten. Om het knipoog te zeggen: RPA-tools zijn gearchitecteerd om een proces te laten werken. Maar voor softwaretesten heb je tools nodig die je helpen bepalen hoe een proces kan breken.

Ineffectieve softwaretestautomatisering is berucht om releases te vertragen terwijl ongelooflijke hoeveelheden bronnen worden geconsumeerd. Naarmate CIO's steeds meer investeren in digitale transformatie-initiatieven die de klantervaring verbeteren door snellere softwarelevering, is knoeien met softwaretesten counterproductief. De juiste tool voor de job kiezen zal significant afdragen in termen van versnelde levering, verminderd zakelijk risico, en meer bronnen om te wijden aan innovatie.

Wayne Ariola, is de auteur van Continuous Testing for IT leaders en een bekende keynote speaker in de DevOps en App Dev ruimte.