Test4change: Testen zonder specificaties - Qquest

Actualiteit

Test4change: Testen zonder specificaties

Mijn naam is Richard en ik test al 10 jaar namens Qquest bij verschillende opdrachtgevers. Mijn passie is om bij mijn opdrachten te zoeken naar manieren om testen te automatiseren. Daarnaast coördineer ik ketentesten waarbij ik processen test die meerdere technische teams en systemen overstijgen. Binnen Qquest ben ik betrokken bij het ontwikkelen en geven van trainingen. 

Test4change-Richard-Scholtes-Qquest

Wanneer ik start bij een nieuwe opdracht is het soms even uitzoeken waar ik moet beginnen. Ik weet namelijk nog niet hoe alles werkt, wat er belangrijk is voor het proces en wat ik ga testen. Volgens een klassieke methode zou je uit kunnen zoeken hoe alle complexe onderdelen werken om vervolgens testgevallen op te stellen. Na het uitvoeren van de testen in de sprint zou je deze testgevallen kunnen toevoegen aan een set van regressietesten en tenslotte deze set gaan automatiseren.

In opdrachten waar Agile wordt gewerkt, kan er beter gekozen worden voor een andere aanpak. Een aanpak waarbij ik als tester iets kan zeggen over de kwaliteit van een systeem zonder dat ik precies weet hoe een systeem werkt. In deze blog vertel ik hoe ik (snel) succesvolle testautomatisering heb opgebouwd bij meerdere opdrachtgevers met de aanpak die ik heb gedoopt tot: Test4Change.

Testen zonder financiële kennis

Test4Change startte toen ik bij een opdrachtgever aanhaakte bij een scrumteam. Dit team was verantwoordelijk voor meerdere systemen die pensioenen van miljoenen klanten regelt. Het was een systeem dat al meer dan 30 jaar draaide en niet eenvoudig vervangen kon worden. Het systeem was aan veel processen verbonden en een compleet functioneel ontwerp miste.

In mijn trainingen, waarbij ik mij richt op de basis van ketentesten, leer ik collega’s dat het zoeken van documentatie de eerste stap is binnen het testproces. In deze situatie was dit dus niet mogelijk. In plaats daarvan ging ik naar een gebruiker die al bijna 30 jaar met het systeem werkt. Tijdens mijn gesprekken met deze ‘key-user’ merkte ik al snel dat een normale gebruiker een financiële studie of achtergrond nodig heeft om het systeem goed te kunnen gebruiken. Daarnaast is inwerktijd van ruim een maand nodig. Om het vervolgens goed te begrijpen en uit te kunnen leggen, daar is meerdere jaren ervaring voor nodig. Ik zat in een scrumteam dat iedere twee weken wijzigingen maakte en deze getest wilde hebben. Door deze snelheid ging ik op zoek naar een andere aanpak.

Testen zonder verwachting

Ik ging opzoek naar een manier om iets te zeggen over het systeem zonder dat ik wist hoe het precies werkte. Dit is in principe niets nieuws, want privé test ik dagelijks apparaten en systemen zonder dat ik weet hoe het precies werkt. Onlangs kocht ik een set bluetooth oordopjes. De software op mijn telefoon legde prima uit hoe ik met twee knoppen, één op elk oordopje, verschillende functies kon gebruiken, zoals opnemen, ophangen, muziek door- en terugspoelen. De functies voor het formule harder en zachter zetten waren nergens voorbijgekomen, maar door simpelweg te proberen wat er gebeurt als je een knop langer ingedrukt houdt was ik daar al snel achter. Voor de resultaten van deze ‘test’ hoefde ik uiteraard geen verantwoording af te leggen. Bij mijn opdracht moest ik wel uitleggen wat en hoe ik test en vervolgens rapporteren over de kwaliteit. Eén van de wijzigingen in het systeem was de wettelijke verhoging van de pensioensleeftijd. De beschikbare informatie was heel specifiek beschreven voor de ontwikkelaar. Zonder financiële achtergrond kon hij mij niet helpen met het voorspellen van waarden die bij verschillende situaties uit het systeem moeten komen. Zonder verwachte waarden kon ik geen standaard testgeval formuleren: hier lag voor mij de uitdaging.

Focus op verandering

