Categorie: Detacheren

Het handmatig uitvoeren van een nultest door een functioneel beheerder is in de praktijk een tijdrovende en foutgevoelige activiteit. Met de inzet van datarobots behoort dit tot het verleden: door het emuleren van data-invoer zijn handmatige handelingen niet meer nodig.

Tijdens ontwikkeling en acceptatie spenderen organisaties veel tijd en middelen aan wijzigingen in de ontwikkel – en testomgeving. In de productieomgeving checkt een functioneel applicatiebeheerder of de applicatie goed werkt. Hij doorloopt een aantal stappen in de applicatie om vast te stellen of deze na installatie naar behoren werkt. De werkzaamheden zijn vaak simpel en voorspelbaar. Dit is feitelijk de smoketest, die ook de sanity check wordt genoemd. 

In de praktijk gebruiken organisaties voor deze taak zelden tools, waardoor de applicatie eigenlijk niet goed wordt getest. De gebruikers gaan dan werken met een applicatie waarvan niet vaststaat of deze volledig functioneert. Met de inzet van datarobots kunnen organisaties dit probleem oplossen. De datarobot voert de noodzakelijke stappen in het testproces automatisch uit. De datarobot emuleert de handmatige handelingen van de persoon die normaliter de testprocedures uitvoert. Via logging en rapportages is vast te stellen of de installatie en sanity check goed zijn uitgevoerd.

Sneller en accurater

Een datarobot werkt tijdens tesprocedures sneller en accurater. Het uitvoeren van terugkerende stappen gaat foutloos en de feedback op het testproces is sneller beschikbaar. Iemand die de stappen handmatig uitvoert, raakt vroeg of laat een keer afgeleid, waardoor het onvermijdelijk is dat er fouten in het testproces ontstaan.

Elke organisatie die software wil testen, kan voordelen behalen met de inzet van datarobots. Dat geldt met name voor testtrajecten voor applicaties met nieuwe functionaliteit. Met de datarobot is het ook mogelijk om de bestaande functionaliteit te testen. Normaliter is er veel aandacht voor alleen de wijzigingen. Werkt de toegevoegde functionaliteit en wat is het effect op de bestaande functies in de applicatie?

Gaat het om een handmatige sanity check, dan is een functioneel beheerder minimaal een half uur bezig. Met de inzet van een datarobot is het mogelijk om deze klus in vijf minuten te klaren. Op jaarbasis kan een organisatie dus veel tijd winnen met de inzet van datarobots. Door de inzet van datarobots kunnen functioneel beheerders zich voortaan
richten op het bedenken van nieuwe oplossingen en verbeteringen van dienstverlening.

UiPath

Om datarobots daadwerkelijk te gebruiken, is een programma als UiPath vereist. Op basis van logische stappen die nodig zijn bij een smoketest of sanity check wordt een beschrijving gemaakt. Op basis van deze beschrijving wordt een script geprogrammeerd in UiPath. Wie dit programma wil gebruiken, moet wel logisch kunnen programmeren. Ook kennis rondom configuraties is in dit verband vereist.

Toekomst

In de toekomst zullen datarobots frequenter worden inzet en voor de toepassing zal specialistische programmeerkennis niet meer nodig zijn. Het werken met datarobots zal daardoor naar verwachting een stuk eenvoudiger zijn. 

Ben je benieuwd hoe datarobots jouw organisatie kunnen helpen met het verbeteren en versnellen van testprocedures? Neem dan contact met Nadine van de Geer voor een vrijblijvend gesprek over de toegevoegde waarde van datarobots.

Voor het ontwikkelen van software kun je verschillende methodieken inzetten. Een ontwikkelmethode die de laatste jaren aan populariteit wint, is Domain Driven Design. In dit bericht leg ik uit wat Domain Driven Design precies is en welke voordelen bedrijven kunnen behalen bij de inzet van deze manier van ontwikkelen.

