EN
NL

The Future of Testing

Welcome to Quality Insights

Klantwaarde leveren zonder IT is in deze tijd geen optie meer: IT is voor bijna alle organisaties onderdeel van de business geworden. Kwalitatief goede software is een randvoorwaarde om (blijvend) optimaal klantwaarde te kunnen leveren. Kwaliteit en adaptief vermogen worden steeds belangrijker om je als organisatie te onderscheiden en om klanten te behouden. Dit betekent ook dat er steeds hogere eisen worden gesteld aan de snelheid en kwaliteit van het software engineering proces. Zowel bij de ontwikkeling van nieuwe software als bij het onderhoud van bestaande IT-systemen. Testen is een geïntegreerd onderdeel van het totale ontwikkelproces om inzicht te verkrijgen in die kwaliteit.

Onze visie is niet voor niks:

"IT is a fast and flexible enabler of customer value"

Klanten worden zich ook steeds meer bewust dat software hun leven en bedrijf beheerst en ook kan bedreigen. Software moet veilig, snel, aanpasbaar en gebruikersvriendelijk zijn en altijd net een stap beter als die van de concurrent.

Hoe denken wij bij De Agile Testers dat we een bijdrage kunnen leveren aan deze uitdaging? Met alleen meer testen kunnen we dit niet oplossen.

Dit brengt ons tot onze purpose. Wat willen wij als droombeeld van de toekomst betekenen? Wat is onze bijdrage aan de visie, ons hogere doel. Voor ons is dat:

"Reinventing Software Testing"

Vanuit onze visie en purpose streven we een concreet haalbaar doel na. Onze eerste missie, op weg naar de purpose is:

"Setting the standard in Agile Testing"

In dit stuk beschrijven we onze kijk op deze uitdaging:

  • Wat zijn de ontwikkelingen rondom testen en kwaliteit in de nabije toekomst
  • Wat is onze visie op testen en kwaliteit voor de langere termijn?

 

Ontwikkelingen in de nabije toekomst

Er ontstaat een groeiend bewustzijn dat testen meer is dan alleen het door een tester laten checken of het ontwikkelde systeem is gebouwd conform de specificaties. Hiermee heb je onvoldoende inzicht in de kwaliteit en risico’s die gelopen worden. Middels het alleen checken van de feiten (specificaties) ontbreekt inzicht in 3 van de 4 onderstaande gebieden waarin je inzicht wilt krijgen. De known knowns ofwel facts; de feiten c.q. specificaties. De known unknowns ofwel questions; de zaken waarvan we weten dat we ze nog niet weten en waardoor we middels het stellen van vragen proberen inzicht te krijgen. De unknown knows ofwel intuition; de zaken waarvan we instinctief aanvoelen dat er iets niet klopt. En tenslotte de unknown unknowns ofwel exploration; dat waar we geen inzicht in hebben en die we middels onderzoek nader moeten onderzoeken.

Inzicht in alle 4 de gebieden heb je nodig om een weloverwogen en geïnformeerde beslissing te kunnen nemen of het product verantwoord kan worden uitgeleverd naar klanten.

Testautomatisering speelt een steeds belangrijkere rol in de systeemontwikkeling. Dit is een ontwikkeling die verder door zal zetten. Er is ook een groeiend bewustzijn dat testautomatisering alleen de ‘knowns’ kan controleren en dat we daarmee weliswaar het controleren van ‘facts’ kunnen versnellen en verbeteren, maar dat daarmee de noodzaak om ook de ‘unknowns’ inzichtelijk te maken niet verdwenen is.

 