Als oplossing heb ik een testtool geprogrammeerd waarin ik de input en output van het systeem bewaar. Met één druk op de knop kon ik de output van het systeem inlezen in de testtool en vergelijken met een verwachte waarde. De eerste test die ik uitvoerde was op de productieversie van het systeem. Deze versie draaide al maanden en was stabiel. De output van het systeem sloeg ik op als verwachte waarde. Elke keer dat ik een geautomatiseerde test startte werd dezelfde input gebruikt en werd de output vergeleken met de opgeslagen waarden. Strikt genomen controleert een test niet of de output correct is. Maar er werd zo wel een overzicht gegenereerd van de verschillen met de productieversie.

Na de eerste testen kon ik heel eenvoudig de output van de laatste test opslaan als nieuwe verwachting. Zo kon ik deze niet alleen vergelijken met de productieversie, maar ook met voorgaande versies op de testomgeving.

Collega’s betrekken zodat zij beter inzicht krijgen in de testen

Ik presenteerde de output aan de financiële experts en gaf daarbij aan in welke situaties er een verschil was geconstateerd en bij welke de output hetzelfde bleef. De experts waren blij met de gerichte controles en de volgende dag kreeg ik de bevestiging dat output inderdaad correct was. Ik markeerde bij de gecontroleerde testgevallen dat de verwachte waarden nu door de experts bevestigd waren.

Een belangrijke kracht van mijn testtool was het overzicht van de input en output van de testen en de verschillen na het draaien van een test. Dit zorgde ervoor dat mijn collega’s, zowel ontwikkelaars, analisten en gebruikers inzicht kregen in mijn testen. Zo konden zij snel aangeven waar nog testgevallen ontbraken. Na het draaien van de testen kon ik een gerichte lijst met verschillen laten zien. Vervolgens konden zij heel gericht bevestigen of de verschillen inderdaad verklaarbaar en correct waren.

Testen-qquest-test4change

Dagelijkse controles van de testen resulteerde in nieuwe inzichten

Al na de eerste controle draaiden mijn automatische testen dagelijks. Elk verschil in output gaf aan dat er iets was aangepast in het systeem. Samen met de analist en ontwikkelaar besprak ik deze verschillen om te bepalen of er sprake was van regressie in de code.

Het mooie van deze controle is dat ik soms een verschil vond, terwijl er geen wijziging gepland stond. Toen ik de situatie liet controleren door de financiële experts, bleek dat de nieuwe resultaten correct waren! De ontwikkelaar had blijkbaar een situatie verbeterd zonder dat iemand uit het team er zich bewust van was dat het al jaren verkeerd door het systeem werd berekend. Een positieve ontwikkeling dus!

De ontwikkelaar was eerst verbaasd dat ik kon zien dat er wijzigingen waren opgeleverd zonder dat hij mij had geïnformeerd. Later werd hij enthousiast, omdat hij hierdoor vertrouwen kreeg in mijn testen en daarmee ook in de kwaliteit die we als team opleverden. De analist was erg blij dat ik steeds minder van zijn tijd nodig had bij het toevoegen en controleren van testgevallen. Een win-win situatie voor iedereen!

Test4changes-Richard-Scholtes-Qquest

Test4Change

In latere opdrachten heb ik deze aanpak met veel succes toegepast om twee redenen. Ten eerste maak je op deze manier optimaal gebruik van het feit dat je een digitaal systeem direct geautomatiseerd test met een testtool. Daarmee bespaar je kosten en verdwijnt het stoffige gedeelte van het testwerk. Ten tweede zit de kracht van de aanpak in het feit dat je als tester niet hoeft te focussen op de vraag “hoe werkt het” of “werkt het goed?” Je focust namelijk op het feit dat er een wijziging is gedaan in de software en controleert wat de effecten zijn van deze wijziging.

Dus: met Test4Change test ik of er een verandering heeft plaatsgevonden. Of deze verandering overeenkomt met de verwachting, dat is aan de ‘experts’. Met mijn testen creëer ik (nieuwe) inzichten.

Nieuwsgierig of deze aanpak geschikt is om testautomatisering binnen jouw bedrijf een boost te geven? Neem dan vrijblijvend contact met ons op. Ik ga graag het gesprek met je aan om de mogelijkheden te bespreken.

Meer weten over Testen?

Lees alles over waar wij goed in zijn met Testen.

Lees meer

Meer weten over Testen?

Lees alles over waar wij goed in zijn met Testen.

Lees meer

De laatste ontwikkelingen

× WhatsApp!