Domain Driven Design is eigenlijk een taalonafhankelijke manier om software te ontwikkelen. Het doel is om de complexiteit voor de ontwikkelaar te vereenvoudigen. Een domein is in dit verband een afgebakend gebied binnen het proces. Een autodealer is bijvoorbeeld actief binnen de domeinen sales en marketing. De focus in het domein sales ligt op het verkopen van auto’s. Binnen elk domein vinden bepaalde activiteiten plaats.

Ubiquitous Language

Met Domain Driven Design ga je in een vroeg stadium nadenken over de tactische aanpak van software-ontwikkeling. Welke domeinen spelen een rol op de werkvloer? Op basis van de inventarisatie van domeinen stel je vast wat eigenlijk de core business van jouw bedrijf is. Het is dan duidelijk waar je de beste krachten kunt inzetten. Je hebt het dan over ontwikkelaars en domeinexperts, die beschikken over de benodigde domeinkennis. Het is de bedoeling dat elke deelnemer genoeg domeinkennis heeft, zodat iedereen dezelfde taal spreekt. Dat noemen ze ook wel Ubiquitous Language.

Een afgebakend gebied waar ze allemaal dezelfde taal spreken heet een Bounded Context. Binnen die context is er geen discussie over de betekenis van termen. Alle kennis is in een afgebakende context binnen het team aanwezig. Termen kunnen in een andere context weer een geheel andere betekenis hebben. Het is daarom goed dat bij de toepassing van Domain Driven Design consensus bestaat over de betekenis van termen.

Voordelen Domain Driven Design

Met Domain Driven Design werk je met modellen die je als team opstelt. Zo’n model is een vereenvoudigde weergave van de werkelijkheid en stelt je in staat om op voorhand met het team na te denken over de domain events die plaatsvinden. Een model is ook weer eenvoudig aan te passen wanneer men niet tevreden is over de uitwerking van dit model. Dit model kan vervolgens omgezet worden in software om het model verder te valideren. De uiteindelijke software is een 1-op-1 vertaling van het bedachte model. De software wordt dan ook beschrijvend in wat het moet gaan doen en is documentatie gewaarborgd via het model en de software. Dat ontbreekt in andere methodieken, waar je deze 1-op-1 vertaling niet terugziet in de documentatie die beschrijft wat de software zou moeten doen. Met de toepassing van Domain Driven Design doe je dat wel en dat is een voordeel.

Een ander voordeel van Domain Driven Design is dat dat je in een vroeg stadium al een model opstelt van de software die je wilt gaan ontwikkelen. Dat kan gaan om een compleet nieuwe tool, maar het kan ook vernieuwingen van bestaande software betreffen. Je maakt eigenlijk een simpel model over de beoogde werking van de software.

Een pluspunt is ook dat je als teamlid direct in contact staat met degene die kennis heeft over het domein. Met Domain Driven Design heb je niet meer te maken met vertaalslagen tussen bijvoorbeeld een Software Analist, een designer en een ontwikkelaar. Je spreekt namelijk al dezelfde taal en deelt hetzelfde model. Je haalt zo miscommunicatie uit het projectteam.

Learning Curve

Organisaties die Domain Driven Design willen toepassen moeten wel rekening houden met een learning curve. Om goede resultaten te boeken moet elke teamlid namelijk over kennis van deze ontwikkelmethode beschikken. Ze moeten weten wat de voordelen van Domain Driven Design zijn. Je hebt iemand nodig die deze kennis in het projectteam kan inbrengen.

Eigenlijk hebben alle organisaties wel baat bij de inzet van Domain Driven Design. Na de introductie in 2004 was nog niet iedereen klaar om met deze methode aan de slag te gaan. Maar omdat applicaties steeds complexer worden is het belangrijk dat je simpele modellen kunt ontwikkelen om de werking te beschrijven. Met Domain Driven Design vereenvoudig je de complexiteit tijdens het ontwikkelproces.