RPA gebruiken voor softwaretesten:een "tech hack"?

Ineffectieve automatisering van softwaretests is berucht vanwege het vertragen van releases en het verbruiken van ongelooflijke hoeveelheden bronnen.

Om de zoveel tijd bevat mijn nieuwsfeed een artikel met 'The Top 10 Life Hacks'. Dit zijn tips en trucs over het gebruik van gewone huishoudelijke producten op onverwachte manieren om je leven te verbeteren - "... en tip nummer 7 zal je verbazen!!!"

Toegegeven, ik ben erin geluisd om dit klikaas te openen. Eerlijk gezegd zijn er momenten dat ik aangenaam verrast ben. Wie wist bijvoorbeeld dat je vervelende plastic blisterverpakkingen kon doorsnijden met een blikopener, of een rol toiletpapier kon gebruiken om te voorkomen dat inpakpapier uitrolt?

Ik heb de twee "hacks" hierboven geprobeerd en raad eens? Ze "een beetje" werkten ... een tijdje. De blikopener sneed door de naad waar het plastic was gesmolten, maar het sneed niet door de lengte van de verpakking. De wc-rol hield het inpakpapier een tijdje vast, maar uiteindelijk verzwakte het karton en rafelde het inpakpapier uit. Het is niet verrassend dat het gebruik van een schaar voor de plastic blisterverpakkingen en een klein stukje tape voor het inpakpapier veel, veel beter werkte.

In dezelfde geest overwegen veel organisaties nu om RPA te gebruiken om softwaretests te automatiseren:een soort "tech-hack" voor het testen van software. Maar net zoals de wc-papierrol geen duurzame oplossing bood om te voorkomen dat mijn inpakpapier uitrolde, is RPA geen duurzame oplossing voor het automatiseren van softwaretests... en de aanpassingen die nodig zijn om de RPA-tool duurzaam te maken voor de taak van softwaretest automatisering zou, nou ja, een hack zijn.

Als je al een RPA-tool in je organisatie hebt en je wilt aan de slag met testautomatisering, dan lijkt je RPA-tool misschien een logische keuze. Het is meestal relatief eenvoudig om enkele fundamentele testscenario's te automatiseren (bijv. een nieuwe gebruiker maken en een transactie voltooien), validatie toevoegen en denken dat u op weg bent om automatisering te testen.

Het is echter belangrijk om te erkennen dat succesvolle en duurzame testautomatisering veel meer vereist dan de mogelijkheid om door applicatiepaden te klikken. Om boven het sombere industriegemiddelde testautomatiseringspercentage van <20% uit te stijgen, moeten teams ook in staat zijn om een ​​effectieve geautomatiseerde testsuite te bouwen en te stabiliseren. RPA-tools zijn meestal niet ontworpen om dit mogelijk te maken. Als gevolg hiervan zult u obstakels voor testautomatisering tegenkomen, zoals vertragingen bij het wachten op de vereiste testgegevens en testomgevingen, inconsistente resultaten die het vertrouwen in het automatiseringsinitiatief aantasten, en "opgeblazen" testsuites die veel middelen verbruiken maar geen duidelijke, bruikbare feedback.

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

RPA-tools voeren 'als, dan, anders'-statements uit op gestructureerde gegevens, meestal met behulp van een combinatie van gebruikersinterface-interacties (UI), of door verbinding te maken met API's om clientservers, mainframes of HTML-code aan te sturen. Een RPA-tool werkt door een proces in de RPA-tooltaal in kaart te brengen zodat de software "robot" kan volgen, met runtime toegewezen om het script uit te voeren door een controledashboard."

Testautomatiseringstools stellen een organisatie in staat om geautomatiseerde functionele tests te ontwerpen, ontwikkelen, onderhouden, beheren, uitvoeren en analyseren … Ze bieden breedte en diepte van producten en functies gedurende de levenscyclus van softwareontwikkeling (SDLC). Dit omvat testontwerp en -ontwikkeling; onderhoud en hergebruik van testcases; en testbeheer, testgegevensbeheer, geautomatiseerd testen en integratie, met een sterke focus op ondersteuning voor continu testen.”

De noodzaak van deze aanvullende testmogelijkheden wordt duidelijk als je kijkt naar enkele van de belangrijkste verschillen tussen:

