Auteur: Kees Blokland ● Kees.Blokland@Polteq.com
Redactie: Paul Beving
Hoe ervaar ik de testontwikkelingen van de afgelopen tijd? Die vraag stelde de redactie mij ter inspiratie voor de Kijk van Kees van deze keer. Dus liet ik mijn gedachten de vrije loop.
Test is overal waar software wordt gebouwd.
Het einde der testers is al menigmaal aangekondigd, maar het is net als met de wet van Moore: steeds verschuift het einde toch weer verder naar de toekomst. Dat komt denk ik omdat tijdens het bouwen van software nu eenmaal fouten ontstaan. Daarmee bedoel ik niet per se dat er slechte code wordt geproduceerd, maar vooral: doet het wat nodig is, lost de software het probleem van de klant nu wel goed op? Om dat vast te stellen lever je met testen kwaliteitsinformatie over het product en sluit je daarmee de feedbacklus van het ontwikkelproces. Ik vermoed dat we nog een tijdje software blijven ontwikkelen, dus dan blijft testen ook wel nodig, in één of andere vorm.
De aard van softwarefouten verandert wel
Vijftien jaar geleden deed ik ISEB-practitioner examen, dat onder meer ging over bepaalde soorten fouten die in software kunnen zitten, zoals initialisatiefouten. Moderne IDE’s geven echter direct feedback op de code tijdens het typen van de code. Met kleurtjes, accenten en context ballonnetjes kun je zien wat er mogelijk mis is en kun je veel potentiële fouten in de kiem smoren. We hoeven met testen dus veel minder op zoek naar dit soort sneue softwareconstructiefouten.
Testers moeten/willen meer verstand hebben van programmeren
Ik voel op verschillende manieren de behoefte om meer verstand te krijgen van programmeren. In willekeurige volgorde zijn dat:
- de behoefte om tests te kunnen automatiseren;
- de behoefte om ontwikkelaars te kunnen bijstaan bij unit-testen;
- de behoefte om iets van de software te begrijpen die het team ontwikkelt;
- de behoefte om meer technisch bezig te zijn.
Die laatste geldt voor mezelf, maar de andere drie hebben betrekking op de veranderende rol van de tester in ontwikkelprocessen waarbinnen steeds meer delen van het software bouw- en testproces geautomatiseerd zijn. Hierdoor groeit de behoefte aan testers die meer kennis hebben van softwareconstructie.
Ketentesten blijft lastig
Ketentesten is en blijft complex, zowel organisatorisch als technisch. Bepaalde projectmanagers vinden het daarom overzichtelijk om de ketentest bij een centraal opererend ketentestteam te beleggen. Maar voor een goede aansluiting op agile werken, willen we de verantwoordelijkheid juist decentraal leggen, in de agile-teams. Zij kunnen prima bilateraal hun gezamenlijke integratietesten regelen. Maar zodra ketens over componenten van meer dan twee teams heen gaan, dan moet er toch nog iets extra’s worden georganiseerd. Dan is het de uitdaging om die extra functie klein te houden en te voorkomen dat alsnog een zware centrale ketentestverantwoordelijkheid ontstaat. Organisaties vinden het lastig om gedeelde verantwoordelijkheid te beleggen bij teams die verschillende ‘eindbazen’ hebben.
Tot zover een paar ontwikkelingen die me de afgelopen tijd hebben bezig gehouden. Misschien herken je ze?
De problematiek van ketentesten is heel herkenbaar. Daarom is er in onze organisatie een centrale testafdeling, omdat de meeste ketens over meerdere applicaties (teams) heen gaan en keten elkaar ook kruisen.
We maken nu een draai om volgens SAFe te gaan werken. Ketentesten wordt nu een gezamenlijke activiteit van de agile teams met ondersteuning van testers uit het system team. Die hebben kennis en ervaring van ketenintegratie en end-to-end testen.
We gaan nog ontdekken hoe die samenwerking tussen decentrale agile teams en een centraal system team gaat uitpakken.