Testen op architectuurniveau

Helaas. Testen op de manier waarop in de zeventiende eeuw schepen werden gebouwd – door domweg steeds dezelfde bouwtekeningen te repliceren – schiet tekort onder wijzigende omstandigheden. Steeds zijn er nieuwe ontwikkelingen waarop ingespeeld moet worden, steeds sneller volgen ontwikkelingen elkaar op. Denk bijvoorbeeld aan het testen van een SOA-architectuur, aan het testen van pakketimplementatie, aan de inrichting en test van ‘business rule engines’ of aan de inrichting en het gebruik van ‘testtool­suites’. Dit zijn zaken die het overzicht van een individuele tester of testcoördinator duidelijk overstijgen.In de praktijk blijven bewuste keuzes bij de inrichting van het testproces nogal eens achterwege en worden gemaakte keuzes niet verantwoord. En dat terwijl de bedrijfsvoering inmiddels volledig afhankelijk is van informatieverwerking en van de betrouwbaarheid en correctheid ervan. We moeten concluderen dat het testvak (gelet op de risico’s in de operationele bedrijfsvoering) te vaak op onverantwoorde wijze wordt uitgeoefend. Het inrichten en toerusten van een testorganisatie is een vak op zich geworden. Het is het vak van de testarchitect.Bij de inrichting van het testproces hebben we te maken met een reeks van vragen, waar een reeks van oplossingen bij past. Maar welke oplossing past bij welke vraag? Er zijn veel oplossingen mogelijk. Een keuze op één gebied heeft weer gevolgen voor keuzes op andere gebieden. Neem bijvoorbeeld de overgang naar een servicegeoriënteerde architectuur. Dit zal gevolgen hebben voor de toepassing van testmethoden en technieken. En hoe gaan we opgeleverde services testen, wat worden de acceptatiecriteria voor de services?Of denk aan een pakketimplementatie: hoe richten we het test- en acceptatieproces in? Of neem testautomatisering met de implementatie van een testtoolsuite. Wie gaan de testtools gebruiken en hoe zit het met de aansluiting op het testproces, de administratie en het beheer? Standaards en richtlijnen zullen veranderen: Hebben we die? Wat is de invloed van dit alles op planning en beheersing van het testproces? Is het testproces zinvol te versnellen? Zonder dat dit ten koste van de noodzakelijk verantwoording gaat? En softwareontwikkeling wordt geoutsourcet. Kunnen we ervan uitgaan dat de provider geteste software oplevert? Hoe moet de verantwoordelijkheid van betrokkenen afgebakend worden? Kunnen we het testen ook zinvol uitbesteden?Is er een oplossing voor dit complex van vragen? Voor elk van deze vragen is een veelvoud van antwoorden mogelijk en een veelvoud van componenten beschikbaar. Het antwoord is dus dat er niet één oplossing is, er moeten keuzes worden gemaakt. Wat is de juiste keuze en hoe verantwoorden we de gemaakte keuze?Om verantwoorde keuzes te maken, moeten alle te beantwoorden vragen in beeld zijn. Randvoorwaarden moeten in beeld worden gebracht. Om te komen van symptoombestrijding tot een echte oplossing, is een integrale aanpak onmisbaar.Welke gebieden moeten voor het testen in de praktijk een invulling krijgen? Een eerste opdeling geeft het volgende overzicht van aandachtsgebieden:- TesttechniekenHoe testen we? Er zijn tal van testtechnieken. De tester moet weten welke technieken onder bepaalde omstandigheden gebruikt moeten worden. De tester weet hoe ze toe te passen in die omstandigheden.- Hulpmiddelen en testtoolingWaarmee testen we? De tester weet welke tools tot zijn beschikking staan, weet waar ze te gebruiken zijn en waar niet, weet hoe ze gebruikt moeten worden.- Op te leveren productenTesten is niet enkel hard werken, de tester produceert tastbare producten. De tester weet wat te produceren, in welke vorm en kent de standaards en richtlijnen ervoor.- Aansluiting op ontwikkelarchitectuur Het testen houdt rekening met risico’s. Risico’s die herkenbaar in het ontwikkelproces en de architectuur aanwezig zijn, risico’s die specifiek voor een bepaalde omgeving zijn. Denk bijvoorbeeld eens aan het testen bij maatwerk of bij een pakketimplementatie. Denk aan het testen van services: een doel van een service-oriented architecture is flexibiliteit met gelijktijdige beheersing van ontwikkel- en testinspanning.- Aansluiting op het acceptatieproces, eisen en kwaliteitscriteria De invulling van het ‘waarom’ van het testen, de specificatie van testdoelen, prioriteiten en randvoorwaarden.Voeg daarbij de organisatie, het testproces, de procedures en het feit dat er een invulling dient te zijn voor verschillende rollen: de tester, testcoördinator, omgevingsbeheerder en testmanager. Dan moet iemand het overzicht van dit alles hebben, iemand moet weten welke vragen gesteld moeten worden en welke antwoorden er mogelijk zijn. Iemand moet weten welke best practices van toepassing zijn, moet weten waar deze best practices toepasbaar zijn. Iemand moet zicht hebben op de mogelijkheden en onmogelijkheden van dit alles. Iemand moet inzicht hebben in de eisen en randvoorwaarden voor alle betrokken disciplines en stakeholders. En dit betekent dat er één rol toegevoegd wordt aan het geheel: de rol van testarchitect.De te produceren werkwijze is afhankelijk van ambities van de doelorganisatie, van omgevingskenmerken, van randvoorwaarden en prioriteiten. Om een zinvol voorstel te kunnen doen, moet de testarchitect zeer goed op de hoogte zijn van de best practices op het gebied van testen. Hij kent de mogelijkheden en randvoorwaarden van oplossingen en de technologie, ziet de aansluiting op het probleemgebied, op de softwarearchitectuur en het ontwikkelproces.De testarchitect produceert – in samenwerking met de belanghebbenden in de doelorganisatie – een beredeneerde en goed onderbouwde oplossing, die we een testarchitectuur kunnen noemen.De testarchitect werkt samen met (test)specialisten en experts. Hij heeft voldoende kennis van alle betrokken gebieden om met de verantwoordelijke partijen te kunnen overleggen en om behoeften en randvoorwaarden te kunnen herkennen.Daarnaast zal de testarchitect over een brede ervaring op allerlei gebieden (systeemontwikkeling, ontwerp, architectuur, beheer, exploitatie, business, acceptatie, eisen en regelgeving) moeten beschikken. Dit om op zinvolle wijze met betrokken disciplines te kunnen communiceren. Het gaat tenslotte om beantwoording van de vraag: Wat is nodig en wat is voldoende om op verantwoorde wijze tot acceptatie te komen? Wat is belangrijk voor deze organisatie? En dit, om ervoor te zorgen dat wat nodig is, inderdaad ter beschikking komt van de betrokken testteams, om ervoor te zorgen dat testers, testmanagers en beheerders hun werk zo pragmatisch mogelijk kunnen doen – zonder daarbij de professionele normen uit het oog te verliezen.De testarchitect is zelf géén expert – daar zijn de specialisten voor. Met uitzondering van het gebied van de testarchitectuur zelf. En op dit gebied zal de testarchitect zelf natuurlijk zijn eigen best practice moeten beheersen.De vragen die bij het inrichten van de werkwijze bij het testen aan de orde gesteld worden, zijn in feite architectuurvragen. En dat wat we zoeken kan dan ook met recht als een architectuur voor het testen (testarchitectuur) betiteld worden. Er zijn algemene eisen die voor elke oplossing belangrijk zijn: architectuurprincipes. En dan zijn er omgevingsspecifieke factoren: factoren die in hoge mate bepalend zijn voor de toepasbaarheid in een bepaalde omgeving.Een standaardoplossing zal nooit recht kunnen doen aan de specifieke behoeften in een bepaalde situatie. Omgevingsfactoren en prioriteiten zullen steeds bepalend blijven en zullen altijd helder gemaakt moeten worden. Dit geldt temeer daar een veelvoud van ontwikkelingen op ons afkomt en de omstandigheden sneller dan vroeger veranderen. Er is een noodzaak om ambities helder te houden: Wat is belangrijk voor deze organisatie? Om daarbij de haalbaarheid en wenselijkheid van deze ambities zichtbaar te maken voor de betrokkenen. Dit is dan ook de rol van de testarchitect.En hiermee doen we een nieuwe stap in de evolutie van het testproces: van het ‘uitproberen’, via de ontwikkeling van standaardtestmethoden, komend bij een werkwijze op basis van een architectuur. Leidend tot een verantwoorde werkwijze die – onder de gegeven omstandigheden – aantoonbaar de juiste is.Simpel gezegd geeft de testarchitectuur aan testers en testmanagers een praktisch toepasbare werkwijze, inclusief het instrumentarium dat nodig is om die werkwijze succesvol toe te passen – in hoge mate gebaseerd op best practices.Eli Diemer (eli.diemer@capgemini.com) is testarchitect (principle consultant) bij Capgemini.TestprincipesDoel van het testproces is om te komen tot een verantwoorde acceptatie. De inrichting van het testproces wordt uitgevoerd op basis van architectuurprincipes, omgevingsfactoren, randvoorwaarden en prioriteiten. Een aantal voorbeelden.▪ Integratie met de ‘software development life cycle’ (SDLC) is een eis.▪ Integratie van testproces en beheerproces.▪ Stakeholders, requirements en acceptatiecriteria moeten aantoonbaar geadresseerd worden.▪ Ontwikkelarchitectuur moet bekend zijn en is bepalend voor af te dekken risico’s.▪ Om te komen tot controleerbare sturing op testdoelen is toepassing van gestructureerde testtechnieken vereist.▪ Elke test heeft een meetbare dekking op basis van coveragecriteria.TestarchitectuurDe inrichting van het testproces als geheel is een uitwerking van de testarchitectuur. Onderdeel van de testarchitectuur zijn bijvoorbeeld:▪ Master-acceptatieaanpakIdentificatie van stakeholders, afbakening van verantwoordelijkheidsgebieden, specificatie van acceptatiecriteria.
▪ Master-testaanpakDefinitie van het testproces, testsoorten, testdoelen, het wat/hoe/waarmee voor deze testsoorten.▪ TesttechniekenInclusief pragmatische toepassingsinstructie, richtlijnen en standaards.▪ TestwareTemplates (mastertestplan, testplan, testspecificatie, testscript) met bijbehorende invulinstructie.▪ TestomgevingenSFlbConfiguratie, inrichting en gebruik.▪ TestinfrastructuurSFlbConfiguratie, inrichting en gebruik van tooling.▪ Administratie & controlSFlbBeheerprocedures, administratie en communicatie.▪ Kengetallen en planningsnormen