Auteur: Patrick Duisters ● Patrick.Duisters@improveqs.nl
Redactie: Paul Beving en Kimberly Snoyl
In de aanloop naar het TestNet Voorjaarsevenement werd ik gevraagd of ik een bijdrage wilde schrijven voor TestNet Nieuws. Nu doe ik dat al meerdere jaren, dus was het niet moeilijk om daar ja tegen te zeggen.
In de aankondiging van het thema zit genoeg inspiratie. Alleen al de woorden ‘de laatste decennia’ zet me aan het denken. Ik sta aan de vooravond van 25 jaar in het testvak: ik voel me al bijna oud 😉.
‘Testautomatisering steeds belangrijker’: daar begon mijn carrière in 1997 mee. In mijn CMG-tijd werd ik direct in TestFrame gezogen. Met als belangrijkste aanleiding het herhaald testen rond de millenniumproblematiek. Destijds al heb ik de keuze heb gemaakt om me vooral te richten op de testinhoud en niet op het maken van de automatiseringsscripts. Gevoelsmatig ligt er tegenwoordig (te) veel nadruk op het automatiseren en zou er meer aandacht mogen zijn voor testanalyse en testinhoud. ‘Automating chaos creates faster chaos’ is een klassieke maar nog steeds een passende uitspraak!
T-Shaped
Maar waarin ik jullie eigenlijk in wilde meenemen is de term T-shaped. Wat is T-shaped eigenlijk? Volgens wikipedia: ‘The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own’. Met als aanvulling: ‘The term T-shaped skills is also common in the agile software development world and refers to the need for cross-skilled developers and testers in an agile team, e.g. a scrum team.‘
Hoe T-shaped ben ik zelf dan?, vraag ik mij dan af. En als dat zo is, komt dat dan door carrièreplanning of door mijn (meer dan?) ‘natuurlijke’ brede interesse? En hebben andere testers en ontwikkelaars dat ook?
Om daarachter te komen wil ik jullie even meenemen door mijn werkzame leven.
De afgelopen 30+ jaar…
Van oorsprong ben ik opgeleid als werktuigbouwkundige (en wat doet die dan in de IT??) en omdat ik als kind vrachtwagenchauffeur wilde worden heb ik me daarna gespecialiseerd via een aanvullende opleiding in de autotechniek en koos ik daarin altijd opdrachten en stages die iets met vrachtwagens te maken hadden. Mijn eerste baan werd dan logischerwijs ook iets in die richting: ik ging werken bij een bouwer van aanhangwagens en opleggers voor vrachtvervoer. Bij dat bedrijf ging men aan de slag met kwaliteit op weg naar een ISO-9000 certificering. Vanuit mijn rol als werkvoorbereider, continu bezig met hoe dingen gemaakt moesten worden, had ik daar uiteraard een rol in. Een zaadje was geplant. Binnen het bedrijf waren er op dat moment 2 pc’s aanwezig: echt ‘vruuger’ dus.
Na een paar jaar maakte ik een overstap naar een metaalconstructiebedrijf waar ik calculaties ging maken voor de producten en dook ik nog dieper in maakprocessen en bijbehorende schattingen. Dat bedrijf was al iets verder met ISO-9000, en ook daar was ik betrokken, onder andere in audits. In dat bedrijf was men ook al verder met IT. De werkvoorbereiding en calculaties werkten daar al met barcodes: state-of-art voor die tijd! Ook werden producten al getekend in CAD-systemen en maakte men gebruik van CNC-machines. En omdat ik ‘computers’ wel interessant vond, bemoeide ik me steeds meer met ‘alles waar een toetsenbord aan zat’ en mocht ik proeven aan ‘internet’! (Kun je het je voorstellen??, e-mail en internet via een 9600 baud modem? Piieeep, grrrrr, biep, schrgggg…..).
Een nieuwe staander van de T was geboren.
Bijna 25 jaar geleden…
Maakte ik de overstap naar het toenmalige CMG. Die hebben zich uiteraard afgevraagd: kunnen we wat met een niet-IT’er? Omdat ik destijds in de avond een HBO-studie Technische Bedrijfskunde deed, zagen ze potentie en namen ze me aan. Ervaring in kwaliteit en bedrijfskunde was de basis voor een volgende ‘T’ in de rol van ‘tester’. Grote vraag vanwege de aankomende millenniumproblematiek deed de rest. CMG werkte toen veel volgens TestFrame, de basis voor testautomatisering op basis van actiewoorden, ofwel: keyword driven testing. Een nieuw kennisgebied. Na een jaar of twee begon ik ook daar cursussen in te geven: voor de testanalist; ofwel testinhoud!
Waar veel collega’s ‘testmanager’ of ‘navigator’ (testen automatiseren door middel van scripts) als ambitie hadden, bleef ik me bezighouden met de inhoud. Eerst in het bankwezen, verzekeringen en bij toeval kwam ik op een opdracht in het medisch domein: Philips Healthcare. Wow, dat was weer eens een hele andere wereld: interessant!! ‘T’
Na vele opdrachten en ook (te) lange reistijden ging ik bij Interpolis werken. De sfeer die ik in mijn CMG-tijd al eens had mogen proeven stond me aan en de reistijden waren voorspelbaar. Met een ‘keileuk’ team verbeterden we het testproces en waren we meestal ‘in control’. Best knap voor die tijd.
Processen en trainingen
Na enkele jaren en wat persoonlijke omstandigheden was het tijd voor een volgende stap en ging ik werken bij Improve. Voornamelijk omdat ik meer met de processen bezig wilde zijn en weer training wilde gaan geven om mijn kennis en ervaring te delen. Ik viel met mijn eerste opdracht meteen met mijn neus in de boter: opnieuw bij Philips, waar ik continu met procesverbetering bezig was en een FDA-audit vanuit de audit-room meemaakte. Een nieuwe ‘T’ deed zich aan. Die ervaring met gereguleerde omgevingen speelde jarenlang een belangrijke rol en vele projecten in het medische domein volgden.
Ook ging ik vrij snel trainingen geven zoals TMap Test Engineer en ISTQB Foundation. Uiteraard gebaseerd op de theorie, maar altijd doorspekt met ervaringen uit de vele projecten en omgevingen.
Gebruiksvriendelijkheid
In een van de medische projecten pakte initieel niemand de noodzaak om te het voldoen ISO-62366 op. Interessant! Wat is dat? Wiki: ‘The international standard IEC 62366 medical devices – Application of usability engineering to medical devices[1] is a standard which specifies usability requirements for the development of medical devices’. Een nieuwe ‘T’ was geboren.
Ik kreeg de kans om me in usability te verdiepen. Ik tuigde een ‘usability test program’ op waarbij we reviews uitvoerden op basis van de 10 Heuristics van Nielsen en usability testen organiseerde met echte eindgebruikers uit laboratoria.
Enkele jaren en projecten later mocht ik het nog eens ‘DIK’ overdoen door het gehele usability traject op te zetten voor een ander nieuw medisch apparaat. Van analyse van de gebruikers, het definiëren van de usability requirements, tot en met het usability testen: internationaal, met gebruikers in ziekenhuizen en labs tot in Frankfurt, Oslo, en Philadelphia aan toe.
Automotive
Oude liefde roest niet. Dus toen ik de kans kreeg om mijn kennis en ervaring over gereguleerde omgevingen te vertalen naar de automotive greep ik die kans uiteraard aan. Bij DAF mocht ik een testteam gaan opbouwen voor een nieuw ‘voertuig controller’ ofwel de voertuig-ECU. Tel daarbij op mijn oude liefde voor vrachtwagens en mijn hobby het rijden in en met Land Rovers, dan kun je je voorstellen dat een andere ‘T’ bovenwater komt.
Inmiddels diverse automotive opdrachten verder heb ik me verdiept in procesmodellen voor de automotive zoals Automotive-SPICE en help ik organisaties en teams met het pragmatisch trainen en implementeren daarvan.
Requirements Engineering
Als tester ervaren we natuurlijk uit de eerste hand als niet duidelijk is hoe het systeem zou moeten werken. De brug naar Requirements Engineering (RE) is daarmee geslagen. Vanuit mijn brede interesse en kwaliteitszin ben ik me uiteraard ook daarmee gaan ‘bemoeien’ en is de volgende ‘T’ ontstaan. Ok, ik geef nog geen trainingen maar werk wel mee aan de syllabus van CARE: Capturing Agile Requirements by Example en praat mee over Living Documentation.
Samen met enkele collega’s schrijven we wekelijks op LinkedIn een blog over onderwerpen die ons opvallen of waar we tegenaan lopen in het RE-vak. Inmiddels zitten we op 25 posts en er is nog inspiratie genoeg.
T or M-shaped?
Als ik zo mijn memoires terugkijk zie ik zoveel T’s dat ik T-Shaped eigenlijk tekort vind schieten. Ik zie meer overeenkomsten met een M en zelfs dat doet wellicht tekort. Wellicht een Grote Gele M? Niet per se die je langs de snelweg ziet, maar ik zie wel een verband.
En als ik verder lees op Wikipedia bij T-shaped zie ik daar twee verwijzingen:
- Versatilist, ofwel veelzijdigheidsdeskundige: iemand die specialist kan zijn in een bepaalde discipline en tegelijkertijd met relatief gemak kan wisselen naar een andere rol.
- Multiple Mountains, ‘R-‘ en ‘M-shaped’ individuen. Hierbij doelend op mensen met sterke punten op computationeel en software-intensieve gebieden.
Op basis daarvan kom ik wel tot de conclusie dat het wel op mij van toepassing is.
Komt het door carrièreplanning? Wat mij betreft niet. De meeste keuzes zijn ontstaan omdat er zich kansen voordeden en ik die heb aangegrepen gedreven door mijn brede interesse.
Een vraag staat nog open: hebben andere testers (en ontwikkelaars) dat ook? Daar heb ik niet zo’n onderbouwd antwoord op. Ik ben eigenlijk wel benieuwd of je die brede interesse bij jezelf herkent. Laat het me eens weten! Patrick.Duisters@ImproveQS.nl of via LinkedIn.
En nu?
Tijd voor een nieuwe ‘T’? Yep. Informatiebeveiliging wordt steeds belangrijker. En omdat er qua processen en verbetertrajecten best wat overeenkomsten zijn, ga ik de komende tijd aan de slag om ook die vertaalslag te maken.