Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Bottleneck bij acceptatie van continuous failure

Boeiend artikel, over dat ‘continuous development’ begint door te breken op de website van Computable. De laatste alinea trok in het bijzonder mijn aandacht, met de kop ‘Testproces blijft de bottleneck’. Dat doet me denken aan vroeger, met waterval en het V-model. Dat je in de laatste dagen van je ‘agile’-sprint nog ‘even’ moet testen. Dan blijkt toch dat we moeite hebben om structureel te investeren in middelen om vroegtijdig inzicht te krijgen in kwaliteit en risico’s. Want testen is een middel, geen doel op zichzelf. Maar wel een middel dat als je het goed en tijdig inzet, helpt om je doel te bereiken.

Waarom beginnen we daar (constateren ook de ondervraagden) nog altijd te laat mee? Al scheelt het wel dat we het nu binnen enkele weken, of met ontwikkelingen als continuous development binnen enkele dagen of uren, als bottleneck gaan zien, in plaats van op het einde van een maanden- of jarenlang project.

Wordt testen nog altijd gezien als iets wat geen waarde toevoegt aan het softwareontwikkelproces? En ervaren we testers met hun rugzak vol methodieken en ervaringen als lastige vragenstellers? Die continu met bevindingen komen die je project, planning en sprint komen verstoren? Die altijd roepen dat ze te laat betrokken worden in het proces waardoor ze moeilijk kunnen leveren en die eerder gemaakte besluiten ter discussie stellen?

Uit ervaring weten we ook dat als we geen ruimte geven/maken aan het zorgvuldig bekijken van de kwaliteit van de oplossing, we vaak in productiesituaties met problemen geconfronteerd worden. Soms nog erger dan het probleem wat je oplost. De (toegevoegde) waarde van je oplossing wordt immers pas echt geleverd als hij van voldoende kwaliteit is.

En ook in agile-omgevingen blijft gewoon een feit: geen bedrijf wil het hoofdonderwerp zijn op nieuwssites en sociale media met een grote verstoring in hun primaire bedrijfsprocessen als gevolg van een fout in het it-landschap.

Kwaliteit vanaf het begin inbouwen

(Copyright: Dan Ashby bij artikel 'continuous-testing-in-devops')

Hoe eerder je ‘andersdenkenden’ (zoals testers) betrekt in het ontwikkelproces hoe eerder je mogelijke problemen kunt voorkomen. Andersdenkenden zijn in dit geval professionals die vanuit risico’s en hun gevoel voor kwaliteit vragen stellen waar anderen niet direct aan denken. De wet van Boehm is nog altijd van toepassing, ook al worden de cycli waarop je feedback krijgt steeds korter. Hoe later je in het proces een bevinding doet, hoe groter de impact is (en daarmee kosten) om deze te herstellen. Tijd en geld dat onder meer ten koste gaat van de snelheid die je wil maken om in deze snelle en continu veranderende wereld mee te blijven gaan. De oplossing is ook in deze moderne tijden nog altijd gelijk aan die van vroeger.

Verwacht van ze dat ze verantwoordelijkheid nemen, betrokken en echt onderdeel zijn. Maak risico’s, het liefst gezamenlijk met het team en stakeholders, inzichtelijk (in plaats van één tester die een product-risico-analyse schrijft). De refining is vaak een geschikt moment hiervoor. Prioriteer samen en ga op basis daarvan werken. Gebruik die vroege inzichten om keuzes te maken. Zo voorkom je dat er fundamentele zaken over het hoofd worden gezien voordat er gestart wordt met het ontwikkelen.

Kies voor kwaliteit

In een wereld van ‘continuous development’ hoort ook een wereld van ‘continuous testing’ om bij elke stap inzicht te genereren of het een stap in de goede richting is. Dat is niet per definitie méér testautomatisering. Dat begint met bepalen wat je wil, waarom je wat wilt en wat die eventuele waarde kan bedreigen. En met dat inzicht zou pas het proces waarbij daadwerkelijk de ontwikkeling plaats vindt moeten starten, waarbij je gedurende het proces continu nog nieuwe inzichten wil gaan opdoen om zoveel mogelijk bevestiging te krijgen dat je nog altijd stappen in de juiste richting zet. En als je begint met de vraag hoe je als team/organisatie gedurende het proces inzicht gaat krijgen of iets goed gebouwd is dan weet je ook direct hoe je de rest van het proces verder kan gaan vormgeven. Om zo bij elke stap de juiste middelen (bv testen) te gaan inzetten.

Gebruik bijvoorbeeld 'riskstorming' om vroegtijdig en gezamenlijk je belangrijkste kwaliteitsattributen te benoemen, bijbehorende risico’s te inventariseren en de eerste stappen te zetten hoe die te mitigeren, of in elk geval inzichtelijk te maken. Daar zie je vaak al dat er andere keuzes gemaakt worden omwille van de kwaliteit. En dat er een gemeenschappelijke basis ligt voor een (test)plan om gedurende het project structureel het inzicht te geven wat je nodig hebt of je op de goede weg zit met de benoemde risico’s die je belangrijkste kwaliteitsattributen bedreigen.

Een ding is daarbij glashelder: Zonder de juiste (test)expertise aan boord blijkt vaak dat men achteraf constateert dat men in een eerder stadium essentiële inzichten heeft gemist. Inzichten waarmee men vaak een andere keuze gemaakt zou hebben ten behoeve van de kwaliteit van de oplossing.

Ide Koops, test expert bij KZA

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Wat ik jammer vind van dit soort betogen is dat er een oplossing(srichting) aangedragen wordt zonder te kijken wat het probleem nu eigenlijk is. Want waarom is het testproces eigenlijk een bottleneck?

Is het een gebrek aan kennis en inzicht in de hedendaagse testmethodieken, of zijn er andere redenen?

In bijvoorbeeld de embedded wereld komt het voor dat hardware, elektronica en software in parallel ontwikkeld worden. Met unit-testen en emulators kun je je software een heel eind vooraf testen, maar de echte integratie en end-to-end testen zullen pas aan het einde plaatsvinden. Daarnaast kan het zo zijn dat het ontwikkelen en onderhouden van de emulatoren dusdanig complex en daarmee kostbaar is, dat de kosten niet opwegen tegen de baten.

In het verlengde hiervan maakt het ook nog een verschil of je serieproductie of klantspecifieke systemen maakt. Er zijn bedrijven die een klantspecifiek systeem in-house helemaal opbouwen, aftesten, en dan weer uit elkaar halen en verschepen. Een behoorlijk kostbare aangelegendheid maar je kunt in ieder geval nog testen voordat je het naar de klant uitlevert.
Is dit niet mogelijk, dan zal een deel van het testen pas na oplevering bij de klant plaats kunnen vinden.Je kunt dan uiteraard zoveel mogelijk vooraf proberen te testen middels emulaties en modellen, maar er zullen altijd een aantal situaties zijn die je niet vooraf kunt testen.

Kortom, een uitspraak als "testproces blijft de bottleneck" behoeft mijns inziens wat meer nuancering alvorens met en conclusies en adviezen aan gaat verbinden

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-06-11T08:35:00.000Z Ide Koops
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.