Dennis Geluk

Als analist werk je in projecten samen met collega’s die verschillende taken en verantwoordelijkheden hebben. Een goede onderlinge samenwerking en communicatie is dan cruciaal om op een efficiënte manier tot een passende (software)oplossing te komen.

Dit artikel is de tweede van een reeks publicaties waarin we als analisten praktische tips delen om efficiënt met verschillende andere rollen in een project samen te werken. In dit artikel staat de samenwerking tussen analist en tester centraal.

De analist verzamelt WAT de wensen van de business zijn, structureert deze en legt ze begrijpelijk vast. De tester valideert DAT de software deze wensen vervult. Deze samenwerking zorgt voor een gevalideerde (software)oplossing die waarde geeft voor de business.

In dit artikel delen we praktische tips waarmee analisten de samenwerking met testers voor, tijdens en aan het eind van een sprint uit Scrum kunnen optimaliseren. Uiteraard gelden de onderliggende principes ook voor andere ontwikkelmethoden.

1.      Tips voor de voorbereiding van de sprint

Tijdens de voorbereiding van een sprint zorgt de analist ervoor dat de stories aan de bovenkant van de product backlog voldoende niveau hebben zodat het Scrum team, inclusief tester, de omvang kan schatten.

Het is de rol van de analist om in de voorbereiding al goed na te denken over de acceptatiecriteria van iedere story / requirement. Wanneer is iets nou echt af? Wanneer voldoen we als team nu eigenlijk aan de specifieke wensen van de stakeholder(s). De acceptatiecriteria moeten zorgen voor een zo scherp mogelijke afbakening van de story. Het is de rol van de tester om alvast na te denken hoe gevalideerd kan worden dat ook echt aan deze acceptatiecriteria kan worden voldaan. Door in een vroeg stadium te valideren of acceptatiecriteria echt testbaar zijn voorkomen we een hoop discussie in het vervolg. Het zal ook de eerste keer niet zijn dat tijdens de refinement de tester missende alternatieven aandraagt of bestaande acceptatiecriteria helpt aan te scherpen.

Bij teams die werken op basis van Specification by Example (SBE),  Test-Driven Development (TDD) of Behaviour Driven development (BDD) principes zijn acceptatiecriteria vaak de basis voor geautomatiseerde testgevallen. Hierbij is de rol van de tester in combinatie met de ontwikkelaar zeer belangrijk om tot zo scherp mogelijke testgevallen te komen.

Praktische tips voor de analist

Wil je als analist de sprint optimaal (efficiënt, en zonder waste) voorbereiden? Dan kunnen deze tips je zeker helpen:

• Voorzie iedere story altijd van acceptatiecriteria die ook echt testbaar zijn. Acceptatiecriteria als bijvoorbeeld: “de gebruikersvriendelijkheid gaat omhoog” kunnen lastig te valideren zijn.
• De wijze van opschrijven kan helpen bij het automatiseren van testgevallen (zie ook ons artikel over de samenwerking tussen analist en ontwikkelaar).
• Laat je story voor refinement alvast even toetsen door de tester.
• Voorzie complexe flows van een activity diagram. Een activity diagram gaat de tester helpen om snel en simpel tot de diverse testgevallen te komen.

2.      Tips voor tijdens de sprint

Tijdens de sprint vult de analist samen met het team de verdere details van een story in. De analist kan de tester helpen met de opstellen van de testgevallen. De tester helpt de analist met het signaleren van onduidelijke requirements of niet-testbare requirements.

Praktische tips voor de analist

• Betrek de tester bij het opstellen van de requirements. Een tester kijkt veelal op een andere wijze naar de requirements en kan de analist echt helpen om de zaken scherp op te schrijven.
• Bied altijd aan om de testgevallen te reviewen. Door te kijken naar de validatie scenario’s van de door jou opgeschreven requirements kun je direct valideren of de testen compleet zijn, je requirements niet ambigue zijn en of je wellicht geen requirements vergeten bent.
• Leg relaties tussen requirements en testgevallen. Probeer samen met je tester een manier te vinden om requirements daadwerkelijk te koppelen met testgevallen. Dit kan middels tooling maar veelal helpt een naamgevingsconventie ook al om snel te kunnen wisselen tussen testgevallen en bijbehorende requirements.
• Als je bestaande documentatie bijwerkt, maak de wijzigingen dan inzichtelijk voor de tester en zorg voor goed versiebeheer. DiVetro heeft werkende oplossingen voor onder meer Enterprise Architect.
• Het is verleidelijk om testcondities die de tester gebruikt vast te leggen in de specificaties, maar daarvoor zijn betere alternatieven. Een mooi voorbeeld zijn bijvoorbeeld foutmeldingen. Het requirement is veelal dat het systeem een foutmelding zal geven; de specifieke tekst van de melding moet uiteraard logisch zijn maar zal in 9 van de 10 gevallen niet als “hard” acceptatiecriterium gelden. Probeer samen met het team te komen tot een situatie die voor iedereen werkbaar is. In het geval van foutmeldingen zou een tabel met teksten voor meldingen met een link naar specifieke documentatie wellicht al voldoende kunnen zijn.
• Vergeet niet het gewenste gedrag voor foutsituaties te beschrijven. Sluitende acceptatiecriteria beschrijven niet alleen wat het systeem moet doen als alles goed gaat maar ook wat het systeem moet doen als zaken anders lopen dan gehoopt.

3.      Tips aan het einde van de sprint

Tijdens de sprint review zal het team de resultaten van de sprint aan de stakeholders tonen. Niets is storender voor stakeholders dan een review waarin onrealistische scenario’s worden gebruikt. Het gebruik van onrealistische testdata leidt de stakeholder dan af van de daadwerkelijke werking. Het kan ook een onrealistisch beeld geven van de applicatie. Stem daarom altijd met de tester af welke set testdata gebruikt zal worden tijdens de demo. Vanuit je expertise als analist kun jij goede realistische scenario’s beschrijven. De tester kan op zijn beurt deze scenario’s omzetten naar een goede consistente set van testdata.

Conclusie

Binnen een IT-project werken een analist en tester nauw samen om te zorgen dat de door het team ontwikkelde oplossing aansluit bij de gestelde eisen. Daarbij is de analist leidend in het WAT en de tester in valideren DAT het ook echt zo werkt. Onderlinge kruisbestuiving is essentieel. Een open en actieve samenwerking zal altijd leiden tot een beter resultaat!

In dit artikel gaven we praktische tips waarmee analisten de samenwerking met testers voor, tijdens en aan het eind van een sprint uit Scrum kunnen optimaliseren. Uiteraard gelden de onderliggende principes ook voor andere ontwikkelmethoden.

Meer informatie

DiVetro heeft veel ervaring met de (optimalisatie van de) interactie tussen analisten en testers in Scrum en andere projectvormen. Heeft u hier vragen over? Wij vertellen u graag hoe u de samenwerking tussen analisten en testers in uw organisatie kunt structureren en verbeteren.

Neem contact met ons op