Auteur: Matthijs Rolsma

 

Afgelopen woensdag bezochten we het testnet najaarsevent in Nieuwegein. Het thema was Continuous Everything, een verwijzing naar de richting waarin de IT sector zich ontwikkelt. Dit uit zich vooral in steeds korter wordende release cycles van software. Voor het testen betekent dat dit continue gedaan wordt. Immers, bij elke release wil men nog steeds weten of de functionaliteit nog werkt.

Naast onze belangstelling voor de nieuwste ontwikkelingen in ons vakgebied dreef ook een ander gegeven ons naar dit evenement: onze collega’s Erik Bits en Tobias Verhoog stonden op het podium met een allegorie over de overgang van de sequentiële wereld naar agile testing. Zo kregen we de mogelijkheid om vast te stellen of Tobias en Erik de “Ars Dicendi” ook zouden beheersen buiten de veilige contouren van ons 2B4QA kantoor.

Op mijn programma stond workshop waarin ik zou leren een Jenkins pipeline te maken. Jenkins is een platform waarop men aan continuous integration doet, vooral in combinatie met Git. Omdat ik al menig commitje en pull requestje heb gemaakt in Git maar geen idee had hoe dit samenwerkte met Jenkins, leek dit me een goede gelegenheid om daar eens wat inzicht in te verkrijgen. Nadat ik een bak pleur naar binnen had gewerkt om de nodige arbeidsvitamines te verkrijgen begon ik met mijn collega Sonny aan de cursus. Hoewel de cursus interessant was hadden we graag wat meer achtergrondinformatie gehad over de werking van continuous integration. Maar de procedurele kennis die we op hebben gedaan biedt ons voldoende basis om zelf eens een CI / CD pipeline op te zetten.

Na een stevige lunch begon het middagprogramma met een keynotespeaker die de relatie legde tussen het persoonlijke leven en werkleven in een CI / CD omgeving. Af en toe smeet hij daarbij ballen in het publiek waarvoor de reden me tot op de dag van vandaag nog steeds onduidelijk is. Na enkele bakken koffie en nog een presentatie over valkuilen bij de transitie naar continuous development, was eindelijk het moment aangebroken waar we voor komen: de presentatie van Tobias en Erik: “The Wizard of Oz.”

Hoewel ik niet over dezelfde retorische kwaliteiten beschik als Erik en Tobias, doe ik mijn best om de presentatie te omschrijven. Het verhaal voerde ons mee naar het magische “Land of Oz.” Dit verhaal geschiedde in het midwesten van Amerika, in de staat Kansas, waar het “saai vertoeven” was, aldus hoofdpersonage Dorothy (in navertelling door Erik Bits). Op een dag kwam er een tornado die haar huis in het land van Oz neersmeet en daarbij een heks plette. Dorothy ging vervolgens op queeste om de tovernaar te vinden die haar kon helpen om weer terug te komen in Kansas waarbij ze hulp kreeg van enkele sprookjesfiguren. Deze sprookjesfiguren hadden kennelijk allerlei persoonlijke problemen, en hoopten dat de tovenaar die problemen kan oplossen. Na vele avonturen kwamen ze bij de tovenaar aan, die tot verbijstering van de hoofdpersonages een flessentrekker bleek te zijn.

Tobias en Erik gebruikten het verhaal om het tornadomodel te beschrijven. Een model waarbij in het begin van de Agile Tornado er creative destruction onstaat van het oude: in het geval van de IT sector de problemen behorend bij het sequentiële model, zoals bureaucratie, lange time to market en een gebrek aan transparantie. In het geval van the Land of Oz wordt de slechte heks geplet en de gevangenen vrijgelaten. Een tornado zorgt dus voor een hoop ontregeling maar lost tegelijkertijd problemen op.

Hoe groter de tornado, hoe verder je zit op de mate van continuous integration (en agile werken). Wie de flessentrekker was in tornadomodel, is mij nog niet helemaal duidelijk geworden. Wellicht dat dit tijdens een volgende sessie wordt onthuld….

Bedrijfsbezoek Tricentis