De belangrijkste rollen/taken van een tester zullen zijn:

  • Het team helpen, middels training, mentoring en coaching, om te denken vanuit risico’s en kwaliteit van start tot einde, bijvoorbeeld door risico sessies te organiseren en afspraken te maken met het team om de kwaliteit optimaal te kunnen borgen (quality built-in), maar ook presentaties over b.v. biases, teamdynamiek en veranderingen.
  • Helpen om inzicht te houden in de knowns, bijvoorbeeld door samen met het team tot een set geautomatiseerde unit testen te komen
  • Inzicht geven in een wereld vol complexiteit, verwarring en halve waarheden (de unknowns), bijvoorbeeld door het stellen van kritische vragen, inzicht te geven in project, product en risico’s, en het onderzoeken van de software (exploratory testing). Context-driven testers zijn in staat de uitdagingen van testen in een software ontwikkeltraject te onderkennen en aan te pakken. De reden hiervoor is eenvoudig: context-driven testen brengt testers de vaardigheden bij die nodig zijn om het testwerk aan te laten sluiten bij het project. Context-driven testen begint met het kijken naar de noden van de klant in relatie tot het product, het team en de organisatie. Vanuit de klantvraag wordt gekeken naar mogelijke oplossingen die kunnen bijdragen aan het invullen van die noden; starten bij de nood in plaats van de oplossing (tool of werkwijze). Door het ontwikkelen en inzetten van eerdergenoemde vaardigheden ondersteunt deze wijze van testen op een effectieve manier de softwareontwikkeling. Testers zijn sneller inzetbaar omdat ze minder afhankelijk zijn van documentatie. Ze werken efficienter omdat ze geen onnodige documentatie produceren. Ze zijn beter in staat software te doorgronden en daardoor bij te dragen aan een goede oplossing. Ze voegen waarde toe aan een team.

 

Veranderende vaardigheden

Deze nieuwe rol/taken vereisen ook een andere set aan skills dan die in het verleden op de rol van tester werden geplakt. Door Agile en DevOps verandert het werk van een tester.

Om teamleden testvaardigheden bij te brengen is het van belang om zelf excellente testvaardigheden te hebben. Mentoring/Coaching skills zijn een steeds belangrijkere vaardigheid om teams mee te nemen kwaliteitsbewustzijn tijdens de hele Software Development Life Cycle (SDLC).

Daarnaast moeten testers ook de techniek begrijpen om de technische zwaktes van software bloot te kunnen leggen en het helpt tevens in de communicatie met de technisch georiënteerde teamleden.

Zie de achtergrondinformatie voor een detaillering van de vaardigheden van een moderne tester.

 

Onze visie voor de langere termijn

Onze missie is:

"Reinventing Software Testing"

Dit willen we op de langere termijn gaan invullen door een groeiend kwaliteitsbewustzijn te laten ontstaan op een aantal vlakken:

  • De rol van de knowns en unknowns zal gemeengoed worden
    • Voor de ‘knowns’ geldt dat er een verregaande automatisering zal zijn van deze testen waarbij we wellicht geholpen gaan worden met slimmere tooling(al denken wij niet dat echte AI hierin de komende 5 jaar een belangrijke rol zal gaan spelen, omdat deze techniek nog lang niet zover is). Tevens zullen deze testen in een verregaande geautomatiseerde delivery pipeline zijn opgenomen.
    • Voor de ‘unknowns’ geldt dat deze niet te automatiseren zijn, simpelweg omdat we ze nog niet weten. Dit blijft toch vooral het domein van een teamlid met testvaardigheden.
  • Het aspect van coaching/mentoring/training van het team in kwaliteitsdenken wordt groter en belangrijker. Je kunt kwaliteit nu eenmaal niet erin testen. Testen geeft primair alleen inzicht in die kwaliteit. Kwaliteit wordt gevormd door het kwaliteitsbewustzijn van alle teamleden en door de processen en technieken die in de hele SDLC worden toegepast. Hiervoor is het van groot belang dat we onze kennis hierover ook delen en overdragen naar het hele team.
  • Testen ontwikkelt zich van Quality Assurance naar Quality Insights; testen biedt geen zekerheden, dat heeft het ook nooit gedaan. Testen biedt inzicht:
    • Inzicht in de status van een product op enig moment in tijd.
    • Inzicht in potentiële waarde.
    • Inzicht in potentiële schade.
  • Potentiële schade zal een meer prominente rol gaan spelen. We hebben als mensen last van naïef constructivisme; we willen graag mooie nieuwe dingen maken om onze klanten blij te maken. We verliezen hierbij bijna altijd uit het oog dat ieder stukje potentiële waarde ook een stukje potentiële schade in zich heeft, of we zijn genegen te denken dat de kans dat deze schade ook echt zich zal manifesteren toch enorm klein is (denk hierbij aan de kernramp bij Fukushima). De tester (al is dat wellicht niet meer de meest dekkende naam voor de rol) zal een cultuurverandering moeten gaan inleiden waarin we als team bij elke goed idee ook gaan nadenken welke potentiële rampen/nachtmerries dit idee tot gevolg kan hebben.

 

