In het vorige deel van mijn blog heb ik uitgelegd hoe de ketentest qua activiteiten volledig is geïntegreerd in het SAFe ® model. Maar ik heb ook verteld dat ik nog iets met diezelfde Ketentest heb gedaan. Dat heeft te maken met de structuur en de rol die testautomatisering (TA) hierin speelt.
Ketentest: Intern vs. Integraal
Het onderscheid tussen een interne- en integrale ketentest heb ik eerder al even aangestipt. Dit zal ik hier nader verklaren. Hierbij hoort het volgende plaatje:
De reden waarom ik dit onderscheid aanbreng, ligt in de afhankelijkheid die je als ART hebt met je omgeving en de impact die dat kan hebben op je eigen organisatie van werkzaamheden. Deze afhankelijkheid kan op diverse vlakken liggen zoals organisatorisch (werkwijze, ritmiek en prioritering van andere teams) en technisch (al dan niet gekoppelde testomgevingen, synchroon lopende testdata en onderhoud op en beschikbaarheid van deze omgevingen).
Om de afhankelijkheden zoveel mogelijk te reduceren kun je je in eerste instantie richten op de zaken die je zelf kunt beïnvloeden: de “eigen keten”, oftewel de interne keten. Je knipt de volledige keten, indien nodig, dus op in twee stukken. In eerste instantie voer je (deel) ketentesten uit op de keten die door de eigen ART wordt beheerd. Uiteraard is dit helemaal afhankelijk van de situatie. In mijn geval start ik bij de API’s die deels door externe teams worden beheerd, waar nodig simuleren we die conform de afspraken die voor de API’s gelden, en voeren we (deel) ketentesten richting de back-end uit. Zolang externe teams nog niet klaar zijn, of elke andere van toepassing zijnde reden, kun je toch alvast het eigen (interne) deel van de keten testen en mogelijke issues wegnemen en risico’s verlagen. Met andere woorden; je reduceert hiermee je doorlooptijd en verkort dus de “Time to Market”.
Zodra de rest van de (integrale) keten beschikbaar komt, kun je de ketentest uitbreiden naar de volledige keten. Hierbij kun je gebruik maken van een deel van de interne keten testset: hergebruik! Doordat je het testproces steeds verder afpelt (Teamtesten, Integratietesten, Interne ketentest) houd je ten slotte alleen nog maar een dunne schil over: de Integrale ketentest en is daardoor eenvoudiger te organiseren en uit te voeren. Belangrijk bij dit alles is dat je een regressie testset opbouwt en onderhoudt. In mijn geval is dat voor zowel de interne- als de integrale ketentest en dan per testomgeving. Dit, omdat de omgevingen qua ontwikkeling uit elkaar lopen. De test omgeving is actueler dan de acceptatie omgeving en loopt mee in de ritmiek van alle teams, terwijl de acceptatie omgeving een weerspiegeling geeft van de nieuwe release naar productie. Hierdoor lopen de testsets ook uit elkaar. Om doorlooptijden nog verder te verkorten, maak je waar relevant ook gebruik van Test automatisering. Hierover meer in de volgende alinea.
Test Automatisering binnen Ketentest
Een belangrijk hulpmiddel om een zo hoog mogelijke effectiviteit binnen de teams te bereiken, maar ook om de risico’s zo beperkt mogelijk te houden, betreft Test automatisering (TA). TA speelt een belangrijke rol binnen Continuous Regression testing en binnen Agile development. Essentieel hierbij is dat we ons steeds afvragen of de kosten opwegen tegen de baten. Uiteraard begint dit al bij het bepalen van je testgevallen: Risico gedreven. Geen risico? Geen test!
Verder bepaalt ieder team zelf de mate van TA en de wijze waarop dit gebeurt. Dit laatste natuurlijk afhankelijk van eventuele corporate richtlijnen. Mogelijk dat een organisatie bijvoorbeeld vooraf heeft bepaald welke tooling mag worden ingezet voor TA.
Daarnaast geldt dat de mate van TA gerelateerd is aan de omvang van alle uit te voeren testen. Hiermee bedoel ik dat het grootste aandeel van TA binnen het volledige testproces vanuit de individuele teams wordt geleverd, omdat daar de meeste testen plaats vinden. Uiteraard geldt de beperking dat niet iedere techniek/component zich (volledig) leent voor TA. Maar toch ligt het grootste aandeel van de totale automatisering binnen de teams.
Het testen van de koppelvlakken door twee teams kent al een kleiner aandeel TA. De interne ketentest, mits dit voldoende oplevert, een nog kleiner deel. En wat mij betreft heeft het vervolgens weinig tot geen zin om de integrale ketentest te automatiseren. Hierbij spelen vaak zoveel afhankelijkheden een rol dat de kosten niet opwegen tegen de baten. De dunne schil van de integrale ketentest wordt dan ook handmatig uitgevoerd. Dit resulteert in het plaatje hier rechts:
Meer informatie
Mijn verhaal komt bijna tot een eind: Maar nog niet helemaal! Ik beschrijf graag nog een extraatje dat de Ketentest overstijgt. Het heeft te maken met ketenkwaliteit in de brede zin van het woord. De keten van samenwerkende teams, werkwijzen en wijze van vast- en verslaglegging. Met één woord bedoel ik hier transparantie. Ik neem je de volgende keer graag mee in dit laatste deel van mijn blog! Ondertussen benieuwd naar meer informatie omtrent Quality Assurance & Testing? Bekijk onze test services.