Geen enkel bedrijf ontkomt er aan, kostenbesparingen zijn aan de orde van de dag. Maar kun je op een creatieve manier van de nood een deugd maken? Kunnen testers ook bijdragen aan de noodzaak om kosten te besparen zonder concessies te doen aan de kwaliteit van de opgeleverde software? Ik vind dat er in Nederland testland veel laaghangend fruit te plukken is. Testers kunnen in mijn optiek hiervan zonder veel moeite drie vruchten plukken; die van procesaanpassingen, die van attitude en die van de inzet van tools.
De eerste vrucht: procesaanpassingen
Allereerst zal het uitvoeren van tests niet meer een eenmalige fase na het programmeren moeten zijn, maar veel meer een ondersteunde activiteit van het ontwikkelproces. Je ziet dit nu al in agile-projecten gebeuren: de tester is onderdeel van het ontwikkelteam en voert zijn tests parallel aan de ontwikkeling uit. Daarmee krijgt de programmeur directe feedback op zijn werk, worden eventuele fouten in een vroeg stadium ontdekt en kunnen ze ook snel weer opgelost worden. Immers, de code zit nog 'vers in het hoofd' van de ontwikkelaar, dus is de hersteltijd aanzienlijk korter dan bij feedback loops van weken. En als de ontwikkelaar en de tester toch zo nauw samenwerken, dan kan de tester ook wel meteen zijn testgevallen aan de ontwikkelaar laten zien. Op die manier wordt er code geschreven die voldoet aan de testcriteria. Als tester kun je dit dan kort valideren en je aandacht richten op andere testsituaties.
Op deze manier verkort je aanzienlijk de doorlooptijd van het ontwikkel- en testproces. Er is sprake van samenwerking in plaats van interne concurrentie. Kwaliteit is veel meer een integraal onderdeel van het proces in plaats van een toetsing achteraf. Dit voorkomt fouten en als ze gemaakt worden, worden ze in een vroeger stadium geconstateerd en sneller opgelost. Dat is een aanzienlijke verbetering in de efficiency van het ontwikkelproces.
De tweede vrucht: attitude
De tweede manier om kosten te besparen is het loslaten van de procesfocus die veel testafdelingen hebben. Voor iedere fase en iedere stap in het testproces is wel een template, een RACI-matrix en een escalatiepad gedefinieerd. Daarbij wordt als norm vaak het 'worst case-scenario' van een testproject gedefinieerd. Het zou zo ontzettend veel geld schelen als we voor minder belangrijke en minder kritische projecten ook eenvoudiger procesmodellen zouden hanteren. Dat kan door projecten te classificeren als hoog, midden of laag risico en ze ook zo te behandelen. De risicoclassificatie doe je uiteraard vanuit business én technologisch perspectief en dus met de business samen.
Door procesmodellen vereenvoudigd toe te passen bespaar je op directe kosten (minder activiteiten) en overhead (minder controle). En start nu niet meteen een project 'Vereenvoudiging procesmodellen testen' maar zet je knapste koppen een middag in een hok, produceer een resultaat en begin ermee in je eerstvolgende project. Bij een goede analyse van het type project hoeft dit helemaal niet ten koste te gaan van de kwaliteit. Je zult er wellicht achter gaan komen dat je jarenlang te veel geld aan testen hebt uitgegeven…
De derde vrucht: inzet van tooling
De derde en laatste vrucht is de inzet van geautomatiseerde hulpmiddelen, oftewel testtooling. Analoog aan de voorgaande suggestie: zet ook deze in als het echt nodig is. Bekijk dus kritisch waar je extra tooling kunt inzetten om sneller tot resultaten te kunnen komen en om duur en langzaam handmatig testen te vervangen. En begin uiteraard met het kijken bij open source-tooling, dat vaak verrassend goed ondersteunt!
Maar kijk ook eens tegengesteld: wordt testtooling wel efficiënt ingezet? Wordt er wellicht teveel regressie geautomatiseerd getest, bijvoorbeeld op die onderdelen van de software die moeilijk testbaar of helemaal niet kritisch zijn? Zijn de gerealiseerde testsets wel voldoende onderhoudbaar of kost iedere wijziging meer dan dat hij oplevert? Ik heb op afdelingen gewerkt waar zelfs eenvoudige schermwijzigingen alleen de afdeling Testautomatisering al drie dagen werk kostte! Dus ook bij het inzetten van testtooling is een op risico's gebaseerde aanpak te prefereren. Niet alles automatiseren, maar automatiseer wel die onderdelen die kritisch zijn en/of veel gewijzigd worden. En zorg ervoor dat het onderhoudbaar en wijzigbaar blijft, want dat gebeurt nu eenmaal bij systemen die in gebruik zijn.
Samengevat: stel je eigen aannames ten aanzien van je testprocesinrichting eens stevig ter discussie. Waarom hebben we bepaalde afspraken gemaakt en is die context waarin die destijds gemaakt zijn nog steeds van toepassing? Zijn er nieuwe risico-afwegingen te maken die besparingen opleveren en eenvoudig te implementeren zijn? Ik weet zeker dat je tot verrassende inzichten komt!
Ik ben het eens met een aantal punten. Echter heb je niet bij elke bedrijf een aparte test-team. Veelal worden de tests uitgevoerd door de functioneel beheerder, die naast het testen andere werkzaamheden hebben die gewoon doorlopen. Om het testen paralel te laten lopen met het systeemtesten van het ontwikkelteam is vaak niet te doen.
Dit in verband met:
a. inzet personeel
b. tijd
c. (verschillende)planningen van de afdeling
Wat m.i. zeker zal helpen om de kosten te drukken voor de testers. Om om gebruikers te vragen naar hun opinie van de FAT (functioneel acceptatietest)
Een GTA op te stellen (Generieke Test Afspraken).
Ook een faalkansanalyse met alle betrokkene opstellen zodat de kwaliteit van het testproces wordt gewaarborgd.
En waar ik het zeker mee eens ben is de samenvatting.
Ik ben van de oude stempel en vind dat de bron aangepakt dient te worden. De programmeur test zijn programma’s en de samenhang binnen zijn/haar scope. De ontwerper doet een totaal test. Pas dan wordt het overgedragen aan de gebruikersorganisatie voor een finale acceptatietest. De fouten die dan gevonden worden zijn minimaal. Zoniet dan is er door de programmeur en ontwerper niet goed getest. Het gaat om competentie van zowel het ontwerp/ontwerper en de programmeurs. Tevens moeten ze de tijd claimen in de planning om de testen uit te voeren.
Het zou beschamend moeten zijn als tijdens een gebruikerstest nog veel fouten worden geconstateerd.
Een verfrissende kijk op het verbeteren van een testproces. Niet dat zware middel TPI waar vaak moeilijke oplossingen worden geboden voor verbeteringen, maar een to-the-point-benadering.
Dat je niet overal een apart team hebt hoeft je niet te weerhouden om kritisch naar je proces, de attitude en de inzet van je tooling te kijken. Niet iedere vrucht kan en hoeft op hetzelfde moment geplukt worden, als deze maar in de gaten gehouden wordt.
@Gerard Jonker
Zoals ik ook onderaan mijn verhaal had gezet:
“En waar ik het zeker mee eens ben, is de samenvatting.”
Samenvatting:
Samengevat: stel je eigen aannames ten aanzien van je testprocesinrichting eens stevig ter discussie. Waarom hebben we bepaalde afspraken gemaakt en is die context waarin die destijds gemaakt zijn nog steeds van toepassing? Zijn er nieuwe risico-afwegingen te maken die besparingen opleveren en eenvoudig te implementeren zijn? Ik weet zeker dat je tot verrassende inzichten komt!
Laaghangend fruit bij besparen op testkosten?
Als je al een testteam op volle kracht hebt werken in een organisatie kan je inderdaad beginnen met bezuinigen en kan je deze tips meenemen in je plannen.
Ik vind zelf de tip om je “procesmodellen” aan te passen aan het project nog wel de meest praktisch toepasbare manier om snel te kunnen bezuinigen, goed idee om prioriteiten aan projecten te geven en dan bepaalde stappen over te slaan of “light” te maken. Wel voorzichtig mee zijn en iemand met meer testervaring erbij halen om zijn ervaringen uit het verleden erin te verwerken.
Het andere punt; al bij de ontwikkelaar gaan zitten en samenwerken vanaf het begin, ontwikkelen en testen. Ik vraag me af IT’ers daar al klaar voor zijn en of het wel laaghangend fruit is. Om een ontwikkelaar en een tester samen te laten werken is wel een aardige leercurve bij betrokken. Ik vind wel dat we daarheen moeten gaan in de IT, maar een snelle winst behalen bij grotere teams lijkt me lastig.
Het besparen op testtooling door open source tooling te gaan gebruiken. Het uitzoeken welke tooling dan is al een investering. ‘al die oude testscripts’ vervangen. Waar vind je de persoon die dat durft ;-).
Helemaal mee eens overigens dat veel geautomatiseerde tests meer geld kosten in onderhoud dan dat het vaak oplevert. Handmatig testen heeft toch nog vaker de voorkeur, al is het alleen maar omdat je dan niet elke keer hetzelfde test, wat meer bevindingen oplevert dan elke keer precies hetzelfde testen, wat met automatische scripts gebeurt.
Mijn samenvatting: Bij grotere al bestaande testteams goede ideëen, ik verwacht dat samenwerken en testtooling opruimen meer werk is dan laaghangend fruit plukken. De tip van prioritering op projecten vindt ik zeer goed. En voor organisaties die bezig zijn een testteam op te bouwen zijn deze tips helemaal pure winst. Valkuilen in testaanpakken die gelijk vermeden kunnen worden. En je samenvatting: Pure winst voor iedereen die op die manier nadenkt!