Veranderende vaardigheden voor een tester op de langere termijn

Teamleden met testvaardigheden kunnen en moeten toegevoegde waarde leveren door zich verder te ontwikkelen op een aantal vlakken om het team en het product naar een volgend level te helpen brengen. Hierin spelen people-skills zoals training van teamleden, onderhandelen, biases en leiderschap een rol, maar ook kritische exploratory test-skills, visualisatie en een switch van risico-denken naar het denken in potentiële schade. Ook zal een teamlid met testvaardigheden meer moeten weten van verandervaardigheden om het team mee te kunnen nemen in de veranderende wereld. Hiervoor zijn ook coaching en mentoring skills een noodzaak.

Daarnaast is een bredere kijk op teams (b.v. team topologies) en op de hele SDLC nodig. Tenslotte is een dieper begrip op technisch vlak nodig van zowel de software als het totale software delivery proces, omdat iedere stap een potentieel risico in zich heeft.

Zie de achtergrondinformatie voor een detaillering van de vaardigheden van de tester op de langere termijn.

 

Achtergrondinformatie

Iedereen is gelijk, maar niet iedereen is hetzelfde

Teamleden zijn allemaal individuen en ieder individu is anders. Als voorbeeld zijn testers meestal een ander persoonstype dan developers. Een team kan pas een echt goed team zijn als er een mix is van de verschillende persoonlijkheidstypen en als de meeste teamleden zich ook bewust zijn dat deze verschillen er zijn. Een van de modellen is de Myers-Briggs type indicator voor verschillende persoonlijkheidstypen.

 

Developers zitten vaak in het linker-bovenkwadrant (IS) en testers voornamelijk rechtsonder (EN). Dit past ook volledig bij de rol en taken die zij in een team uitvoeren. Het is van wezenlijk belang dat teamleden het werk doen dat bij ze past en dat ze ook leuk vinden. Je kunt alleen een hele goede developer of tester zijn als dat ook echt je passie is. Mensen excelleren in hetgeen ze leuk vinden, en andersom. Een top-ontwikkelaar is slechts zeer zelden een top-tester en een top-tester is zeer zelden een top-ontwikkelaar. En gezien de complexiteit van de vakgebieden kun je niet tegelijkertijd een top-testspecialist en een top-ontwikkelspecialist zijn.

 

Wat zijn de vaardigheden van een moderne tester?

