Is testen nog een levensvatbaar vak?

Geschreven door Ywe van der Pol

Gepubliceerd op 31 maart 2016

Blog Ywe 252x300 - Is testen nog een levensvatbaar vak?

Agile, Scrum, Kanban, DevOps, termen die vandaag de dag hot en trending zijn en waar we volgens de markt niet meer zonder kunnen. “Om bij te blijven bij de huidige snelle markt moet je wel Agile werken”, is een veelgehoorde zin waarmee het huidige methodieken-ensemble wordt neergezet. Maar wat betekent dat nu eigenlijk? Wat betekent het voor ons testers? De discussie over hoe testers zich zouden moeten gedragen in het huidige IT-landschap is heviger dan ooit. Terwijl de markt roept dat bedrijven zich moeten focussen op ontwikkeling, continuous “alles” en testen probeert af te schrijven als onnodig, is de Test community op zoek naar een antwoord op de vraag: “Is Testen nog een levensvatbaar vak?”
“Ja!” is mijn volmondig antwoord.
De wereld der IT is niet anders dan welke arbeidstak dan ook en is dus zwaar onderhevig aan trends. Op welk niveau dan ook, iedereen “leest” wel eens iets of “pikt” wel eens iets op. Zeker domein- of vakmensen onder elkaar vertellen graag verhalen over hoe het bij hun te werk gaat, en ik spreek uit ervaring. De verhalen over hoe fantastisch het Agile werken is, hoe prachtig de continuous delivery stream opgezet is of hoe effectief de sprints verlopen, zijn allemaal onderwerpen die makkelijk aanzetten tot nadenken.
Ongestructureerd (en vaak ongevraagd) wordt de hele ontwikkelstraat veranderd, alle documentatie overboord gegooid en wordt er elke ochtend om 10 uur het “scrum” bord letterlijk voorgelezen. Er worden sprints geïmplementeerd, de projectleider heet voortaan Scrummaster en pokeren wordt weer hot. De samenvatting van elke ontwikkelmethodiek tegenwoordig is simpel; “Hoe kom ik het snelst van A naar B?”. Dit gespiegeld naar softwareontwikkeling vertaalt zich naar: “hoe ontwikkel ik zo snel mogelijk mijn software?”. En in deze vraag ligt de crux. Laat me jullie in vogelvlucht meenemen in de historie van softwareontwikkeling.
Traditioneel ligt ontwikkeling van software in de waterval methodiek. Van idee of probleem tot aan oplevering met alle disciplines die daar bij horen. Informatieanalist, ontwikkelaar en tester. En zoals de zin al laat merken, Testen staat als laatste dus kunnen we het makkelijkste overslaan om tijd te winnen. Maar laten we eens kijken waarom de tester achteraan in de cyclus staat.
Van origine is de Tester de functionele poortwachter van de softwareontwikkeling. Problemen werden geanalyseerd, oplossingen werden gebouwd en vrees niet, voordat we onze software live brengen is daar de tester die “alle” bugs eruit haalt en dan komt alles goed! Maar niets bleek minder waar. Traditioneel, voordat de software in de schoot van de tester viel was er al zoveel tijd verstookt aan alle voorgaande disciplines dat alles waar de software aan moest voldoen in de tussentijd was veranderd. Niet omdat de analist zijn of haar werk niet goed had gedaan maar er zat zoveel tijd tussen dat de markt of de eindgebruiker veranderd was ten opzichte van de originele requirements.
De oplossing: Agile ontwikkeling! Alle disciplines in 1 team zodat iedereen vanaf moment 0 op de hoogte is. Fantastisch! Prachtige software werd er geproduceerd, meteen getest en direct door de business geaccepteerd. Iedereen gelukkig! De “ready to be shipped” pakketjes waren er in overvloed en de business had haar versnelling gekregen waar behoefte aan was. Toch schuilt er een valkuil in deze methodiek en die zit in het woord ontwikkeling. De definitie van softwareontwikkeling is letterlijk:
“Een discipline die zich bezighoudt met methodes om een vraag of probleem uit de werkelijkheid om te zetten naar een computerprogramma”
Ontwikkelde software zegt niets over het gebruik en hoe software live te krijgen. En zo is DevOps geboren.

De definitie van DevOps zit in de naam.