• Het automatiseren van reeksen taken in productieomgevingen om met succes een duidelijk gedefinieerd pad door een proces uit te voeren, zodat u het werk sneller kunt voltooien, en
• Realistische bedrijfsprocessen automatiseren in testomgevingen om te zien waar een applicatie faalt, zodat u weloverwogen beslissingen kunt nemen of een applicatie te riskant is om vrij te geven

Wat betekenen deze verschillen voor het testen van software?

• Automatisering moet worden uitgevoerd in een testomgeving die doorgaans onvolledig, evoluerend en beperkt is
• Het beheren van stateful, veilige, conforme testgegevens wordt een enorme uitdaging
• Effectief testcaseontwerp is essentieel voor succes
• Storingen moeten inzicht geven in bedrijfsrisico's

Laten we, om het meer concreet te maken, eens kijken naar het voorbeeld van het testen van een online reisservice. Stel dat u de functionaliteit wilt controleren waarmee een gebruiker zijn prepaid hotelreservering kan verlengen. Eerst moet u beslissen hoeveel tests er nodig zijn om de toepassingslogica grondig te oefenen en welke gegevenscombinaties elk zou moeten gebruiken.

Vervolgens moet u alle gegevens verzamelen en inrichten die nodig zijn om de toepassing in de staat te brengen waarin het testscenario kan worden uitgevoerd. In dit geval heeft u (minstens) een bestaand gebruikersaccount nodig met een bestaande prepaid-reservering voor een bepaalde datum in de toekomst, en kunt u de werkelijke productiegegevens niet gebruiken vanwege privacyregelgeving zoals de AVG.

Vervolgens heeft u een manier nodig om het vereiste bereik van antwoorden van het aangesloten hotelreserveringssysteem (een kamer is beschikbaar/niet beschikbaar), de creditcard (transactie goedgekeurd/geweigerd) enz. op te roepen, maar zonder daadwerkelijk een kamer te reserveren of een creditcard.

Je zou het proces natuurlijk moeten automatiseren. Dit houdt in inloggen, de bestaande reservering ophalen, aangeven dat u deze wilt wijzigen en vervolgens de lengte van de verlenging opgeven.

Zodra u het volledige proces heeft geautomatiseerd, moet u een aantal validaties configureren op verschillende controlepunten. Zijn de juiste gegevens in het juiste berichtformaat naar het hotel gestuurd? Is de reservering bijgewerkt in uw gebruikersdatabase? Zijn de betalingsgegevens correct naar de creditcardaanbieder verzonden? Zijn er rekeningtegoeden toegepast? Heeft de gebruiker een gepast bericht ontvangen als de reservering niet verlengd kon worden? Wat als de creditcard wordt geweigerd? En als de creditcard werd geweigerd, is uw systeem dan teruggekeerd naar de oorspronkelijke reserveringsduur in plaats van extra nachten toe te voegen waarvoor niet daadwerkelijk is betaald?

Stel je nu voor dat je bedrijf heeft besloten om $10 wijzigingskosten toe te voegen voor alle vooruitbetaalde reserveringen. Zou u deze nieuwe vereiste gemakkelijk in uw bestaande geautomatiseerde tests kunnen opnemen, of zou u elke test aanzienlijk moeten herwerken om aan deze kleine wijziging tegemoet te komen?

Zelfs dit eenvoudige voorbeeld onthult enkele van de vele complexiteit van softwaretests waarvoor RPA-tools gewoon niet zijn ontworpen. RPA-tools zijn gebouwd om specifieke taken binnen een reeks te automatiseren. Softwaretestautomatiseringstools zijn ontworpen om de veerkracht van een bredere reeks taken te meten. Om het bot te zeggen:RPA-tools zijn ontworpen om een ​​proces te laten werken. Maar voor het testen van software heb je tools nodig die je helpen te bepalen hoe een proces kan breken.

Ineffectieve softwaretestautomatisering is berucht vanwege het vertragen van releases en het verbruiken van ongelooflijke hoeveelheden bronnen. Aangezien CIO's steeds meer investeren in initiatieven voor digitale transformatie die de klantervaring verbeteren door snellere softwarelevering, is het beknibbelen op softwaretesten contraproductief. Het kiezen van de juiste tool voor de klus zal aanzienlijk lonen in termen van versnelde levering, verminderd bedrijfsrisico en meer middelen om te wijden aan innovatie.

Wayne Ariola, is de auteur van de Continuous Testing voor IT-leiders en een bekende keynote spreker in de DevOps- en App Dev-ruimte.