Agile

Ik weet wel wanneer ik wil weten dat mijn shuttle naar Mars van zijn koers afwijkt. Namelijk nu direct. Of anders zo snel mogelijk. Zelfs het allerbest samenwerkende team is namelijk kansloos zonder Fast Feedback. Daarbij maakt het niet uit of je software maakt of naar Mars reist. Op het moment dat er ergens een foutje optreedt, wil je het weten. Dan is bijsturen nog mogelijk en zinvol. Zonder snelle feedback zal je niet merken dat je je koers verlaat. En als je reist met de snelheid van het licht, zit je voor je het doorhebt in een naburig zonnestelsel.

Het bekendste voorbeeld van Fast Feedback in een software-ontwikkeltraject is testautomatisering. Door testautomatisering goed in te richten, stelt een team zichzelf in staat om razendsnel de gewenste feedback op een softwareaanpassing te krijgen, en afwijkingen in een zo vroeg mogelijk stadium te onderkennen. Goede testautomatisering blinkt niet alleen uit door zijn snelheid, maar is ook robuust en goed onderhoudbaar.

Doordat snelle feedback meer en meer als een teamverantwoordelijkheid wordt gezien, zien we dat de tester steeds minder vaak de rol van test automatiseerder bekleedt. Test automatiseringscode is immers programmacode, en in een Quality Infected Team wordt die code met productiekwaliteit geschreven door ontwikkelaars.

De tester maakt twee bewegingen om de snelle feedback-loops met zoveel mogelijk waarde te laden. Enerzijds zien we de ‘shift-left’, waar de tester maximaal waarde toevoegt door het team samen te brengen rondom de testuitdagingen die we op proberen te lossen. Hierbij worden onder andere technieken als Specification by Example en Impact Mapping gebruikt om het gezamenlijke begrip binnen een team te maximaliseren en daarmee de kans op fouten te reduceren. Anderzijds zien we de tester een ‘shift-right’ maken: de ultieme feedback op een systeem is immers feedback van échte gebruikers in productie. Tijdens het bouwen van software kan al nagedacht worden over indicatoren die in productie weergeven of het systeem gebruikt wordt zoals verwacht. Net zoals de shuttle naar Mars: als we het systeem niet gebruiken zoals bedoeld, willen we het zo snel mogelijk weten, ook als we daadwerkelijk airborne zijn.

Het streven naar Fast Feedback op alles wat er gebeurt, is de tweede eigenschap van een Quality Infected Team. De tester pakt de rol van Feedback Engineer en maakt een shift-left én een shift-right ten opzichte van zijn klassieke rol.

170222 – Quality Infect Teams – praatplaat

Benieuwd naar het vervolg op deze blog? Lees dan deel 4 over Exploration.

Schrijf je in voor
de nieuwsbrief

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Delivery Pipelines

Mei21

Steeds meer organisaties willen gebruik maken van delivery pipelines, waarbij software geautomatiseerd naar omgevingen gedeployd wordt. Hoe voorkom je dat de delivery pipeline een heel efficiënte manier wordt om fouten naar productie te brengen? Hoe zorg je ervoor dat je nog steeds de juiste risico’s afdekt? Hoe zorg je ervoor dat je je team en de omliggende organisatie meeneemt in de totstandkoming van de delivery pipeline? Hoe krijg je de gewenste feedback?

Tijdens deze Bijtanken bij Bartosz sessie belichten we de verschillende aspecten van een delivery pipeline. We lichten toe welke rol we als testers kunnen spelen in het proces van de totstandkoming van een kwalitatief goede delivery pipeline. Hiervoor is het niet alleen van belang om software efficiënt en effectief naar volgende omgevingen te deployen, maar ook om stakeholders en het acceptatieproces hierin mee te nemen.

Mijn Paarsz