Het samenbrengen van de development kant en de operationele kant, ofwel infrastructuur. De vraag die vanuit Agile is ontstaan, is een uitbreiding op de vorige: “hoe ontwikkel ik zo snel mogelijk mijn software en hoe breng ik deze zo snel en zo goed mogelijk in productie?”. Deze uitbreiding wordt weer vertaald naar de indeling van de ontwikkel teams. Onder andere infrastructuur, performance en security experts moeten 1 worden met de huidige ontwikkel teams. Gezien de versnellende markt is ook de noodzaak tot versnellende ontwikkeling weer aangewakkerd waarmee de term continuous is geïntroduceerd. De behoefte om continue iets te kunnen doen staat synoniem aan snel. Continue integratie van je ontwikkelde software, continue kunnen deployen naar verschillende omgevingen met als uiteindelijk doel dat elk karakter code direct door de ontwikkelstraat in productie komt. Prachtig!! Zullen alle resultaatgerichte denkers denken.
Maar wat betekent dit nu in de praktijk? Ontwikkeling moet nog sneller, kennis is nog belangrijker en de tijdsdruk is nog hoger. Om hieraan te kunnen voldoen is er bijna een verplichting tot test-automatisering en dus behoefte aan technische testers die deze kennis en ervaring hebben. Wederom met als uiteindelijk doel de lijn tussen disciplines te kunnen verwijderen en een waarlijk multidisciplinair team te hebben die op elk moment de wereld kan verzetten. De rol van traditioneel en functioneel tester zal dus verdwijnen. Maar is dat wel zo?

 
 
 
 
 
 
bron: https://geek-and-poke.com/
Ja en nee. De huidige markt dwingt bedrijven snel te kunnen leveren tegen een bepaalde verwachting van kwaliteit. De consument verwacht directe service en om daar aan te kunnen voldoen zal de IT-wereld zich moeten aanpassen. Maar wat verandert er nu wel en wat niet. Natuurlijk, snelheid verandert, kosten moeten nog steeds omlaag en de kwaliteit moet omhoog. En juist in dat laatste zit mijn vak en expertise, kwaliteit.
50 jaar geleden wilden mensen kwaliteit, 25 jaar geleden wilden mensen kwaliteit en vandaag de dag is het niet anders: we willen nog steeds kwaliteit. Aan ons de kunst om onze expertise mee te nemen in de huidige markt. Als testers zijn we in staat om anders tegen software te kijken, anders een test uit te voeren en een goed beeld te kunnen geven hoe de software zich meet ten opzichte van de requirements. Natuurlijk zullen wij testers onze skills moeten blijven verbeteren zodat we om kunnen blijven gaan met de huidige technische vraag, tools en methodieken. Maar zeg nou zelf, wie kan er nou beter iets over kwaliteit zeggen dan een Tester!

Reacties

Sjoerd op 31 maart 2016, 15:02

Precies om deze reden noemen wij de testspecialisten in onze teams graag QA specialist. Het is namelijk niet alleen testen of iets werkt, maar alle expertise aan boord brengen om de kwaliteit hoog te houden (op functioneel vlak). De kwaliteit op technisch vlak ligt ‘gewoon’ bij de technisch specialisten. Maar hoe zie jij dat eigenlijk? Moeten we alle kwaliteitseisen niet op 1 hoop gooien en alle ‘test’ specialisten daar verantwoordelijk voor maken, of is het een teamverantwoordelijkheid waar de functionele kwaliteitscriteria (met bijbehorende specialisme en expertise) slechts een onderdeel van zijn?

Reageren

Ard Kramer op 1 april 2016, 19:58

Interesante vraagstelling, ik mis in het verhaal wel wat onderdelen:
Waarom spreek je over waterval als de start, volgens mij waren daarvoor was er ook nog een tijd waar multidisciplinaire teams aan (mainframe) software bezig waren, zonder duidelijke ontwikkelmethodiek?
Waarom geen melding van het feit dat een heel team verantwoordelijk wordt gesteld (bij scrum) voor kwaliteit en een andere mindset betekent voor ‘ontwikkelaars’ van een scrumteam?
En is het uitgangspunt dat testers bij uitstek iets kan zeggen over kwaliteit kan zeggen, vind ik ook wel wat achterhaald, ook gezien mij tweede vraag. Dat we van waarde kunnen zijn, lijkt me wel, je argumentatie vind ik nog niet erg sterk….ik ben benieuwd naar andere argumenten

Reageren

Schrijf een reactie

Gerelateerde artikelen