Leiderschap in testen: assurance van bedrijfsprocessen in ondernemingen
Noot van de redactie: Welkom bij de serie Leadership In Test van softwaretestexpert en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral testers in agile teams—te helpen uitblinken in hun rollen als testlead en manager.
In het vorige artikel bekeken we de tools die je nodig hebt voor effectief testen en samenwerken. In dit artikel bespreken we de laatste testfase en hoe je kunt bevestigen dat je systemen zullen leveren wat gepland is.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te krijgen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn fragmenten uit Pauls Leadership In Test-cursus, die we sterk aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Gebruik bij inschrijving onze exclusieve kortingscode QALEADOFFER om $60 korting te krijgen op de volledige cursusprijs!
We zijn aangekomen bij de laatste paar artikelen in de Leadership In Test-serie. Tot nu toe hebben we besproken hoe je een testproject van begin tot eind plant en beheert, evenals veel van de betrokken tools en processen.
In dit artikel wil ik borging van bedrijfsprocessen op ondernemingsniveau (EBPA) bespreken—wat het is en hoe je het kunt aanpakken. We behandelen:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Wat is borging van bedrijfsprocessen op ondernemingsniveau?
- Inzicht in systeemintegratie en testen
- Horizontaal testen: de E2E-testaanpak
- Integratierisico's en E2E-testen
Er is veel te behandelen, dus laten we beginnen.
Wat is borging van bedrijfsprocessen op ondernemingsniveau?
Elke organisatie die nieuwe systemen implementeert, heeft problemen ervaren bij het eerste gebruik ervan. Systemen die zelfs maar enigszins afwijken van de bestaande infrastructuur en bedrijfsprocessen kunnen grote chaos veroorzaken en moeilijk te herstellen zijn.
Iteratieve, agile en meer samenwerkingsgerichte werkwijzen helpen, maar de uitdagingen van integratie binnen de hele organisatie kunnen alleen worden aangepakt met een laatste testfase.
We noemen deze laatste fase borging van bedrijfsprocessen op ondernemingsniveau (EBPA). Succes hangt af van een of meer testfasen die aantonen dat de systemen, bedrijfsprocessen en gegevens geïntegreerd zijn en de beloofde diensten leveren.
Er zijn maar weinig wetenschappelijke artikelen over dit onderwerp, hoewel de laatste fasen van elk grootschalig project door deze activiteit worden gedomineerd. Om onze EBPA-strategie vorm te geven, bekijken we eerst de soorten systeemintegratie en testen waarmee je te maken krijgt nader.
Voor projecten op organisatieniveau neemt de complexiteit exponentieel toe. Daarom kan het kiezen van software voor databasebeheer op organisatieniveau een enorme verbetering betekenen voor je kwaliteitsengineeringinspanningen.
Inzicht in systeemintegratie en testen
Verticale integratie
Vanuit technisch perspectief staat integratie voor de verbinding tussen de verschillende lagen van de technische architectuur. Integratietesten voor ontwikkelaars bestaan meestal uit controles of gegevens die via de gebruikersinterface in een bijwerktransactie zijn geaccepteerd, succesvol in de database worden opgeslagen.
In de andere richting worden de opgeslagen gegevens gecontroleerd, zodat ze nauwkeurig in de gebruikersinterface kunnen worden weergegeven wanneer daarom wordt gevraagd. De verbindingen en paden door de technische architectuur kunnen worden gezien als verticale paden of verticale integratietests.
Horizontale integratie
Eindgebruikers zien de technische architectuur en alle complexiteit ervan niet. Ze bekijken het systeem als een reeks functies, die door verschillende gebruikers worden uitgevoerd in wat een gebruikersreis kan worden genoemd.
Deze gebruikersreizen volgen paden in de bedrijfsprocessen van gebruikers en gebruiken bij elke stap op het pad de gebruikersinterface om toegang te krijgen tot verschillende systemen en functies.
Agile teams werken aan verhalen op kleinere schaal en zien het grotere epische verhaal niet. Ontwikkelaars kunnen langere gebruikersreizen meestal ook niet traceren en testen, omdat ze niet over de omgevingen of gegevens beschikken. Daarom vertrouwen organisaties doorgaans op tests en testteams op grotere schaal om deze te valideren.
Gebruikersreizen omvatten van nature het bedrijfsproces en de systeemfuncties in combinatie. Op deze manier testen horizontale tests de integratie tussen de systemen en het bedrijfsproces.
Verticale integratietests hanteren een technischer perspectief; horizontale tests hanteren een gebruikers- of bedrijfsprocesperspectief.
Laten we deze concepten nu gebruiken om een model op te stellen dat ons helpt EBPA te begrijpen en te plannen. In het model verwijzen we naar de horizontale en verticale integratiebenaderingen.
Een model voor integratie en testen
Integratie is een concept dat vaak verkeerd wordt begrepen. Het integratieproces begint feitelijk vrijwel zodra het coderen begint. Je zou kunnen zeggen dat integratie begint zodra we twee regels code hebben — de tweede regel code moet met de eerste worden geïntegreerd. Integratie eindigt wanneer alle functionele tests bij de gebruikersacceptatie zijn afgerond.
Laten we ons richten op een voorbeeld met kant-en-klare commerciële modules (COTS) en modules voor enterprise resource planning (ERP).
Het softwarebedrijf dat COTS- of ERP-modules maakt, heeft unit- en functionele tests uitgevoerd. Wanneer deze componenten arriveren, mag doorgaans worden aangenomen dat ze werken en technisch kunnen worden geïntegreerd. Er bestaat echter altijd een risico dat geïntegreerde componenten van verschillende leveranciers op onvoorziene manieren op elkaar reageren.
Als componenten bovendien worden aangepast, verandert hun gedrag en zal dit waarschijnlijk opnieuw subtiele (en niet zo subtiele) neveneffecten elders veroorzaken. Er blijft behoefte aan verticale integratie om de uitwisseling van besturing en gegevens in de technologiestack te verifiëren, en aan horizontale integratie tussen componenten en het bedrijfsproces.
We geven de vier integratieactiviteiten weer in een model met vier kwadranten en twee assen. Op de X-as staat de schaal van het systeem dat wordt getest – óf één afzonderlijke component of subsysteem, óf de geïntegreerde systemen in de context van het bedrijfsproces.
De rechterkant van het model is blauw gearceerd en vertegenwoordigt EBPA. Het testen van ons systeem in de context van andere systemen (SIT) en het bedrijfsproces (BIT) noemen we borging van bedrijfsprocessen binnen de onderneming.
Laten we de vier kwadranten achtereenvolgens bekijken.
Testen van modules, functies of componenten
De module moet functioneel worden getest, ongeacht of deze op maat is gebouwd of een COTS-component is. De gebruikerservaring is altijd belangrijk en moet worden geïntegreerd met een stap of activiteit in het bedrijfsproces.
Integratietests van subsystemen
Integratie verloopt incrementeel. Naarmate componenten en functies op laag niveau beschikbaar komen, worden ze geïntegreerd in het steeds grotere systeem en getest totdat het volledige, samenhangende systeem gereed is. Dit noemen we integratietests van subsystemen.
Systeemintegratietests (SIT)
Geen enkel systeem bestaat geïsoleerd, dus wanneer ons systeem compleet is, moeten we dat systeem integreren met andere systemen. We installeren ons systeem in een omgeving met de systemen waarmee het interfaces heeft en testen deze systemen terwijl ze via deze interfaces samenwerken als een ‘systeem van systemen’. Ons doel in deze fase is het aanpakken van de technische integratierisico’s; dit noemen we systeemintegratietests.
Bedrijfsintegratietests (BIT)
Er is een laatste integratiefase die ervoor moet zorgen dat de gebouwde systemen integreren met de bedrijfsprocessen en (vaak handmatige) procedures van de gebruikers van die systemen. Inclusief de externe interfaces van het systeem (als die nog niet zijn getest), valideren we dat de systemen en bedrijfsprocessen, die in samenwerking functioneren, samenhangende en efficiënte gebruikersreizen bieden en gegevens correct en consistent beheren en overdragen. Dit noemen we doorgaans bedrijfsintegratietests.
Voor de rest van dit artikel richten we ons grotendeels op de horizontale, EBPA-kant van het model.
Gerelateerd artikel: 10 BESTE TOOLS VOOR TESTGEGEVENSBEHEER
Horizontaal testen: de E2E-testbenadering
Horizontale integratie is vooral afhankelijk van wat vaak end-to-endtesten (E2E) wordt genoemd.
E2E-testen is een testontwerptechniek waarbij een reeks verbonden transacties wordt aangeroepen, die doorgaans meerdere systemen omvat, waaronder ons te testen systeem of onze te testen systemen. Deze tests volgen meestal gebruikersreizen door hun bedrijfsprocessen.
Uitgaande van een model van een bedrijfsproces worden paden door het proces gevolgd om een bruikbare reeks transacties te creëren die simuleert hoe gebruikers het systeem in productie zullen gebruiken.
Deze modellen kunnen bekende diagrammen zijn, zoals stroomdiagrammen of swimlanediagrammen, of meer technische weergaven, zoals UML-sequentie- of samenwerkingsdiagrammen. (UML is de uniforme modelleertaal die door veel IT-organisaties wordt gebruikt).
E2E-tests pakken specifieke risico’s aan die niet eenvoudig kunnen worden aangepakt door eerdere tests op subsystemen of in omgevingen die sterk afhankelijk zijn van gestubde interfaces en uitsluitend synthetische gegevens.
Op het gebied van horizontaal testen wordt de E2E-testbenadering vaak aangevuld met gespecialiseerde software. Bekijk voor een zorgvuldig samengestelde lijst met software die dit proces kan stroomlijnen deze best beoordeelde oplossingen voor testbeheer
Acceptatie
Het begrip ‘passendheid’ is van toepassing op de integratie van componenten met componenten, systemen met systemen en systemen met bedrijfsprocessen.
Acceptatie is normaal gesproken gebaseerd op de resultaten van horizontale E2E-tests, omdat belanghebbenden uit de business erop kunnen vertrouwen dat deze tests laten zien hoe het nieuwe systeem aansluit op en ondersteuning biedt voor hun manier van werken. Horizontale E2E-tests geven hun het vertrouwen dat de geleverde dienst zal werken.
Het acceptatieproces voor systemen is meestal, ten minste gedeeltelijk, afhankelijk van succesvolle horizontale E2E-tests. Dit komt doordat alleen E2E-tests het systeem in een realistische omgeving uitvoeren en realistische gebruikersactiviteiten simuleren.
In veel organisaties is het pas in de laatste testfasen mogelijk om te demonstreren dat systemen werken, en dit geeft belanghebbenden het vertrouwen dat het systeem naar behoren zal werken.
Als je wordt gevraagd een acceptatietest te plannen, verwachten we dat de E2E-testtechniek een grote rol zal spelen in je planning.
Integratierisico’s en E2E-tests
Zoals besproken hebben integratierisico’s betrekking op de integratie van systemen met systemen of systemen met bedrijfsprocessen.
Sommige organisaties kiezen ervoor de tests die deze twee risicotypen aanpakken op te splitsen in systeemintegratietests (SIT) en bedrijfsintegratietests (BIT). Vaak worden de risico’s en tests echter samengevoegd in één testfase met het label E2E, Acceptatie of bedrijfstests.
Ongeacht hoe de tests zijn gestructureerd, er wordt uitgebreid gebruikgemaakt van de hierboven uitgelegde E2E-testaanpak. In jouw omgeving kunnen de risico’s waarmee je te maken krijgt variaties op deze thema’s zijn en moet je mogelijk het testdoel en je testaanpak dienovereenkomstig aanpassen.
De hier gepresenteerde lijst met risico’s moet uitsluitend worden beschouwd als een startpunt en als herinnering aan waar je je testinspanningen op moet richten. Waarschijnlijk zijn er risico’s die specifiek zijn voor jouw organisatie, bedrijfstak of technologie en die je aan deze startlijst moet toevoegen.
In de onderstaande tabel verwijst ‘systemen’ naar de verzameling geïntegreerde systemen waaruit het nieuwe systeem of de nieuwe systemen in ontwikkeling bestaan, evenals andere verouderde of infrastructuursystemen en externe systemen, bijvoorbeeld banken of partnerorganisaties.
| Risico | Testdoel | Testaanpak |
| Systemen zijn niet geïntegreerd (gegevensoverdracht). | Aantonen dat systemen zijn geïntegreerd en de gegevensoverdracht correct uitvoeren. | Systeemintegratietest (SIT) |
| Systemen zijn niet geïntegreerd (controleoverdracht). | Aantonen dat systemen zijn geïntegreerd (de controleoverdracht met de vereiste parameters wordt correct uitgevoerd). | SIT |
| Interfaces werken niet wanneer ze gedurende langere tijd worden gebruikt. | Aantonen dat interfaces gedurende langere tijd continu kunnen worden gebruikt. | SIT (Deze controles kunnen ook worden uitgevoerd als onderdeel van betrouwbaarheidstests en/of failovertests) |
| Systemen zijn niet geïntegreerd (gegevens komen niet overeen tussen interfaces). | Aantonen dat systemen zijn geïntegreerd (gegevens die via een interface worden overgedragen, worden consistent gebruikt, bijvoorbeeld valuta, taal, meeteenheden, tijdstippen, nauwkeurigheid en toleranties). | SIT |
| Systemen zijn niet gesynchroniseerd (gegevensoverdrachten worden niet gestart, op het verkeerde moment gestart of meerdere keren gestart). | Aantonen dat gegevensoverdrachten correct worden gestart. | SIT |
| Objecten of entiteiten die in meerdere systemen bestaan, komen niet overeen tussen de systemen. | Aantonen dat de statussen van bedrijfsobjecten nauwkeurig worden weergegeven in de systemen die gegevens over de objecten bevatten. | Bedrijfsintegratietest (BIT) |
| Systemen zijn niet geïntegreerd met het bedrijfsproces (de toeleveringsketen). | Aantonen dat de systemen integreren met bedrijfsprocessen en het proces van de toeleveringsketen ondersteunen. | BIT |
| Bedrijfsprocessen aan de achterkant ondersteunen de web- of mobiele frontends niet. | Aantonen dat de processen van de toeleveringsketen werkbaar zijn en de bedrijfsdoelstelling ondersteunen. | BIT |
| Geïntegreerde systemen die door dezelfde medewerkers worden gebruikt, hebben inconsistente gebruikersinterfaces of gedragingen voor vergelijkbare of gerelateerde taken. | Aantonen dat gebruikers consistent gedrag ervaren in de verschillende systemen bij het uitvoeren van vergelijkbare of gerelateerde taken. | BIT (Deze controles kunnen ook worden uitgevoerd tijdens UX-controles) |
Opmerkingen bij de risicotabel
Sommige van de bovenstaande risico’s hebben iets meer uitleg nodig.
Problemen met gegevensoverdracht
Vaak worden gegevens tussen systemen via netwerken overgedragen. Als deze overdrachten als batchprocessen worden uitgevoerd en mislukken, of mislukken als realtime overdracht die door een gebeurtenis van een gebruiker, de bedrijfsomgeving of een ander systeem wordt gestart, ontbreken er gegevens in het doelsysteem.
Onjuiste controleoverdracht
Een controleoverdracht vindt plaats wanneer een gebruikersactiviteit of systeemproces de gebruiker of het proces overdraagt aan een andere functie van het systeem.
Doorgaans is er een keuze uit doelfuncties en wordt, afhankelijk van de gebruikersactie of de gegevensinhoud van een transactie, een andere route door de applicatie gekozen.
Vanuit het perspectief van de gebruiker wordt deze naar de verkeerde plaats in de applicatie geleid, of verwacht een systeemproces het verkeerde proces uit te voeren en raakt het de synchronisatie kwijt.
Gegevens komen niet overeen
Een systeem kan gegevens verspreiden met betrekking tot bijvoorbeeld geld, de locatie van activa of een bepaalde fysieke hoeveelheid die in alle systemen bij elkaar moet optellen.
Wanneer bijvoorbeeld 100 voorraadartikelen worden ingekocht en verplaatst, verkocht, gebruikt in productieprocessen, als defect worden aangemerkt en geretourneerd of afgedankt, moet het aantal artikelen dat in elk subsysteem wordt aangehouden, overeenkomen met het oorspronkelijke aantal van 100.
Een variant op dit probleem betreft bijvoorbeeld de eenheden die worden gebruikt in de systemen waarin gegevens worden opgeslagen. Er moet rekening worden gehouden met de batchgroottes of aggregaties van getelde items, of systemen moeten metrische en imperiale meeteenheden op elkaar afstemmen, enzovoort.
Systemen zijn niet gesynchroniseerd
In samenhang met het eerdergenoemde probleem van gegevensoverdracht moeten de systeemprocessen die overdrachten uitvoeren in de juiste volgorde worden gepland, worden geactiveerd door processen of personen met de juiste autorisatie, en tijdig en door de juiste gebeurtenis of combinatie van gebeurtenissen worden gestart.
Sommige batchprocessen moeten elk uur, dagelijks, wekelijks, aan het einde van de maand, het kwartaal of het jaar enzovoort worden uitgevoerd en moeten worden gecontroleerd. Veel functioneel gedrag hangt af van de onderlinge timing van transacties of de ouderdom van gegevens in verschillende systemen en moet daarom ook worden gecontroleerd.
Objecten komen niet overeen
Deze risico's hebben geen betrekking op aantallen objecten, geldbedragen of fysieke metingen, maar op de status van objecten die in gedistribueerde systemen worden opgeslagen. Zo moet de status van een medewerker in een personeelsrecord consistent zijn in alle systemen waarin kopieën van dat gegevensobject worden bewaard. De processen die statuswijzigingen verspreiden over systemen waarin kopieën van hetzelfde object worden bijgehouden, moeten worden geactiveerd en hun acties moeten worden gecontroleerd.
Systemen zijn niet geïntegreerd met de bedrijfsvoering
Het gedrag van systemen moet worden afgestemd op de bedoelingen van gebruikers. Typische problemen ontstaan wanneer het systeem onvolledige, verouderde of onjuiste informatie toont. De onderliggende oorzaak is dat gegevensoverdrachten of synchronisaties niet correct werken, maar deze problemen komen via de gebruikersinterface aan het licht.
Back-endprocessen ondersteunen de front-end niet
Dit type probleem manifesteert zich als een inconsistentie tussen registratiesystemen en interactiesystemen. Back-endbatchprocessen die niet vaak genoeg of helemaal niet worden uitgevoerd, stellen geen gegevens beschikbaar aan front-endsystemen voor interactie. Op dezelfde manier worden gebruikerstransacties via interactiesystemen niet weergegeven in registratiesystemen.
Inconsistente gebruikersinterfaces
Wanneer een bedrijf of dienst wordt aangeboden via mobiele, web- en kioskinterfaces, gedraagt de gebruikersinterface zich verschillend of inconsistent. Ze zijn mogelijk allemaal afzonderlijk getest, maar hun gedrag verschilt. Zo kunnen verschillende regels voor invoervalidatie worden toegepast, kunnen verschillende gegevensvelden worden vastgelegd of weergegeven, of kan de volgorde van invoer verschillen.
Slotgedachten
We hebben een model voor integratie en testen gepresenteerd waarin bedrijfsbrede integratie en het bedrijfsproces centraal staan. De E2E-aanpak is de enige aanpak die volledige systeemintegratie vereist en tests baseert op volledige gebruikersreizen. Op deze manier kunnen belanghebbenden bewijs zien dat systemen correct werken in een realistische context.
Veel organisaties vertrouwen erop dat gebruikers een vorm van E2E-testen toepassen in hun acceptatietests en deze tests handmatig uitvoeren. Op basis van mijn ervaring pleit ik voor een meer systematische, risicogebaseerde aanpak die het eenvoudiger maakt om een groot deel van de arbeidsintensieve testuitvoering te automatiseren.
Naarmate organisaties agile en meer dynamische ontwikkelbenaderingen voor continue levering invoeren en agile teams meer verantwoordelijkheid geven voor het testen van hun subsystemen, is het gemakkelijk om latere bedrijfsbrede integratie- en acceptatietests te verwaarlozen.
De EBPA-aanpak, vooral wanneer deze geautomatiseerd is, breidt het regime van continue integratie uit van subsystemen naar waarborging van bedrijfsprocessen op ondernemingsniveau.
COTS- en ERP-pakketten maken het mogelijk om zeer krachtige maar complexe systemen te implementeren met minder ontwikkelinspanning, maar de integratierisico's zijn net zo prominent als bij de ontwikkeling van maatwerksoftware.
In grotere omgevingen worden agile- en continueleveringsbenaderingen steeds populairder. Naarmate de complexiteit en schaal toenemen, neemt dus ook de leveringsfrequentie en het bijbehorende risico toe.
De oplossing is duidelijk: organisaties moeten EBPA serieus nemen. Ze moeten integratierisico's begrijpen en weten hoe ze tests moeten structureren om deze risico's aan te pakken. Testers moeten overstappen op de moderne modelgebaseerde aanpak, hun bedrijfsprocessen, systemen en tests abstraheren en testautomatisering systematisch implementeren.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de reeks online komen. Deze berichten zijn fragmenten uit Pauls Leadership In Test-cursus, die we van harte aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Gebruik in dat geval onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Aanbevolen om te lezen: 10 BESTE OPEN SOURCE-TESTMANAGEMENTTOOLS