Een moderne Agile tester bezit de volgende skills:

  • People skills: een moderne tester is onderdeel van het team en helpt het team en de software naar het best mogelijke niveau. Om dit te kunnen doen beschikt de tester over skills zoals:
    • Het stellen van kritische vragen
    • Het geven en ontvangen van feedback
    • Kritisch kunnen denken
    • Met begrijpen van biases en de gevaren die dit met zich meeneemt
    • Onderhandelingen kunnen voeren
    • Coaching en Mentoring skills om het team te kunnen meenemen
    • Bewustzijn over persoonlijkheidstypes in een team en hier het optimale uit kunnen halen (zie achtergrondinformatie)
  • Agile skills: een agile tester beheerst en leeft Agile (at scale), Scrum, DevOps, CI/CD als mindset. Als agile tester kun je je aanpak feilloos afstemmen op de klant en de behoefte.
  • Testing skills: agile vergt naast al bekende testtechnieken ook test-skills die passen bij altijd accuraat inzicht in de status van het product. Denk hierbij bijvoorbeeld aan:
    • Exploratory testing
    • Behaviour Driven Development
    • Context Driven testing
    • Agile Risk Assessments en Bughunts en de bijbehorende tools zoals Riskstorm, Bowtie en de Nightmare Headline Game.
  • Technology skills: daarnaast heeft een agile tester kennis van de techniek; code lezen en begrijpen, automatische testen opzetten en schrijven. Daarbij heeft hij/zij kennis van actuele tools die hierbij relevant zijn zoals ReadyAPI, Cucumber. JUnit/Xunit, Specflow, Fitnesse etc. etc. Maar denk daarnaast ook aan versiebeheer tools, CI/CD tools en Cloud tools.

 

Veranderende vaardigheden voor een tester op de langere termijn

Teamleden met testvaardigheden kunnen en moeten toegevoegde waarde leveren door zich verder te ontwikkelen op een aantal vlakken:

  • People skills
    • Leiderschap: een tester is in de eerste plaats een teamlid. Om succesvol in een team te kunnen opereren, moet je als lid kennis hebben van psychologische veiligheid, aansprakelijkheid en verantwoordelijkheid. Als je deze kennis hebt, kun je je team helpen groeien.
    • Onderhandelen: onderhandelen is een middel waarmee je kan krijgen wat je nodig hebt zodra je met een medemens te maken hebt. Op basis van de unieke positie in een agile team waarin een tester zich bevindt, heeft hij of zij vaak een grote behoefte om haar of zijn perspectief begrepen, en de benodigde vereisten om de klus te klaren, te krijgen. Daarom is het essentieel om soepele onderhandelingen te kunnen voeren om te krijgen wat nodig is en om de relatie met het team en de belanghebbenden buiten het team gezond te houden.
    • Biases: ‘Without the aid of prejudice and custom, I should not be able to find my way across the room’ en ‘Prejudice is the child of ignorance’. Zonder onze vooroordelen zou ons leven onmogelijk zijn om te leven. Maar vooroordelen bedriegen ons ook zonder het te merken of mensen kunnen onze vooroordelen in hun voordeel gebruiken. Het erkennen, herkennen en toepassen van biases is een essentieel onderdeel van testen omdat een tester zich niet moet laten leiden door deze biases om een goed inzicht te kunnen geven in de status van een product.
  • Test-skills
    • Kritische exploratory test-skills: het testen van de ‘knowns’ zal voor 90-95% geautomatiseerd zijn. Dan blijven er echter nog 3 interessante gebieden over:
      • Unknown knowns; hiervoor moet je vragen stellen zodat het known knowns worden. Typisch een eigenschap van een kritische denker, een onderzoeker, een tester
      • Known unknowns; hiervoor moet je de ervaring en de intuïtie hebben die je leiden naar de onbekende problemen
      • Unknown unknows; dit vereist een onderzoekende geest, focus en de-focus, een kritische houding, altijd vragen naar ‘what if’ en een creatieve geest om te komen tot ‘horror stories’

Deze 3 gebieden blijven het domein van het testen en vereisen mensen die deze skills beheersen.

Een voorbeeld: 

 

Je ontwerpt een geruisloze elektrische auto die van 0-100-0 in 3 seconden kan en een top van 300 heeft.

Wat zou je kunnen testen:

      • Lukt het echt in 3 seconden, van 0 naar 100 en weer terug naar 0?
      • Maakt hij inderdaad geen geluid?