Van afgelopen donderdag tot zaterdag zijn we met 2B4QA in Wenen geweest om onze partner Tricentis te bezoeken. Tricentis is de ontwikkelaar van Tosca, een suite voor testcase management, testautomatisering en test reporting. De laatste jaren hebben ze een enorme groei doorgemaakt en wordt er op hoog tempo nieuwe functionaliteit toegevoegd aan de Tosca test suite. Reden voor ons om eens  de banden aan te halen met onze partner.

Een goed begin?

Donderdag vertrokken we naar Wenen. Na enige treinvertragingen vanwege blikseminslagen bleek ook onze vlucht twee uur vertraging te hebben. We waren hierdoor genoodzaakt om wat tijd door te brengen in een authentiek Schiphol etablissement wat ons de gelegenheid bood om te reflecteren op de vraag  waarom het samenreizen van twee niet nader te noemen individuen altijd samenhangt met vertraging.

Na een kort nachtje en een stevig ontbijt voor sommigen werden we hartelijk ontvangen bij Tricentis door Franca en Peter. Franca werkt als implementatie consultant en Peter is director of Alliances van de regio EMEA. Franca trapte de dag af met een presentatie over de mogelijkheden van Tosca. Ze koppelde de theorie van test case design in Tosca aan de praktijkervaring die ze heeft bij klanten. Uit haar ervaring bleek bijvoorbeeld dat het stellen van een korte termijn doel een hogere kwaliteit van risk assessment biedt. Wanneer er te lang over gedaan wordt en alle actoren hun plasje over het gewicht van de requirements moeten doen kan er de neiging tot politieke correctheid ontstaan. Uit de praktijk blijkt dat de risico’s een egaal gewicht wordt toegedicht. Dit voorkomt een zuivere analyse van de risico’s. Franca: ”Political correctness kills the assessment.

Theorie en praktijk

In de praktijk wordt testautomatisering niet optimaal gebruikt om kwaliteit van software te vergroten. De grote beloftes die testautomatiseringstools in de afgelopen decennia hebben gemaakt zijn tot nu toe nog niet waar gemaakt. In het geval van Tosca komt dit voornamelijk omdat er niet goed wordt nagedacht over wat een efficiënte manier is van het bepalen van de testcases. De module testcase design biedt mogelijkheden om op een gestructureerde wijze testcases samen te stellen die gebaseerd zijn op de happy flow door een systeem. De happy flow is het pad door het systeem met de hoogste business value. Over het algemeen is dit een pad dat veel gebruikt wordt en daarmee de kern is van het verdienmodel van de klant.  Met testcase design is men in staat om op basis van deze flow testcases te genereren die steeds één stap afwijken van de happy flow. Als er een testcase faalt, dan weet je precies door welke teststap dit komt.

Demo

Na de presentatie van Franca doken we met Roman van Tricentis in een demo van oude en nieuwe functionaliteiten van Tosca. De mogelijkheden op het gebied van API testing, test case management, testcase design en exploratory testing werden besproken. In exploratory testing is een feature opgenomen waarmee mensen zonder Tosca licentie uitgenodigd kunnen worden voor een testsessie. Zo kan je hun bevindingen integreren in een Tosca test report. Zodoende krijgen stakeholders een volledig, integraal en samenhangend overzicht van de uitgevoerde testen. Daarnaast sprong de API testing feature er voor mij uit omdat het een efficiënte manier biedt om functionaliteit van een applicatie te testen met een hoge performance.

Great expectations

Wolfgang Platz, CEO en founder van Tricentis hield een vurig betoog over de rol van Tosca in de toekomst van testen. Zijn idee is dat er in het algemeen meer nagedacht moet worden over het efficiënt inzetten van middelen zodat je met minder mensen een veel hogere testdekking van applicaties kan realiseren (zie afbeelding) . In de huidige situatie zijn te weinig testen geautomatiseerd, test redundancy (overbodige testen) is veelvoorkomend en testers zitten niet dicht genoeg op het vuur waardoor ze vaak te laat op de hoogte zijn van de ontwikkelingen in hun applicatie. Door in te zetten op goed opgeleide mensen die in staat zijn om Tosca in de volle breedte te gebruiken kan zowel het marktaandeel van Tosca vergroot worden en de inzet van Tosca specialisten bij organisaties. Door grondige kennis van Tosca en van continuous development te hebben gaan Tosca specialisten continuous testing implementeren bij organisaties om zodoende continu inzicht te bieden in de kwaliteit van de opgeleverde software. Hierbij heeft Tricentis een maturity model ontwikkeld dat organisaties helpt bij de overgang naar continuous testing.

