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

Crisis in testen

 

Computable Expert

Carlo van Driel
Testmanager, ThiemeMeulenhoff. Expert van Computable voor het topic Development.

De crisis grijpt nog steeds om zich heen. Heeft dit gevolgen voor testen of juist niet en wat zijn de positieve kanten aan de crisis?

Het aantal projecten is kleiner omdat het budget kleiner is. Zou het echter niet nu juist tijd zijn om het aantal projecten gelijk te houden en de effectiviteit van die projecten te verhogen.

Laat ik het toespitsen op testen: de afgelopen jaren is het testvak voornamelijk bezig geweest met het verbeteren van de ict-wereld. Op zich een nobel streven, maar ze zijn daarbij wel één belangrijk ding vergeten, en dat is dat die verbetering toch echt bij jezelf moet beginnen. Talloze verbeteringen in requirement management, ontwerpen en bouwen hebben nog nauwelijks geleid tot minder testinspanning, terwijl dat in theorie toch wel de bedoeling is. We zien nog steeds een substantieel deel van een projectbudget opgaan aan testen nog los van het feit dat zelfs de kleinste aanpassing in een applicatie honderden test-uren kost.

Conclusie is dan ook dat de crisis nog onvoldoende is geweest om de testwereld (want laten we nu eens bij ons zelf beginnen) te dwingen om te komen met nieuwe innovatieve ideeën om het aantal test-uren zowel relatief als absoluut flink naar beneden bij te kunnen stellen, zonder daarbij de kwaliteit uit het oog te verliezen of de inspanning te verplaatsen naar een andere discipline.

Waar zouden we aan kunnen denken:

  • minder opsplitsing van testfuncties; meer functies is meer overhead
  • later starten met de testvoorbereiding; de praktijk leert dat er altijd uitloop is en testers veel leegloopuren hebben
  • doorlooptijd van testen vergroten maar veel meer projecten simultaan; om leegloop op te vangen de risico's spreiden over meerdere projecten
  • testsoorten drastisch inperken; veel testen worden meer dan een keer gedaan in min of meer gelijke testsoorten
  • moeten we echt alles documenteren; we doen er meestal toch niets meer mee
  • laat testverbetering over aan de community zoals bijvoorbeeld testnet; doe niet zelf half aan verbetering daar dit niets oplevert
    • Ik begrijp dat bovenstaande aanpassingen niet dat innovatieve idee zijn om echt te komen tot de gewenste verbetering. Het zijn alleen quick-wins om een deel van de besparing te kunnen bereiken.

      Ik wil de test-community oproepen om, niet teveel gehinderd door de huidige methodieken en standaarden, na te denken om tot een dusdanige methodiek te komen om echt een verschil te maken. De tijd lijkt gekomen voor revolutie in plaats van evolutie.

      Conclusie

      Is er crisis in testen? Nog niet genoeg om de testwereld te dwingen om met echte innovatieve ideeen te komen.

      Bij deze de oproep om ons eigen testproces en de methodieken eens kritisch onder de loep te nemen om door forse budgetreductie te komen tot een echte doorbraak in efficiënt en effectief testen.

      Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3363185). © Jaarbeurs IT Media.

      ?


      Lees meer over


       

      Reacties

      Testen als instrument voor kwaliteitsborging zou centraal moeten staan. Op dat vlak is de laatste jaren heel veel vooruitgang geboekt, maar met de enorme hoeveelheden bugs in software die nog steeds normaal worden gevonden, is die ontwikkeling nog lang niet voltooid. We kunnen bezuinigingen en kaalslag, onder de dekmantel van "innovatie" en "efficiëntie", niet accepteren. Als de ICT sector (belangrijke economische motor in de EU) mee wil helpen de crisis te beëindigen, dan is beknibbelen op kwaliteit totaal niet aan de orde. Om maar te zwijgen van de noodzaak, het vertrouwen van klanten en markten te behouden. Juist in crisistijd is grondig testen harder nodig dan ooit.

      Waarom wordt er, al die 15 jaar die ik in de testwereld zit, gesproken over minder testen en goedkoper testen? Of nog zo een: dat softwareontwikkelprocessen nog niet voldoende volwassen zijn en dat daarom getest moet worden?
      Mijn stelling:
      Hoe volwassener de industrie, hoe volwassener de testprocessen.
      Carlo heeft een punt als hij zegt dat er veel dubbel wordt gedaan en dat testware niet voldoende wordt hergebruikt. Maar moeten we het daarom dan maar niet doen? Naar mijn mening moeten we als testers juist blijven sjorren aan het verder volwassen maken van het hele softwarevoortbrengingsproces, volgens het principe: stuur op kosten en de kwaliteit daalt / stuur op kwaliteit en de kosten dalen.

      Wat zijn dan die "talloze verbeteringen in requirement management, ontwerpen en bouwen"? Als ze er al zijn, dan toch niet door testers geinitieerd. Ik zie testers zich vooral met zichzelf bemoeien en veel te weinig met de andere disciplines. Nou ja, we klagen vooral over anderen.

      Ik denk dat het testvak pas serieus genomen wordt als wij in staat zijn om bruggen te slaan naar de andere disciplines. En dit OOK in onze methodes - want daar zijn wij goed in. Veel testmethodes gaan alleen over testen!

      Ik ben het eens met Carlo dat er iets moet en kan gebeuren. Maar of de verbeteringen worden bereikt door later te starten of door de leegloop te verdelen over meerdere projecten, daar heb ik twijfels bij. Ik denk zelfs dat hierdoor de druk op de testers groter wordt en dat hiermee de kwaliteit van de software achteruit gaat.
      Volgens mij is er meer te verdienen als kwaliteit niet alleen wordt uitgevoerd door testers, maar een team verantwoordelijkheid wordt. Dus samen met de (eind-)gebruikers, ontwerpers en ontwikkelaars. Het testen wordt dan niet meer alleen uitgevoerd door de tester. Dit houdt ook in dat testers andere taken van andere disciplines zullen (en kunnen) overnemen.
      Dus samenwerken!

      Vacatures

      Stuur door

      Stuur dit artikel door

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

      ×
      ×