Kwaliteit was belangrijk, is belangrijk en zal altijd belangrijk blijven. Een open deur die we gebruiken om onze goede intenties ten opzichte van kwaliteit te uiten. Maar hoe we dat concreet maken en handvatten en inhoud geven, blijft een uitdaging, ook binnen de it. Elke ontwikkelmethode of procesmodel dat gekozen wordt, geeft aandacht aan kwaliteit. Een pijler is het testen.
Binnen waterval was het duidelijk: er zijn opeenvolgende fasen en elke fase had één of meerdere rollen die daarin de belangrijkste activiteiten uitvoeren. Denk aan ontwerp door een business-analist, bouwen door een ontwikkelaar, testen door een tester en uiteindelijk het releasen door de release-manager. Het was duidelijk wie waarvoor verantwoordelijk was. Bij de overgang naar agile is dat onduidelijker geworden. Alle activiteiten zijn op één hoop gegooid en het team als geheel is verantwoordelijk voor de berg aan activiteiten.
Dit brengt uitdagingen aan het licht. Het begint met de rol die iedereen heeft binnen het team: iedereen is developer. Door de semantiek van dit woord lijkt het of opeens iedereen in het team een programmeur is, want een developer is toch een ontwikkelaar en dat is toch een programmeur?
Waar het hier om gaat, is dat het hele team verantwoordelijk is voor ontwikkeling en dat betekent alle aspecten daarvan. Softwareontwikkeling is een deelgebied van de informatica dat zich bezighoudt met alle aspecten van het bouwen van complexe maar betrouwbare software tot informatiesystemen. Het is een vakgebied dat zich bezighoudt met methodes om een vraag of probleem in de werkelijkheid om te zetten naar een computerprogramma.
Belangrijke zinsnede hierin is ‘alle aspecten’. Dus nadrukkelijk niet alleen programmeren. Het daadwerkelijk programmeren beslaat slechts dertig tot vijftig procent van de tijd. Wat gebeurt er dan de rest van de tijd? Dit is tijd voor ontwerpen, testen en releasen. Dus ook al heet iedereen ‘developer’, de andere activiteiten zullen nog steeds uitgevoerd moeten worden en nemen samen een groter deel van ontwikkeling dan programmeren in beslag.
Binnen het team zal daarom een verdeling van de activiteiten moeten plaatsvinden, zowel naar tijd, activiteiten als personen. Er zal nog steeds een tester nodig zijn of in elk geval iemand met kennis van en ervaring met testen en kwaliteit. Deze persoon of personen zullen moeten definiëren wat er binnen een agile team nodig is aan activiteiten die bijdragen aan de gewenste kwaliteit van de op te leveren producten en diensten. En er zal nog steeds bepaald moeten worden hoeveel tijd dit gaat kosten. Testen en kwaliteit zijn een essentieel onderdeel van agile werken.
Semantiek van het woord
De volgende uitdaging zit in de de verdergaande vraag naar automatisering binnen agile en devops. Ook hier zit de semantiek van het woord developer in de weg. Iedereen is developer en dus kunnen we alles automatiseren.
Om dit te ondersteunen, worden er pipelines gebouwd. Deze pipelines bestaan uit opeenvolgende repeterende activiteiten die nodig zijn om code naar bruikbare software om te vormen. Uiteraard, bij voorkeur, geautomatiseerd als een lopende band in een autofabriek die alleen door robots wordt bemand.
Code met kleine wijzigingen gaat door deze pipeline en resulteert, als alles goed gaat, in gewijzigde bruikbare software. Dit kan voor veel onderdelen van de code prima werken. Denk aan code die zegt: 1+1=2. Dit is duidelijk en ook als test goed te automatiseren.
Maar hoe ga je om met gebruiksvriendelijkheid van een geheel systeem of de toegankelijkheid van het systeem voor mensen met een fysieke beperking? Of met integratie met andere systemen buiten de eigen organisatie? Daarnaast worden systemen elke dag complexer waardoor creativiteit in testen en het buiten-de-gebaande-paden-denken essentiëler worden. Deze testen zijn vaak beperkt te automatiseren door flexibiliteit en complexiteit, en vergen daarom alle aandacht van een specialist, de tester. Dus door testen te automatiseren, krijgt de tester meer tijd voor het uitvoeren van complexere testen al dan niet ondersteund door tooling. Maar een tester doet nog veel meer.
Auteurs: Bart Knaack, Iris Pinkster, Bilal Sabuncu, Veerle Verhagen, Francis Welbie
Hier wordt volgens mij een grote denkfout gemaakt. Niet de testers zijn onmisbaar, maar de testen zelf. En dan specifiek: zo volledig als mogelijk (en haalbaar) testen.
De auteur merkt terecht op dat in een DevOps omgeving iedereen een ontwikkelaar is (T-shaping etc.) maar vergeet daarbij dat een ontwikkelaar ook wel degelijk testen dient te ontwikkelen. Als was het alleen maar om bij het refactoren van de code een achteruitgang in functionaliteit of de introductie van fouten te voorkomen. Ook regressie dient door de ontwikkelaar te worden voorkomen door middel van testen.
De denkfout hier echter is dat de ontwikkelaar zich niet zou bezig houden met testen, of op z’n hoogst unit tests. Maar in een DevOps omgeving dient de ontwikkelaar een aantal petten op te zetten: die van de architect (hoe houdt ik het systeem onderhoudbaar en worden alle functionele en niet functionele requirements gedekt), die van de ontwikkelaar (ik moet de gevraagde functionaliteit implementeren en bewijzen dat het werkt), maar ook zeker die van tester (werkt alles ook in samenhang).
Dat ontwikkelaars hier wel eens moeite mee hebben of dat het ze (nog vaker) moeilijk wordt gemaakt is duidelijk. Maar het zijn niet meer perse een aparte groep met testers die de tests ontwikkelt en uitvoert, dit is ook nog eens op het bordje van de ontwikkelaars gekomen. Het is misschien tijd om de testers om te scholen tot ontwikkelaars, en dan de mede-ontwikkelaars blijvend wijzen op het belang van testen.
Het idee van een ontwikkelaar die ook kan/moet testen omarm ik. Net als het idee dat een tester moet/kan ontwikkelen. In een Devops omgeving zal iedereen in een team verschillende petten op moeten kunnen zetten. Dat wil niet zeggen dat mensen geen lievelingspet hebben. Dus de ontwikkelaars weten het meest van ontwikkelen (en vinden dat waarschijnlijk ook het leukst) en de tester zal het liefst de testpet opzetten omdat zij dat het leukst vinden. Als we zo omgaan met alle rollen zal er geen taak of activiteit zonder de juiste diepgang en kennis opgepakt worden.
@Iris .. ik ben hier in de loop der jaren wat terughoudender in geworden ….
Het hangt mijns inziens nogal af van het gewenste kennisniveau binnen je team/project, ofwel weten 3 mensen die ieder iets weten van ontwikkelen, testen en operations net zoveel als 3 mensen die elk in één van die gebieden gespecialiseerd zijn?
Als het antwoord nee is, maar er is geen behoefte aan diepgaande kennis, dan is het geen enkel probleem wellicht. Maar ik heb ondertussen heel wat *peep*-implementaties gezien voor bijvoorbeeld installatie, geschreven door teams waarin iedereen alles werd geacht te kunnen.
Een simpel voorbeeldje: een cmd file waarin je wat kopieert, installeert en als laatste commando een “echo done” geeft
Dit script stop je dan vervolgens in een scheduler als Jenkins, en je build is altijd groen … waarbij mensen vervolgens blindelings op de groene build vertrouwen.
Wat voor applicaties gaat het hier over? Want dat mis ik dus altijd in dit soort artikels.
Hoeveel tabellen opslag praten we over? Aantallen users? Welk platform draait het op? Wat zijn de software dependencies (OS, runtime, etc)?
Agile mensen praten altijd over hun applicaties alsof het een ERP applicatie is. Maar eigenlijk is het gewoon weer alsof de 90’s weer terug zijn, toen iedereen zijn eigen kleine applicatietjes schreef.
Uiteindelijk komt het allemaal neer op risico en hoe we daarmee omgaan. Deel 3 van dit artikel geeft dat ook al aan. En natuurlijk dragen eerdere ervaringen ook bij aan het risico profiel dat je als team opstelt.
Iris,
Risico management gaat om Murphy in de bek spugen:
If there’s more than one way to do a job and one of those ways will end in disaster, then somebody will do it that way.’ betekent dat je niet alleen de vraag moet stellen wat er mis kan gaan maar ook welke maatregelen je KUNT nemen om de daaruit voortkomende schade te beperken als het om EXTERNE risico’s gaat. KJ heeft een punt over de schakels in de keten want agile werken is alsof je weer gaat kleuteren in de zandbak omdat iedereen vooral met zichzelf bezig is.
Terug naar Murphy want er is altijd een wisselwerking tussen een hogere leversnelheid en de operationele kosten. Dat heet ‘kwaliteit’ zoals de Boeing 737 MAX lessen leren, gebrek aan inzicht in het systeem als geheel leidt nog weleens tot besluiten die leiden tot rampen. Ik denk dat het evident is dat er een verschil zit tussen zandtaartjes bakken en een vliegtuig bouwen want juiste diepgang aangaande het inzicht in het systeem als geheel hebben software testers niet.
Natuurlijk is het metertje van de brandstoftank op het dashboard goed ontworpen en getest maar als iemand vergeet deze aan te sluiten op de sensor die informeert over de inhoud van de brandstoftank dan krijg je wat PaVaKe schetst, verkeerde besluiten door onjuiste informatie.
Hmmmm, interessant dat ons artikel zoveel discussie los maakt.
Altijd goed om te zien dat mensen de tijd nemen om het te lezen EN te reageren… Even wat commentaren…
‘Niet de testers zijn onmisbaar, maar de testen zelf.’: true, wat in het artikel ook staat ‘Er zal nog steeds een tester nodig zijn of in elk geval iemand met kennis van en ervaring met testen en kwaliteit.’
Je wilt op een of andere manier testkennis in je team geborgd hebben….. dat hoeft niet per se een ’tester’ te zijn, een ‘programmeur’ met affiniteit met testen, kan hier ook een goede invulling aan geven….. wat we echter in de praktijk zien is dat dit lang niet altijd aanwezig is in een team. Het liefst heb je iemand met een ’test-spike’ in je team, iemand die de testkennis kan in brengen en het team kan coachen in kwaliteitsdenken en testen.
En om even op dat punt door te pakken….. als het kwaliteitsdenken omhoog gaat in een team is er minder behoefte aan ’testen’. Hoe beter de unit testen zijn, hoe minder API en End-2-end testen er nodig zijn. Hoe beter men van te voren nadenkt over risico’s en impact, hoe minder er achteraf nog behoefte is om ‘kwaliteit erin te testen’, hetgeen mijns inziens sowieso een fallacy is.
En ik sluit me absoluut aan bij de visie dat het een pre is verschillende ‘expertises’ in je team te hebben, boven een team van generalisten, die overal een beetje verstand van hebben….. het heet immers niet voor niets T-shaping…..zonder de poot van de T wordt het een stuk moeilijker om alle taken op de juiste manier gedaan te krijgen.
Dit houdt echter ook in dat de streep van de T ook moet zijn ingevuld…. een ‘programmeur’ zal iets van design en testen moeten weten. De ’tester’ zal de basics van programmeren ook moeten begrijpen en op de raakvlakken zullen ze elkaar zeker moeten vinden. We hebben in het verleden al meermalen joint workshops gehouden over unit testen waar ‘programmeurs’ en ’testers’ de handen ineen slaan om tot goede unit tests te komen…..