Het is tijd voor Testen3.0

In het derde jaar na het uitbrengen van het boek “Testen2.0” is het logischerwijs tijd voor Testen3.0! Waar in 2.0 bewust de focus werd gelegd op de Agile mindset en de achtergronden van de Agile methodieken, is 3.0 meer concreet gericht op implementatie in projecten.

Regelmatig zullen we op deze blog updates van onze vernieuwde en uitgebreide visie plaatsen.

In één plaatje staan de belangrijkste testactiviteiten die het multidisciplinaire team doet om kwalitatief hoogwaardige software te realiseren:Een overzicht van Testen3.0
Niet functioneel testen

In principe horen alle testsoorten binnen de iteratie te worden uitgevoerd, teneinde de feedback lus zo kort mogelijk te houden. Dat geldt dus ook voor testen van kwaliteitsattributen zoals performance en security. Richt daartoe één of meer aparte testomgevingen in, welke niet gebruikt worden voor de functionele testen. De praktijk leert overigens dat in bijna alle gevallen er veel meer waarde gehecht wordt aan informele metingen dan aan ‘exacte metingen’ op basis van gecontroleerde omgevingen en de bijbehorende (dure) tools. Een programmeur heeft namelijk genoeg aan indicatieve metingen en trends voor het aanbrengen van correcties. Een beheerafdeling wil vooral bewezen zien dat de performance niet meer dan lineair achteruit gaat.

Het is belangrijk om deze testen van kwaliteitsattributen op de juiste plaats uit te zetten in de tijd. Een eventuele correctie kan namelijk heel duur zijn, omdat het vaak niet zozeer de code is die wordt aangepast, als wel de onderliggende architectuur. Richt daarom in ieder project een zogenaamd Proof of Concept in, waarop de metingen van de gekozen kwaliteitsattributen vroegtijdig kan plaatsvinden.

Sowieso is het wenselijk dat er sprake is van een doelgerichte architectuur, waarbij de testbaarheid van het geheel in het achterhoofd wordt gehouden. Een goed gebruik is bijvoorbeeld de separation of concerns; dit houdt in dat afgebakende onderdelen (vaak: lagen) in een applicatie zich met verschillende zaken bezighouden. Als bijvoorbeeld de bedrijfsregels deels verstopt zitten in de database, dan is het waarschijnlijk moeilijk om als team het overzicht te behouden, en te bepalen hoe een wijziging getest moet worden.

Zijn er heel veel kritische onderdelen, in de zin dat er bijna iedere iteratie nieuwe onderdelen bijkomen die getest moeten worden op bijvoorbeeld performance, dan zal het Proof of Concept geen uitsluitsel geven. Richt in dat geval de testen zodanig in, dat deze binnen de iteratie kunnen worden uitgevoerd. Kies bewust voor een beperkte ‘levensduur’ van het merendeel van de testen, omdat het beheer ervan in latere iteraties kostbaar zal zijn. Selecteer aan het einde van iteratie slechts een deel van de testen om aan te houden als onderdeel van de regressie suite.

Voor sommige testen is het heel moeilijk om deze in te passen in de Agile procescyclus. Denk daarbij bijvoorbeeld aan het testen met ketenpartners, die er zelf een andere release cyclus op na houden. Dan is het belangrijk om goede afspraken te maken over het testen van de interfaces. Voor de eigen ontwikkeling is het prima om het merendeel van de testen binnen de iteratie uit te voeren tegen stubs. Voorafgaande aan het ‘live’ gaan van een product zal men de test met zo min mogelijk stubs willen uitvoeren. Die testuitvoering alsmede eventuele herstelwerkzaamheden zitten per definitie op het kritieke pad; vroeg testen moet dit tot een minimum beperken.

Over ericjimmink

Eric Jimmink is een testconsultant met een achtergrond als ontwikkelaar / meewerkend voorman. Zijn eerste agile project was al in 2001. Eric geniet bekendheid als co-auteur van het boek 'Testen2.0', als schrijver van artikelen over agile testen, en door het geven van presentaties. Momenteel is Eric bezig met 'Testen3.0', waarvan enkele fragmenten geplaatst worden op de AgileOrdina blog.
Dit bericht werd geplaatst in Agile Testen, Implementatie van agile, Testen3.0 en getagged met , , , , , , , , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

2 reacties op Het is tijd voor Testen3.0

  1. Gerard zegt:

    Het plaatje doet sterk denken aan de testing quadrants zoals Lisa Crispin in haar boek Agile Testing beschrijft.

    Is het hier van een afgeleide? Zo ja, waarom dan de andere weergave en waarom het loslaten van assen van de testing quadrants?

    (voor meer info: )

    (en onder de button ‘reactie plaatsen’ staan twee buttons, met beide hetzelfde doel volgens mij🙂 )

  2. ankotijman zegt:

    Hi Gerard,

    We hebben echt ‘outside in’ gedacht: wat verbindt de elementen in het testen in agile projecten. We vonden dat een verdieping t.o.v. Testen2.0 noodzakelijk was omdat we daar niet specifiek inzoomen op de “orde” van testactiviteiten binnen de iteratie. Dus in een aantal iteraties zijn Eric en ik tot deze orde gekomen. Wij kennen uiteraard het boek en het gedachtegoed van Lisa en Janet, maar hebben -eerlijk is eerlijk- geen moment dat model als uitgangspunt genomen. Dan moet het dus wel dicht bij de waarheid liggen😉
    Overigens: het model an sich komt van Brian Marick’s blog.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s