Volgens het Global Center for Digital Business Transformations zijn er verschillende branches die versnellen door de digitalisering (digitale vortex). Daarom zouden bedrijven dus sneller in moeten spelen op trends en ontwikkelingen in de markt. Hierdoor zouden deze bedrijven dus sneller en vaker software moeten opleveren (time to market moet omlaag)
1. Hoe ervaren jullie dit aangezien jullie in de XXX branche zitten?
2. Ervaren jullie dat de time to market bij jullie verkort moet worden, maar daarnaast ook dat de kwaliteit van de software omhoog moet?
Nu is het bekend dat, door de software te testen, bugs en fouten uit het product gehaald te kunnen worden en daardoor dus de kwaliteit omhooggaat.
3. In hoeverre komt handmatig testen bij jullie voor?
4. Wat doen jullie om de kwaliteit van jullie software hoog te houden?
Door testen te automatiseren zou dit proces kunnen worden ingekort. Hierdoor wordt de time to market dus verlaagd, en de kwaliteit verbeterd.
5. Hoe denken jullie over testautomatisering? (is het nuttig/ zinloos/ tijdverspilling o.i.d.) 6. Waar staan jullie op gebied van testautomatisering?
7. Welke tests zijn nog niet geautomatiseerd?
8. Waarom zijn deze tests nog niet geautomatiseerd?
9. Waar willen jullie naartoe?
10. Wat doen jullie eraan om de volgende stap te zetten op gebied van testautomatisering?
Nu zou deze kennis op verschillende manieren in huis gehaald kunnen worden.
a. (consultancy eerste keuze) Wat verwachten jullie dan van zo’n consultancy traject?
Waar letten jullie op, wat vinden jullie belangrijk?
b. (consultancy niet eerste keuze) Waarom is consultancy niet jullie eerste keuze om jullie hierbij te helpen?
11. Als consultancy niet de eerste keuze was, waarom dan niet?
12. Nou wij zijn dus bezig met het opzetten van zo een dienst. Maar zou 90 dagen dan een goede looptijd zijn hiervoor in jullie ogen?
13. Na mijn uitleg over hoe wij deze dienst in willen richten en waar wij op willen focussen, zouden jullie hierin geïnteresseerd zijn?
14. Op basis van de toelichting van de dienst die wij willen opzetten, zijn er dan nog vraagtekens die bij u opkomen of punten waar wij nog op moeten letten?
111
Bijlage J Resultaten interviews problem validation
Verbatims
Interview Maarten Dirkse
SP1
Uhm, nou onze consultants zien het probleem bij klanten. Zij willen testen gaan automatiseren want het duurt allemaal te lang enz. Maar ze hebben zelf niet de kennis in huis om daarmee te beginnen of om daarmee te starten. Dan zijn er eigenlijk drie mogelijkheden om de kennis in huis te halen: Volgen van trainingen, het hele testen te outsourcen op een of andere manier of door middel van consulting of consultancy. Nu is het probleem bij outsourcing dat je best wel, je bent afhankelijk van de externe partij SP2 Ja klopt
SP1
Wat ook weer tijd kan, ja, kan kwijtraken. Met trainingen, ja weet je iemand volgt die training, het is laagdrempilig en kosten zijn over het algemeen laag maar of het
geïmplementeerd wordt, dat is een tweede. En consulting is voor, vaak voor bedrijven, uit mijn onderzoek, een beetje spannend. Bijvoorbeeld dat ze bang zijn dat ze een beetje afhankelijk worden of daarnaast bang voor de instelling uurtje factuurtje, dat soort dingen
SP2 Ja klopt
SP1
Dus het idee is nu om een pakket als dienst aan te bieden voor testautomatisering dat bestaat dan, sorry. In een vaste tijd dus na die looptijd is het traject ook echt klaar. 90 dagen is nu de gangterm. Of in ieder geval het idee. De eerste twee weken assessment dan komen er een aantal developers uit India die nemen het team eigenlijk een soort van over. Die gaan testen schrijven samen met het team. Dan de laatste drie/vier weken, ik weet niet precies de tijd, wordt dit werk steeds meer over gedragen aan het team zodat aan het einde van de looptijd het bedrijf zelf verder kan.
SP2 Ja duidelijk
SP1
Dus het is eigenlijk een combinatie van consulting, training en outsourcing. Dat is het idee. Daarom ook dit interview, de problemen die ik als eerste heb beschreven, is dat ook het probleem wat de klant ervaart. Is het echt het probleem dat ook in de markt speelt, dus eigenlijk de validatie daarvan. Dat is de reden van dit interview. Dus kloppen de aannames die ik heb gedaan zodat wij zo verder te kunnen gaan met het bouwen van een MVP Minimum Viable Product. Duidelijk?
SP2 Ja hoor, ja.
SP1
Uit een van mijn bronnen, digital business vortex, daar staat in dat er een aantal branches zijn die steeds meer moeten verstellen op digitalisatie en steeds sneller moeten gaan schakelen op veranderingen in de markt. Onder andere E-commerce, en daardoor moet die time to market omlaag. Dat is volgens die bron. Maar ervaar jij dat ook binnen bol.com?
112 SP2
Ja, zeker. Wat ik dus net zei dat is wel waar. 30% groei los van wat we verder doen.
Maar het is zeker zo dat als je de. Oke. Waar het om gaat is inventaris, je hebt een voorraad. We zijn een E-commerce bedrijf, we verkopen spullen maar de truc is om de hoeveelheid spullen die we op een gegeven moment op voorraad hebben, om die zo laag mogelijk te houden. Want als je die twee, idealiter heb je zeg maar niks op voorraad en heb je alles niet uit voorraad want dan kost het je minder geld.
SP1 Dan heb je dus eigenlijk de optimale ijzeren voorraad.
SP2
Precies. Dus we besteden super veel geld aan om dat te optimaliseren om zeg maar precies genoeg voorraad hebben omdat het niet te veel geld kost. Maar hetzelfde geldt voor software. Als jij software schrijft en je moet vervolgens zes weken wachten tot het gereleased wordt naar productie, dan is dat eigenlijk een software voorraad die je hebt opgebouwd die op de plank ligt en geen waarde genereerd voor je klanten. Dus wat je wil is dat er, tussen het moment van het opleveren van de software en dat het
daadwerkelijk waarde gaat genereren voor je klanten, dat dat zo kort mogelijk wordt.
En niet alleen is dat goed voor je bedrijf omdat je dan geen software voorraad hebt, maar het is ook goed voor je werknemers want die zien wat ik vandaag gemaakt heb beland gelijk in productie of beland dezelfde dag in productie en wordt gebruikt door klanten en we kunnen gelijk zien oh dat was een slecht idee want het levert minder omzet op, of het was een uitstekend idee want het levert heel veel omzet op zeg maar.
Dus je wil zo snel mogelijk naar productie omdat je het idee zo snel mogelijk wilt testen. Als het goed is moet je ook zo snel mogelijk in staat zijn om aan te passen en iets anders te doen. En daarvoor is heel veel snelheid nodig. Dus het antwoord is ja SP1 Klopt het dan ook, nou die snelheid moet omhoog maar geldt dat dan ook voor de
kwaliteit van de software? Die combinatie daarvan.
SP2 Ja dus die twee dingen gaan hand in hand. Je kan wel heel snel releasen, maar als je crap released dan heb je er niks aan. Dus die twee dingen gaan hand in hand.
SP1 Oke, nouja het is vrij duidelijk, sowieso voor jou, het is bekend dat testen, daar gaat je kwaliteit van omhoog. Van je software. Om die bugs en die fouten eruit te halen.
SP2 Ja, uhm, ja ja
SP1 Of in ieder geval om die boven water te halen SP2 Ja, Heb je het over automatische tests?
SP1
Nee nog niet, daar kom ik zo op. Dit is, oke wacht. Mijn vraag is dan ook, hoeveel komt dat handmatig testen nog voor bij jullie.
SP2 Uhm, dat komt nog wel voor maar nog wel heel weinig.
SP1 Op welke gebieden?
SP2 Het is vooral de UI dingen, dingen die lastig te automatiseren zijn.
SP1 Visueel dan?
SP2
Ja, maar we hebben. Vier jaar geleden zijn we met een heel, zijn we met een initiatief gestart om alle testen die we deden, toen werd er heel veel handmatig getest, om dat allemaal te automatiseren. Maar er zijn nog een aantal dingen zoals alle flows in de webshop die nog met de hand worden getest
SP1 Waarom, waarom zijn die dan niet meegenomen
113 SP2
Ja die zijn gewoon niet geautomatiseerd. We hebben eigenlijk iets gedaan, wat jij, wat min of meer in jij nu voorstelt. We hebben een stel consultants ingehuurd die samen met ons de tests zijn gaan schrijven en toen, het idee was dat als zij klaar waren (dat was geen 90 dagen, dat was een jaar ofzo) als ze klaar waren dat wij dan zelf verder zouden kunnen. Maar dat ging niet helemaal goed zeg maar, toen zij weg waren, waren er nog een aantal mensen die geen idee hadden van wat ze ermee moesten.
SP1 Dus dan die overdracht dat is dan..
SP2 Die overdracht is niet in alle gevallen even goed gegaan. Maar, dus heel weinig dat nog met de hand wordt gedaan, maar er is nog wel wat.
SP1 En dat zijn dus dan de dingen, het is niet de reden dat het niet te automatiseren valt voor een deel maar omdat het domweg niet gebeurd is in het verleden.
SP2
Ja, er zijn nog maar heel weinig dingen die echt niet, waar de toegevoegde waarde dusdanig laag is dat je het echt zou willen automatiseren. Die zijn er bijna niet eigenlijk.
Maar we hebben het over automatische tests. Dus tests die draaien op het moment dat je een commit doet, dan draaien die tests zeg maar. Dus er is een school binnen IT die zegt van dat zijn helemaal geen tests, het zijn checks. Testen is echt zitten achter een product en gaan klikken, kijken of je het stuk kan maken. Terwijl wat je schrijft zijn checks die verifiëren dat iets nog zo werkt als het zou moeten
SP1 Dus eigenlijk dat Test Driven Development eigenlijk SP2 Precies. Dus dat is weer een beetje een dingetje
SP1
Dat is ook eigenlijk wel een beetje de volgende vraag die ik wil stellen. Van hoe sta jij in het, tegenover testautomatisering? Hoe denk je erover, vind je het nuttig of (zoals je nu zegt) het is een hele andere mindset als je daar echt mee aan de haal wilt gaan.
SP2
Je moet, als je die snelheid wil bereiken dan moet je met enige zekerheid wijzigingen kunnen doen. En die zekerheid die ontleen je aan de set van geautomatiseerde tests of checks die, voor elke code change die je doet, verifiëren of bepaalde dingen blijven werken. En dat is, dat zal nooit 100% dekkend zijn, dat heeft ook helemaal geen zin om dat 100% dekkend te maken. Maar die test suite die je hebt gebouwd die geeft jou een bepaalde mate van zekerheid. Dat als jij een code change doorvoert en je test suite die slaagt, dan heb je veel meer vertrouwen van datgene dat je naar productie brengt dan als je 0,0 tests zou hebben. Dan zouden triviale dingen stuk kunnen zijn zonder dat je dat door hebt bij wijze van spreken. Dus ja, dat is noodzakelijk als je een basis wilt hebben om heel veel snelheid te maken, moet je dus bepaalde zekerheid hebben over de veranderingen die je doet. En zo'n automatische test suite die is daar natuurlijk bij SP1 Ja oke, duidelijk. Als je nu op een schaal van 1 tot 100, is denk ik makkelijker in jullie
geval, hoeveel % is nou wel geautomatiseerd qua..
SP2 Goede vraag
SP1 Naja je noemde het net al, we hebben eigenlijk niet echt een testomgeving
SP2 Ja die hebben we nog wel hoor. Er zijn nog teams die daar gebruik van maken. Maar hoeveel er geautomatiseerd is zou ik eigenlijk niet durven zeggen,
SP1 Meerendeel?
114 SP2
Als het goed is zouden we ruim boven de 80 90% moeten liggen. Ja er zijn nog heel weinig teams die met de hand uhm… Aan de mobile kant zit nog wel, mensen die een nieuwe versie van iets dat ook op mobile getest moet worden, dus ook op
verschillende devices
SP1 En is dat omdat zij niet voldoende kennis hebben om dat wel te doen, of hebben ze bepaalde redenen waarom ze het niet doen, of…
SP2
Ja we zijn ooit zo begonnen en toen hebben we, en misschien is het ook al lang niet meer zo hoor dat zou ook kunnen, maar ze hebben enorm lang lopen mutsen om dat te automatiseren en daar is uiteindelijk nooit een knoop over doorgehakt. Dus volgens mij doen ze het gewoon zoals ze het vroeger ook deden.
SP1 Maar die zijn voor jouw kennen, zijn die wel te automatiseren?
SP2
Ja, ja tuurlijk, die zijn allemaal te automatiseren. Ik bedoel dat, dat kan gewoon, laat ik het zo zeggen.
SP1 En waar ligt dat aan dat dat nog niet is gebeurd. Is het: we willen gewoon door gaan met produceren, of?
SP2 Ja
SP1 Dus waarschijnlijk een stukje management overtuigen?
SP2 Nee, ja nog nooit echt de moeite genomen om het echt goed te automatiseren SP1 En wat ook net werd genoemd, daar krijgen, dus als IT kant krijgen we daar geen tijd
voor. Is dat dan het geval?
SP2 Weet ik niet, ik denk dat het te maken heeft met de mensen die het doen niet echt, SP1 Niet uit hun hokje willen kijken
SP2 Ja zo is het nou eenmaal en we hebben daar ook niet al te veel moeite mee.
SP1 Oke
SP2 En we hebben daar blijkbaar nog geen enorme negatieve impact op de snelheid SP1 Maar dan krijg je misschien weer iets als met de IPhone van joh je weet nu nog niet dat
je dit wil.
SP2 Precies
SP1 Dat is een beetje wat ik eruit ophaal toch?
SP2 Ja zeker, ja.
SP1
Oke, nou dit hebben we eigenlijk allemaal al gehad. Ja wat. Stel je wordt nu Team Lead of Product Owner, ik weet niet precies wat jullie interne termen daarvoor zijn, maar jij bepaalt wij willen dit gaan doen. Wat is dan jouw eerste stap om
SP2 We willen dat gaan doen
SP1 Ja hoe wil je dat gaan doen en hoe zou je dan die kennis in huis willen halen. Zou dat dan intern zijn,
SP2 Testautomatisering bedoel je?
SP1 Ja
115 SP2
Oh zo, uhm, het is een beetje de, als ik wil test automatiseren, dan laat ik dat niet doen door mijn testers maar door mijn developers. Of ik zorg dat die testers wat meer developers worden, dus ik zou niet zo snel geneigd zijn om dan van buiten mensen in te huren omdat ik dan. Omdat het gewoon onderdeel zou moeten zijn van het normale development zeg maar. Dat moet erin gebakken worden en die test suite die in eerste instantie op te bouwen, dat hoeft niet in een keer big bang, oke nu hebben we een test suite en we kunnen weer door. Dat kan ook geleidelijk aan gebeuren zeg maar. Dus ik denk dat ik dat, als er nog helemaal niks zou zijn en we moeten ermee beginnen, dat ik dan de developers de, dat ik dan tegen de developers zeg van vanaf nu worden er ook automatische tests geschreven en ik wil graag een basis hebben waarmee we verder kunnen, waarmee we met zekerheid naar productie kunnen. En die moeten we dus nu gaan bouwen. Om het dan zo te doen zeg maar.
SP1 En, om dan het stapje terug te maken naar de POE (het idee dat we in de markt willen zetten), waarom zou je dan dus niet kiezen voor consulting?
SP2
Ja ik denk, ik denk dat ik niet zou kiezen voor een consultant omdat ik graag zou willen dat developers dat zelf doen. En dat bootstrappen met consultants, dan heb je toch altijd dat, dan wordt er iets neergezet, en dat is door andere mensen gemaakt, dat is vaak met het team dan zo. En dan hebben developers al snel het idee dat is hun code, wij hebben dat niet gedaan dus. Maar ja, dat vereist wel dat je developers hebt die goed zijn en die bereid zijn om dat te doen. Die het nut ervan inzien enzo, het is niet overal zo bij wijze van spreken dus. Als ik het zou moeten doen dan zou ik het zo oplossen. Maar ik denk wel dat er zat bedrijven zijn voor wie de consulting aanpak misschien beter zou zijn. Dan binnen 90 dagen inderdaad iets neerzetten en, als je dan de overdracht goed regelt, wel van toegevoegde waarde is.
SP1
Oke, nou dat is dan ook het volgende antwoord. Ja, dit is dan eigenlijk op die 90 dagen wat ik dan net noemde. Het eerste idee was dan dat dit dan twee weken assessment, en de rest het schrijven van testen en het overdragen aan het team omdat het een kwartaal is wat voor bedrijven als het goed is een hele fijne tijd zou zijn. Hoe sta jij daarin, denk je dat dat te kort is, en ook aangezien jouw ervaring
SP2 Dat ligt eraan, wat de omvang is van de opdracht SP1 Dus of het een team is..
SP2 Bij ons was het te kort geweest, maar bij kleinere bedrijven zou dat wel goed moeten komen
SP1 Ja, want het idee is niet om die 90 dagen voor het hele bedrijf, maar om één of misschien twee teams daaruit te pikken. Zou dat beter aansluiten?
SP2 Ja dat zou zeker moeten lukken. Denk dat twee weken assessment misschien nog aan de lange kant is.
SP1 Oke
SP2 En je gaat er dus vanuit dat er nog niks is, er is nog helemaal niks zeg maar?
SP1 Uhm
SP2 Is dat reëel? Zijn er nog veel bedrijven die dat hebben?
116 SP1
Nee sorry, dan heb ik dat misschien verkeerd uitgelegd. Dat was inderdaad de eerste insteek, waar ik in het begin ook wel tegen aanliep, maar wat we nu willen doen is om
"de volgende stap te zetten". Dit is namelijk om de volgende reden; ik heb een
assessment gedaan op de (DevOn) Summit om te inventariseren hoe ver bedrijven zijn met testautomatisering. Heel veel bedrijven geven aan dat ze ongeveer 30 tot 40% van de testen die zijn geautomatiseerd. En hoe kan je de stap zetten om naar de 60 te gaan. Dat is eigenlijk de insteek, en we zien allebei niet waarom dit niet zou lukken in
assessment gedaan op de (DevOn) Summit om te inventariseren hoe ver bedrijven zijn met testautomatisering. Heel veel bedrijven geven aan dat ze ongeveer 30 tot 40% van de testen die zijn geautomatiseerd. En hoe kan je de stap zetten om naar de 60 te gaan. Dat is eigenlijk de insteek, en we zien allebei niet waarom dit niet zou lukken in