Het heeft even geduurd maar het is mij gelukt. Sinds april dit jaar heb ik een gedroomde testopdracht: testmanager voor een nieuw op te zetten internetbroker. Mijn motivatie is groot: hier wil ik bij zijn en ik wil een goed resultaat.
Complex
Het project zelf is behoorlijk complex: effectenhandel is ingewikkelde materie. Het gaat een compleet nieuw systeem worden, met veel klanten, veel gebruikers, en nog meer leveranciers, systemen en interfaces. Bovendien kreeg ik al snel te horen dat tijd en geld flink aan banden lagen. En alsof dat nog niet genoeg was: de klant wilde bovendien met de beschikbare mensen testen. Vooral met business analisten! En dat heeft natuurlijk zijn nadelen. Dat weet iedereen. Oeff.., hoe pak ik dit nu aan? Wat kun je eigenlijk doen in zo’n situatie?
Kiezen
Dit wordt testen met beperkte middelen. Kan niet missen. Ook dacht ik: is dit niet ‘Lean’? Wordt dit niet vooral keuzen maken en de onnodige dingen weglaten?! En wat laat ik dan weg? Of kan ik het omdraaien? Wat moet ik vooral wel doen? Moet ik niet alleen dingen maken die door vrijwel iedereen gebruikt gaan worden: liefst door alle disciplines. Ik weet uit ervaring dat een compact testrapport dat wordt gebruikt door zowel analisten, bouwers, projectleiders èn natuurlijk klanten, goud waard is. Iedereen gebruikt dan dezelfde informatie en dat maakt communiceren wel een stuk eenvoudiger.
Workshoppen
Terug naar mijn werkelijkheid. Ik heb er voorlopig voor gekozen om geen teststrategie of testplannen in Word-document op te leveren. In plaats daarvan geef ik vooral korte workshops. De beoogde testers zijn ervaren IT mensen: business analisten hebben aan een paar woorden genoeg: ze weten hoe de business in elkaar steekt. Testgevallen maken valt hen niet zwaar. En dat is wel mooi meegenomen. Maar ik ben er natuurlijk nog lang niet. Hoe zorg ik ervoor dat alle testen ook gaan draaien straks? Hoe krijg ik overzicht en waar vind ik structuur? Op welk doel moet ik me richten?
Het moment
Om mijzelf en anderen hiermee te helpen heb ik een terugkerend thema bedacht, waarbij ik de volgende vraag centraal stel: hoe krijgen we straks de best en snelst mogelijke afhandeling van onze bevindingen? Voor mij ligt daar altijd hét moment van de waarheid. Daar moet alles samenkomen! Zeker met zo’n complexe keten van systemen. Daar zal blijken of de organisatie klopt en of iedereen zijn werk heeft gedaan en kan doen. Nu maar zien hoe dit gaat verlopen.
————————————————————–
Dirk van Dael is testconsultant bij Capgemini
Dirk,
Is jezelf deze vraag centraal stellen niet een hele dure grap? Hoe krijgen we straks de best en snelst mogelijke afhandeling van onze bevindingen?
Moet je niet veel meer bij iedereen de mindset tussen de oren krijgen hoe voorkomen en detecteren we zo vroeg als mogelijk de zaken die tot bevindingen kunnen leiden?
Hoi Dirk, Wat zijn dan de nadelen wanneer je de business analisten laat testen…?
@Andreas
Terechte opmerkingen. Laat mij proberen hierop te antwoorden.
Mijn insteek bij testen is altijd de best mogelijke testen te doen binnen de gegeven de context. Dat is in dit geval niet anders. Ik wil het maximale doen om gereed te zijn voor de testen die gaan komen.
Zo moet je mijn ‘rode draad’ en bijhorende vraag ook zien. In mijn workshops loop ik de verschillende onderdelen af: strategie, planning, documentatie, testdekking etc. En wil dan telkens weten hoe we ervoor staan en of we klaar zijn.
Vooral daarvoor gebruik ik graag dat moment van die eerste bevindingen, want die zullen er zijn. Ik stel de vraag ook zo: Wat als de bevindingen nu binnenkomen? Wat moet er nog komen?
Wat nu al gebeurt is dat we voor alle onderdelen van het systeem en voor de (test)documenten eigenaren, prioriteiten etc. vastleggen. En dat biedt al de nodige houvast.
@Anko
Wat zijn de nadelen van met business analisten testen..? Ja mooie vraag. Die kon ik natuurlijk van Mr. Agile verwachten.
Voorop gesteld: er gaat weinig boven testen samen met de andere disciplines. Dat is meestal heel leerzaam en kan geweldig goed uitpakken in een project (denk aan complementariteit).
Maar waar je vooral voor moet waken met business analisten is dat zij hun eigen werk gaan testen. En dat speelt in mijn geval omdat er helaas weinig andere mogelijkheden zijn.
Bovendien geldt dat business analisten behoorlijk eigengereid kunnen zijn, zeker als het hun eigen werk betreft. En ik heb liever geen bedrijfsblindheid. Het is juist de natuur van testers om buiten de gebaande paden te gaan.
Wat ook kan spelen is dat business analisten vaak moeilijk te porren zijn voor het fijne werk: het opstellen van fysieke testgevallen.
Maar wat ik al aangaf: je krijgt er wel veel kennis en content voor terug.
Wat ik zelf momenteel doe is werken met een ‘peer testing’ aanpak . Zo worden de testonderdelen door twee mensen bezet en beoordeeld.
Groet, Dirk
Niks op papier zetten, bespaar enorm veel werk. Vaak genoeg heb ik gemerkt dat er tientallen dagen verloren gaan aan het maken van dingen zoals een master test plan dat vervolgens niet meer wordt geactualiseerd nadat het is aangemaakt. Dan heb je aan een Powerpoint-presentatie van vijf slides evenveel als aan statisch MTP van 50 pagina’s.
De afhandeling van bevindingen is slechts gedeeltelijk gelinkt aan hoe goed dat processen verlopen. Het zijn mensen die projecten dragen en dus ook de snelheid (of het gebrek eraan) van bevindingenbehandelingen bepalen. Zelf sta ik dan iedere dag wel minstens één keer aan de bureau van de tester, analyst, project manager, … om hier de vaart in te houden. Het werkt in ieder geval een stuk effectiever dan mailen en telefoneren.
Dirk
Heb je Exploratory test charters al eens goed toegepast. Past binnen agile en waterval prima.
Je kunt er ook heel goed houvast mee creëren en goed profiteren van de business analisten.