Wat zou een kritische geest nog meer kunnen bedenken?

      • Hoeveel mensen gaan er overlijden omdat de auto om een boom gekruld wordt of een overstekend hert tegenkomt?
      • Hoeveel mensen gaan er overlijden omdat ze worden aangereden omdat ze de auto niet horen of zien aankomen?
      • Wat is eigenlijk de (klant)waarde van deze specificatie?
      • Hoe lang zouden de remmen en de banden meegaan?
      • Waar kun je eigenlijk 300 rijden?
      • Hoe lang gaat die accu mee als je 300 rijdt? Red je het volgende oplaadpunt wel?
      • Wat gebeurt er als ik de auto re-boot als hij rijdt?
      • Is de zelf-rijden functie ook actief bij 300?
      • Enz enz.

 

  • Een andere kijk op dat wat ten grondslag ligt aan het testen: risico. Risico is een dubbelzinnig begrip. Het vormt de kern van testen, terwijl we vaak geen duidelijk beeld hebben van wat het is. En nog belangrijker, het concept ‘risico’ is een mogelijke bias die kan leiden tot onvoorziene rampen. Daarom moeten we risico vervangen door een nieuw, veel breder concept: ‘potentiële schade’. Dit geeft een meer totaalbeeld(zie onderstaand plaatje en voor een nadere toelichting en detaillering kijk hier(hoofdstuk 2)) van alles wat de waarde van software bedreigt en tevens een manier om met deze schade om te gaan, opgesplitst in bekende schade (schade die we van tevoren kunnen bedenken) en onbekende schade (onvoorziene schade). De traditionele Risico Analyses wordt vervangen door:
    • Een potential damage assessment (PDA) is een activiteit waarin een concrete, praktische, gestructureerde invulling wordt gegeven aan ‘knowns’ (dat wat we op voorhand kunnen bedenken). Het gevaar, de gebeurtenissen die het gevaar kunnen triggeren, de bedreigingen, de consequenties en preventieve en herstel acties worden gedefinieerd evenals eventuele escalatie factoren. Die doen we aan de hand van DRAFT
      • Determine
      • Resolve
      • Arrange
      • Forestall
      • Track
    • Om ook om te kunnen gaan met de ‘unknowns’ maken we gebruik van BARE SPACE
      • Keep track of the Big picture
      • Hold standards for Accountability and psychological safety
      • Put effort in Redundancy of vital elements
      • Evolve aggressively (this is, learn aggressively)
      • Situational Awareness
      • Preoccupation with failure
      • Add enough depth
      • Commit to resilience
      • Esteem for experts
    • Daarnaast zijn exploratie (om zoveel mogelijk feedbackloops te creëren), systeemdenken (met verschillende lenzen naar een project of product kijken) en modelleren (gebruik modellen, tekeningen, andere visualisaties) generieke manieren om nieuwe en informatieve inzichten te krijgen.

