De voorbije 10 jaar hebben bedrijven de waarde van QA en testing in het algemeen ingezien. Vandaag heeft elk bedrijf zijn eigen QA-departement dat ervoor zorgt dat zijn software correct werkt. Maar de kost van deze departementen worden alsmaar hoger. Zal deze trend zich voortzetten of zijn er nieuwe en goedkopere manieren om QA aan te pakken?
Digital disruption
Op de hoek van mijn straat is er een Chinees restaurant. Heel dichtbij, en toch, wanneer ik Chinees bestel ga ik er nooit langs, maar doe ik het bij een restaurant dat zich niet eens in mijn eigen dorp bevindt. En dat doe ik niet omdat het eten slecht is in het restaurant op de hoek. Neen, de reden is dat het tweede restaurant een app aanbiedt waarmee je online kan bestellen. Bestaande klanten als mezelf kunnen dus in een vingerknip hun avondeten bestellen.
Dit persoonlijke voorbeeld is een van de zoveelste over hoe bedrijven beïnvloed worden door digital disruption. Zowel kleine als grote, kijk maar naar wat er met Kodak is gebeurd. Sinds enkele jaren worden klanten verwend met digitale oplossingen die hun leven een stuk makkelijker maken. En met de explosie van mobile adoption heeft omzeggens elk bedrijf de middelen om hun klanten met een digitale oplossing te bedienen. Klanten smullen niet alleen van die oplossingen, ze verwachten ze ook. Net als ik: als ik mijn eten niet online bij jou kan bestellen, ga ik wel naar een concurrent waar ik dat wel kan.
Verandering is niet gemakkelijk
Op de hoogte zijn van digitale innovatie is belangrijk. Ik ben ervan overtuigd dat de meeste grote bedrijven dat zijn, maar er daarom niet altijd naar handelen. Neem bijvoorbeeld de financiële sector. Banken hebben de afgelopen 40 jaar gestaag hun IT-landschap uitgebreid en hun interne processen verbeterd en toch moeten ze plotseling enorme onlineplatformen beginnen bouwen om te concurreren met ‘nieuwe’ digitale spelers als PayPal.
Bedrijven die dit probleem erkennen, investeren fors in hun digitale transformatie. De invulling hiervan is voor elk bedrijf anders, maar als ze willen slagen, dan moeten ze wel een gelijkaardig doel voor ogen houden: ze moeten leren wat hun klanten belangrijk vinden in hun producten en diensten en deze hieraan aanpassen. Bedrijven die dit sneller doen dan hun concurrenten kunnen hier heel wat voordeel mee doen. Wanneer we dit in een IT-perspectief plaatsen, houdt dit o.a. in dat bedrijven hun product release cycles moeten gaan versnellen. En nog geen klein beetje.
Het opnemen en invoeren van praktijken als lean thinking en agile software development zijn hierin niet voldoende. Er zijn een aantal oorzaken die de lead time van product releases beïnvloeden, maar naar mijn gevoel is Quality Assurance degene die het meest vergeten wordt.
Traditionele QA
Wanneer je aan IT-projecten werkt, hoort QA erbij. Doorheen de jaren zijn bedrijven meer en middelen gaan besteden aan QA, ondertussen goed voor ongeveer 35% van het totale projectbudget. En dit getal blijft maar stijgen.
Dit valt te verklaren door de waarde die QA oplevert. Elk probleem dat een tester vindt levert waarde op voor de stakeholders van het project en elk opgelost probleem levert meteen waarde op voor de eindklant.
Bedenk ook dat in deze digitale wereld klanten heel wat impact kunnen hebben op de reputatie op een bedrijf, o.m. via social media. Om klanten tevreden te houden, moet het QA-team alle – en zeker en vast de kritische – problemen opsporen. Maar omdat project alsmaar complexer worden en business requirements steeds sneller veranderen, hebben kleine QA-teams het moeilijk om het hoofd boven water te houden. Intuïtief gezien zou het dus logisch zijn om nog meer in QA te investeren, maar als we kijken naar hoe QA is geëvolueerd, zien we dat dit niet noodzakelijk steek houdt.
Het probleem is dat in heel wat bedrijven een QA-team een team is bestaande uit testers die software bekijken vanuit het standpunt van de gebruiker. Dit is met andere woorden een externe view op het project die alleen van toepassing is wanneer een applicatie tot op een bepaald niveau is afgewerkt.
Hierdoor gaat traditionele QA deel uitmaken van de watervalaanpak, wat een heel kostelijk en lang proces is. Want voor elk probleem dat opgelost wordt, moet de code base opnieuw gedeployed worden en moet de applicatie getest worden op regression defects. Dit kost heel veel tijd voor mogelijk slechts één feature die stakeholders aan hun klanten willen aanbieden.
Test automation
Ik heb al heel wat bedrijven gezien die hun functional regression packs wilden automatiseren om net met dit probleem komaf te maken. Op papier lijkt dit nuttig en voor traditionele QA professionals voelt dit ook goed aan omdat ze een product met de blik van een buitenstaander proberen te bekijken. Maar deze aanpak zal je niet helpen met het verkorten van je gemiddelde lead times. Meer testers inzetten en functionele testautomatisatie zullen het probleem niet oplossen, want eigenlijk plaats je een vrij dure pleister op een wonde die in feite genaaid moet worden.
De weg naar quality at speed
In de beginjaren was QA een vangnet voor bugs aan het einde van de waterval. Zelfs customer-facing software hoefde enkel te ‘werken’. De QA-teams van vandaag worden nog steeds gezien als een vangnet, maar daarbovenop moeten ze zich met heel wat meer zaken bezighouden. QA is meer dan enkel testen op bugs. QA wordt geconfronteerd met performance en availability SLA’s, usability en accessibility requirements, tekortschietende omgevingen, projecten die op legacy steunen, externe producten en nog zoveel meer zaken die buiten beschouwen werden gelaten in traditionele QA. Met andere woorden: investeren in een groter vangnet is niet meer voldoende.
Traditionele QA-teams zijn niet gewapend om met al deze facetten om te gaan en omdat ze pas op het einde van de release cycle in het spel komen, liggen zaken als usability en code quality vaak ver buiten hun scope. Om releases sneller te laten verlopen, moeten we QA een onderdeel maken van de rest van het project. We hebben ook QA-professionals nodig die de business value van een project kennen, de tech stack begrijpen en de infrastructuur waarop het draait. QA-experten zullen ‘awareness’ moeten creëren en architecten, developers, analisten etc. bijstaan bij het opmaken van een blueprint waarin de noodzakelijke maatregelen staan die kwaliteitsgarantie bieden (en liefst op een snelle manier).
Deze maatregelen verschillen van project tot project, maar ze richten hun pijlen wel op dezelfde elementen: ze hebben een impact op hoe software wordt ontwikkeld, hoe code wordt geschreven, hoe omgevingen opgezet worden, hoe met data omgesprongen wordt etc. QA zal mee in het bad getrokken worden tijdens het project in plaats van op het einde ervan en elke projectmedewerker moet zijn of haar rol vervullen met QA in gedachte.
Met dit type QA kunnen we eindelijk de weken van bugs opsporen in acceptance omgevingen achter ons laten. In plaats daarvan kunnen acceptance omgevingen gebruikt worden door onze business stakeholders als private beta environments waar ze sneller kunnen leren wat hun klanten echt willen en hoe gebruiksvriendelijk hun producten echt zijn. Product features kunnen nu gereleased worden binnen enkele dagen in plaats van maanden, wat de feedback loop tussen business en hun klanten sterk verkort. Voor een bedrijf dat een digitale transformatie ondergaat, is dit een van de doelen die, eens bereikt, sterk zal helpen bij het overklassen van de concurrentie.
Dit zijn natuurlijk veranderingen met een hoge impact die niet in 1-2-3 doorgevoerd kunnen worden. Maar wanneer testcycli te lang beginnen duren, bugs in productie terechtkomen of klanten beginnen te klagen op social media, is het aangewezen om minder sterk te investeren in een traditionele QA-afdeling. In plaats daarvan is de tijd rijp om te herevalueren hoe we QA binnen onze projecten aanpakken.
Ben je op zoek naar een partner die je kan helpen met de eerste stappen te zetten naar echte quality at speed? Contacteer dan onze QA-experten.
