- 2013/09/01
- 2015/08/06
- Nederlands
- Narrative Geïntegreerd Agile
De Test Ontwerper¶
Als de tester het niet kan testen, kan de bouwer het ook niet bouwen.
Om effectief werkende software op te leveren zijn vaak veel mensen nodig; ieder met zijn eigen specialiteit. Die ook nog eens moeten samenwerken. Bij het invoeren van Geïntegreerd Agile verandert die manier van samenwerken. Mensen kunnen dat als bedreigend ervaren, terwijl dat niet nodig is. Want na enige gewenning is vrijwel iedereen enthousiast: dan heeft het gevoel meer tijd te hebben voor de essentie van hun vak. Al vraagt dat om een zorgvuldige, geslaagde invoering.
Vooral traditionele testers zijn soms angstig dat hun rol verdwijnt. Of dat ze vooral met
technische zaken bezig zijn. Ook omdat sommige collega’s consequent spreken over de technische
tester. Dat is geheel onjuist In mijn visie moet een tester vooral goed zijn in testen! Met name
in het ontwerpen van goede testen.
Laten we daarom eens bestuderen waarom en hoe de testrol verandert. En wat de tester van nu moet
kunnen. We zullen zien dat hij, of zij, vooral goed moet zijn in zijn testvak: goede testen
bedenken.
Samenwerken¶
Eén van de belangrijkste ideeën van het agile manifest is samenwerken. Zoals samen bepalen wat prioriteit krijgt. Want al kiest uiteindelijk de ProductOwner, dat gebeurt pas nadat hij van het team gehoord heeft wat de kosten zijn; dat is dus altijd inclusief de testkosten. Elke tester heeft dus al vanaf dag-nul een belangrijke rol.
Ook moet het team, programmeur en tester samen, er voor zorgen dat elke oplevering werkt. Niet
alleen de nieuwe features, maar ook de bestaande. Regressietesten is dus belangrijk is; zo
belangrijk dat we die term eigenlijk niet meer gebruiken; bijna elke test wordt een regressietest!
De testbaarheid van het ontwerp, de code, en het product zijn dus erg belangrijk. Wederom is hier
een belangrijke rol voor de tester; vanaf dag-nul.
Dit zijn slecht twee voorbeelden van hoe, doordat iedereen moet samenwerken, de rol van de
tester verandert. En waarbij vooral zijn test-expertise belangrijk is.
Bij de agile-tester, gaat het niet om het uitvoeren van de testen, maar om goede testen te
bedenken. Ik spreek dan ook over de test-ontwerper.
Werkende software¶
Een Geïntegreerd Agile team maakt werkende software. Dit klinkt simpel en logisch maar is heel anders dan in traditionele projecten. Vroeger zorgde de opdrachtgever voor een eigen, onafhankelijk testteam. Nu is het de verantwoordelijkheid van het team om te bewijzen dat het werkt! Om deze verantwoordelijkheid in te vullen is test-expertise belangrijk. Want het is ondenkbaar om een stuk software op te leveren dat niet getest is. Als een test niet af is zal een Geïntegreerd Agile team die feature niet opleveren; ongeteste features kunnen nooit af zijn! Al kan daar in overleg met de ProductOwner incidenteel van afgeweken worden.
Maar de rol van de tester gaat veel verder. Werkende software is pas mogelijk als er wensen en
eisen zijn. Maar wat als die niet af zijn? Of niet helder zijn, of zelfs tegenstrijdig? Voor de
gemiddelde programmeur is dat geen groot probleem, hij is creatief en bedenkt wel een
oplossing. Terwijl een tester geschoold is om dit herkennen, zonder kan hij geen test scenario’s
maken. En dus zal hij om opheldering vragen.
In een Geïntegreerd Agile team gebeurt dit ook, meteen op dag-nul. Zodat er alleen software
geschreven wordt die getest kan worden.
Kortom, om werkende software te maken is testen belangrijk. Maar in plaats van achteraf te controleren op fouten helpt de tester om fouten te voorkomen. Dat is niet alleen goedkoper, het is ook logischer. En vooral leuker.
Veelvuldig testen¶
Natuurlijk moet de software ook getest worden; na elke verandering moet gecontroleerd worden of
nieuwe features werken. Maar ook of de bestaande nog steeds werken. Er moet dus steeds meer getest
worden. Want elke sprint worden nieuwe features opgeleverd: voor elke moet minimaal één test
bedacht worden. Bij het ontwerpen van elke test moet hier rekening mee gehouden worden; hij zal
talloze malen uitgevoerd moeten worden. Minimaal eenmaal per (komende) sprint, maar ik de praktijk
veel vaker. Want als de software aan het eind van de sprint moet werken, kunnen we niet wachten tot
op de laatste dag om te testen. Bij elke falende test moet er voldoende tijd zijn om de bug op te
sporen en op te lossen. En om opnieuw te testen; totdat de software fout-vrij is.
Vaak zal het team een groot deel van de testen iedere dag uitvoeren; vaak ’s nachts, automatisch.
Om de grote hoeveelheid tests frequent uit te voeren moet de test(uitvoering) geautomatiseerd zijn (zie ook: Waarom testautomatisering?). Zo’n ATS (Automatisch Test Script) wordt vaak geschreven in Python, iets waar tester soms wat huiverig voor zijn.
Een tester is geen programmeur en dat is ook niet nodig. Met een goed testconcept (en framework,
zoals Pathways) is het schrijven van een ATS niet moeilijk. De meeste
ATSsen zijn minder dan een A4tje lang. En –belangrijker– geschreven als een
test-scenario dat elke tester moet kunnen lezen.
Natuurlijk zijn er altijd een paar complexe ATSsen, of zijn er een paar testers die wat
moeite hebben met het gebruik van Python. Maar omdat ook testen een team-activiteit is, is dat nooit
een probleem: er zijn altijd programmeurs die kunnen helpen.
Elke test –ook een ATS-- moet vooral goed zijn in een ding: testen.
Daarom mag een programmeur helpen om een ATS te schrijven, maar moet een tester bepalen
of de test voldoet. Ook hier staat samenwerken weer centraal: Iedereen moet vooral werken aan de
zaken waar hij goed in is, maar samen zorgen dat alles werkt.
Testen ontwerpen¶
In een Geïntegreerd Agile project is de testuitvoering geautomatiseerd. De tester besteedt zijn tijd dus aan het bedenken van de testen. Grofweg dit deel splitsen in twee delen:
Nadenken over hoeveel en welke testen nodig zijn, en
Dat vastleggen in allerlei documenten.
Ook hier verandert een en ander: de focus verschuift naar het nadenken.
Omdat we het uitvoeren van de testen uitbesteden aan de computer, moet dit eenduidig gebeuren. Dit
resulteert in eerder genoemd ATS; een handvol regels Python. En aangezien we eisen dat
(vrijwel) iedereen die kan lezen, is dat ook voldoende documentatie voor het team. De traditionele,
dikke ‘Word’ test-documenten zijn daarmee overbodig!
Daarmee wordt ook het onderhouden van de testen veel eenvoudiger. Ook omdat we ATSsen
kunnen beheren met hetzelfde versiebeheer-systeem als de programmacode. Als ergens de
functionaliteit verandert, zullen zowel de programmatuur als de bijbehorende ATS(sen)
veranderen. En omdat die samen beheerd worden gaat dat bijna vanzelf goed.
Ook daar is weer een heel klein stukje techniek voor nodig.
Maar dat mag een moderne tester niet afschrikken. Die handvol regels Python, of het gebruiken van
een versiebeheer-systeem leer je zo. De meeste excel verwijzingen zijn complexer!
Sommige zaken kan iedereen. Maar een goede test ontwerpen, daar is echt een expert voor nodig. En
met Geïntegreerd Agile is dat ook een hoofdtaak van de tester.
Disqus
Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.