Verkennend onderzoek

Naast het opdoen van kennis over testautomatisering hebben we gedurende weekend ook onze exploratory test vaardigheden aangesproken om het recreatie aanbod van de stad Wenen te testen. Alle collega’s van 2B4QA hadden ervoor gekozen om ook de zaterdag met elkaar in Wenen door te brengen. Daarbij hebben we gelet op de kwaliteit van de plaatselijke horeca, de mate van architectonische waarde van bezienswaardigheden, de klantvriendelijkheid van de plaatselijke markkoopmannen. Er kan gemeld worden dat deze cases allen succesvol gerund zijn.

Agile Testen

Door een verschuiving van traditionele watervalmethoden naar een Agile benadering bij softwareontwikkeling, verandert ook de rol van de tester. Waar de watervalmethode gericht is op aparte afdelingen, een rigide blauwdrukplanning en volledige documentatie is Agile gericht op het mengen van expertises, het geven van vertrouwen en het verzorgen van kennisborging bij de teams. Deze ontwikkeling maakt het leven testers interessanter en zorgt ervoor dat testers van alle markten thuis moeten zijn.

Agile betekent letterlijk behendig. Software wordt ontwikkeld in korte perioden die dezelfde structuur hebben. In elke periode (sprint) wordt een werkend deel van de software afgeleverd. Dit wordt incrementeel en iteratief genoemd. Deze manier van ontwikkelen zorgt ervoor dat de business goed in kan spelen op de veranderende wensen van de consumenten en technologische ontwikkelingen.

Testers zijn bij Agile onderdeel geworden van Scrum teams. Dit zijn teams van minimaal drie tot maximaal negen leden bestaande uit een Scrum Master, een product owner en developers. Bij watervalmethoden waren testers ondergebracht in een aparte kwaliteitsafdeling, wat vaak leidde tot communicatieproblemen. Ook vond het testen later in het ontwikkelingsproces plaats waardoor herstelkosten opliepen. Bij Agile wordt er vanaf de eerste sprint getest.

Deze aanpak van ontwikkeling heeft implicaties voor de werkzaamheden van een tester. Ten eerste is de kennis van hoe software gemaakt wordt belangrijk. Voorheen hadden testers over het algemeen beperkte kennis van hoe programmeurs software maakten. Doordat programmeurs en testers bij Scrum in dezelfde teams ondergebracht zijn en dus ook developers worden genoemd, kunnen zij van elkaar leren. De tester leert code, de programmeur leert kritisch testen.

Ten tweede is kennis van businessprocessen voor de tester belangrijk geworden. Doordat de Scrum teams direct gekoppeld zijn aan de business, zal een tester ook verstand moeten hebben van businessprocessen. Zo kan de tester de eisen van een productowner beter begrijpen. De kans dat een product gemaakt wordt waar ook vraag naar is wordt daardoor veel groter.

Ten derde is automatiseringskennis van belang. Omdat Scrum incrementeel van aard is, moeten testers hun testen kunnen automatiseren. Na elke sprint wordt immers een stukje werkende software opgeleverd. Omdat deze software invloed kan hebben op andere delen van het systeem moeten de testen die initieel zijn uitgevoerd herhaald worden. Hier zijn regressietesten voor nodig die een groot deel van het systeem dekken. Het kost teveel tijd om dit handmatig te doen en het is geestdodend.

Samenvattend: De Agile ontwikkelingsfilosofie heeft ertoe geleid dat het werk van een tester interessanter is geworden. Testers worden van begin af aan bij ontwikkeling betrokken als developer. Hierdoor is er naast het uitoefenen van het testvak de kans om wat te leren over programmeren en over de business. Kortom, de tester wordt ook behendig.

Contact

  • Telefoon

    0318 - 240 044

  • Email

    info@2b4qa.nl

  • KVK

    601.397.73

  • Postadres

    Cuneraweg 322
    3911 RT Rhenen

  • Bezoekadres

    Plesmanstraat 59
    Kamer 21
    3905 KZ  Veenendaal

2B4QA BV  (c) 2018