De kwaliteitsmonitor versus de testmanager

In november 2011 is het concept Project de Baas gelanceerd. Met dit concept is een integrale manier van kijken geïntroduceerd, ofwel dat vanuit het proces, de middelen en de organisatie de implementatie van het nieuwe c.q. gewijzigde informatiesysteem wordt gerealiseerd. Na de launch kwam regelmatig de vraag naar voren wat is nu het verschil tussen een kwaliteitsmonitor een testmanager? Dit artikel gaat op de verschillen in.

Allereerst wil ik eerst de definities geven van de kwaliteitsmonitor en de testmanager. De testmanager is de persoon die verantwoordelijk is voor het projectmanagement van testactiviteiten en testmiddelen, evenals het evalueren van een testobject. De persoon die de evaluatie van een testobject stuurt, beheerst, administreert, plant en reguleert. De kwaliteitsmonitor is verantwoordelijk om de inpasbaarheid van het nieuwe c.q. gewijzigde informatiesysteem in de lopende organisatie vast te stellen, ten aanzien van het proces, de middelen en de organisatie.

Wat zijn nu de verschillen? Laten we daar eens verder op ingaan.

De verschillen

Het verschil tussen de kwaliteitsmonitor en de testmanager is op verschillende manieren te duiden. Vanuit de positionering, vanuit het proces en vanuit de scope.De testmanager zoals we die tot op heden kennen maakt onderdeel uit van de voortbrengingsketen en is in het algemeen verantwoordelijk voor een testsoort of een testvorm. Daarbij zijn ze veelal gepositioneerd aan de aanbodzijde. Een aantal organisaties maakt gebruik van de rol van programmamanager test waarbij de span of control groter en omvangrijker is dan een bepaalde testsoort of testvorm. De kwaliteitsmonitor kijkt niet naar een specifieke testsoort of testvorm maar kijkt over het gehele traject, waarbij vooral de interactie tussen de diverse onderdelen onderwerp van aandacht is. De kwaliteitsmonitor is gepositioneerd aan de vraagzijde. Juist om vast te stellen of het nieuwe/gewijzigde informatiesysteem goed aansluit bij de organisatie en de bedrijfsprocessen. De kwaliteitsmonitor is op programmaniveau of op C-level gepositioneerd.

Een ander kenmerkend verschil is de scope. De testmanager is (vaak) verantwoordelijk voor het testen van het informatiesysteem zelf. Een uitzondering daarop is de testmanager die verantwoordelijk is voor de gebruikers acceptatietest (=GAT). Afhankelijk van de organisatie inrichting kan bijvoorbeeld de werkinstructie ook getest worden. De kwaliteitsmonitor test het informatiesysteem over het algemeen niet zelf maar krijgt de informatie aangereikt vanuit de voortbrengingsketen, gepresenteerd via het zogenaamde dashboard. Dit betreft alleen de middelen! Voor de procesverificatie en/of het vaststellen van de organisatiegereedheid organiseert de kwaliteitsmonitor vaak zelf validatiesessies.Een ander opmerkelijk verschil is in de transitie gelegen. De kwaliteitsmonitor kijkt ook nadrukkelijk naar de wijze waarop de organisatie de transitie naar de nieuwe situatie vorm geeft. In het bijzonder ligt hier de nadruk op de organisatiegereedheid. Weten de diverse partijen wat er van hun verwacht wordt en op welk moment? Denk bijvoorbeeld aan productiedraaiboeken. De testmanager kijkt daar over het algemeen niet naar. De focus ligt wellicht op een bepaalde testvorm (bijvoorbeeld de conversie) maar verder zal de betrokkenheid niet reiken.

Al eerder is de span of control genoemd. Ik wil daar nog even verder op ingaan. De testmanager is, zoals al aangegeven, verantwoordelijk voor een deelactiviteit. Denk daarbij aan een testsoort en/of testvorm. Op basis van acceptatiecriteria wordt voor het betreffende deel, testen voorbereid en uitgevoerd. De resultaten worden gerapporteerd. De span of control beperkt zich dan tot de betreffende testsoort en/of testvorm. Voor de kwaliteitsmonitor is een testsoort of een testvorm slechts een schakel in de gehele keten. Alle gedefinieerde testsoorten en/of testvormen vormen onderdeel van de span of control. De resultaten worden door de kwaliteitsmonitor geanalyseerd en vertaald naar de impact voor de organisatie of de bedrijfsprocessen.Tot zover een kort overzicht van de meest kenmerkende verschillen tussen de testmanager en kwaliteitsmonitor. Mochten er in de toekomst nog meer opmerkelijke verschillen ontstaan dan zal ik een update verzorgen van dit artikel.

Het schrijverscollectief

Project de Baas is ontwikkeld door een schrijverscollectief. Het schrijverscollectief is een interdisciplinair collectief van praktijkmensen die elkaar gaande weg hun professionele loopbaan één of meerdere malen zijn tegengekomen tijdens diverse projecten in diverse contexten en altijd met oog voor het resultaat. In de loop van de jaren heeft het woord ‘integraliteit’ hen gebonden en is daardoor de basis van het boek gaan vormen.

Het schrijverscollectief bestaat uit Jos van Rooyen, Jan Fokke Mulder, Hanneke Kroon – van der Linde, Hans Somers en Jurgen van Amerongen.Voor meer achtergrond informatie kan onderstaande literatuur geraadpleegd worden.

[Lit. 1] ‘www.projectdebaas.nl – 2011
[Lit. 2] ‘Project de Baas’-J. van Rooyen et all – 2011
[Lit. 3] ‘De kwaliteitsregisseur’ – Werkgroep Testregie, TestNet – 2011
[Lit. 4] ‘Testwoordenboek’ – E van Veenendaal, M. Posthuma – 2010

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!