Figuur 1: Potential Damage overzicht

 

  • Agile skills
    • Verandermanagement: om echt agile te kunnen werken is het implementeren van een proces niet voldoende. Teamleden moeten worden meegenomen in een verandering van mindset. Testers moeten in staat zijn om teamleden mee te nemen in deze gedragsverandering. Zonder de agile en kwaliteit mindset kunnen teams niet excelleren en zal de kwaliteit van de software achter blijven. We onderscheiden 3 soorten van ‘coaching’:
      • Agile teaching; teamleden vertellen hoe het werkt.
      • Agile mentoring; teamleden helpen met behulp van je eigen ervaringen.
      • Agile coaching; teamleden helpen door ze zelf tot inzichten te laten komen.
    • Een bredere blik op de hele SDLC en hierin kunnen adviseren: om kwaliteit te kunnen brengen is testen alleen niet genoeg. Kwaliteit begint bij de start van de SDLC en stopt ook niet bij het in productie nemen van software. Testers moeten overzicht hebben van de SDLC en kunnen bepalen op welke plekken ze optimalisaties moeten (laten) doorvoeren om een betere kwaliteit product te krijgen. Dit kan zijn middels:
      • Shift Left; verbeteren van de ‘Think it’ fase b.v. door invoering van BDD-SBE.
      • Shift right; verbeteren van de ‘Run it’ fase b.v. door actieve monitoring.
      • Quality Built-In; verbeteren van de ‘Build it’ fase b.v. door een geautomatiseerde delivery pipeline.
    • Complexere modellen kunnen invoeren om teams optimaal te laten samenwerken.
      • Veel organisaties ervaren spanning tussen de ambitie om sneller en flexibeler waarde te leveren voor hun klanten en de bestaande inrichting van systemen en hun teams. De vraag waarmee deze organisaties worstelen komt in de kern hier op neer: hoe organiseren we een effectieve en efficiënte samenwerking tussen de teams die verantwoordelijk zijn voor onze systemen? Team Topologiesbiedt een theoretisch framework dat herkenbare pijnpunten in organisaties kadert én biedt concrete handvatten om met deze vraag aan de slag te gaan. Vier typen teams en drie vormen van interactie tussen deze teams worden als oplossing geboden tegen cognitieve overbelasting, contra-klantgerichte architecturen en afstemmingsproblemen tussen teams. Voor testers is het in de toekomst van belang te begrijpen hoe dit framework in elkaar steekt om daarmee in staat te zijn de klant meer agile te laten werken (people- en agile skills), om organisatorische problemen die risico’s in de software veroorzaken te herkennen en te adresseren in de testset (test skills), om de gekozen architectuur te toetsen op klantgerichtheid (technology skills) en om de interactie tussen de verschillende teams als input voor risico inschatting te gebruiken (test- en technology skills).

 

  • Technology skills
    • Risico’s kunnen aangeven rondom technical debt; hoewel technical debt natuurlijk vooral een issue is dat door de developers moet worden voorkomen en opgelost, bedreigt het de kwaliteit van een product. Daarmee is het een ‘potential damage’ en zal een tester hierin inzicht moeten kunnen geven. Methoden hiervoor zijn o.a. statische code checkers voor o.a. de code zelf, voor security en performance specifiek of voor usability. De tester dient het bestaan te kennen en ervoor te zorgen dat deze tools ook gebruikt (gaan) worden omdat ze nodig zijn om de meest essentiële technical debt inzichtelijk te maken.
    • Een testautomation strategy kunnen neerzetten die perfect aansluit op de bestaande technische omgeving
      • Aangeven wat de voor-, maar ook nadelen zijn van testautomatisering
      • Zelfstandig kunnen opzetten van een onderhoudbaar testautomatiseringsframework
      • Inzicht hebben in de mogelijkheden van de diverse testautomatiseringsframeworken.
      • Begrijpen hoe testautomatisering past binnen de Software Delivery Life Cycle
      • Begrijpen hoe testautomatisering past binnen gedefinieerde development modellen en/of architectuur
      • Adviseren over de juiste tools voor een organisatie
    • Snel kunnen inwerken in alle mogelijke testtools; er zijn veel tools, maar de meesten zijn gebaseerd op dezelfde principes. Een tester dient kennis en ervaring te hebben met een breed scala aan tools zodat hij deze kan inzetten waar nodig en nuttig.
    • Een breder begrip en kennis van tools uit de SDLC is nodig omdat kwaliteit niet alleen bepaald wordt door de code van de software, maar ook door zaken daar omheen zoals een geautomatiseerd CI en CD proces en een goede versioning en versioning strategie.

Alain Bultink | Directeur
alain@deagiletesters.nl
06-15361077

Carlo van Driel | Directeur
carlo@deagiletesters.nl
06-12913682

Theo Janssen | Business Development
theo@deagiletesters.nl
06-15022781