Op de eerste plaats wil ik iedereen bedanken voor de uitgebreide reacties op de column De toekomst van testen: De 10. Mooi om te zien dat mijn stellingen zoveel constructieve reacties oproepen. Ze zijn inderdaad directief gesteld. Enerzijds is dat het karakter van de stellingen, anderzijds heb ik dit bewust gedaan om te prikkelen. Dat is mooi gelukt.
Een van de opmerkingen is dat als ik deze column 4 jaar geleden had geschreven de stellingen ook waar waren. Daar ben ik het volledig mee eens en daar zit ook mijn punt. Ik heb al regelmatig in andere publicaties aangegeven dat we ons als testcommunity moeten doorontwikkelen. We blijven stilstaan en dreigen langzaam aan achterop te raken bij andere delen van de IT industrie. Een zorgelijke ontwikkeling. Dat was een van de redenen om deze column te schrijven. We zullen echt de handen ineen moeten slaan om door te groeien naar een volgend volwassenheidsniveau. Daar moeten we inderdaad zowel proces als product kwaliteit in meenemen. Productkwaliteit heb ik meegenomen in stelling 6,7 en 8. Proceskwaliteit onder andere in stelling 2,3 en 4. Echter, er is een breed scala aan maatregelen nodig om het vak een stap verder te brengen. Dat zie je ook wel in de feedback terugkomen. Er is niet een punt dat we even moeten aanpakken en klaar is Kees. Nee, we zullen daar fundamentele stappen in moeten zetten. Mijn overtuiging is dat we daarvoor buiten betreden paden moeten treden. Ontwikkelingen zoals context-driven development zouden elementen kunnen zijn.
Is dit wishful thinking? Absoluut niet. In mijn ogen een harde realiteit waar we stevig mee aan de gang moeten. Als testers moeten we niet meedenken dat we het werk wel af krijgen in een bepaalde periode terwijl de scope aan alle kanten beweegt en schuift. Of denken daar zitten geen risico’s. De laatste weken worden we bijna dagelijks geconfronteerd in het nieuws met grote problemen in de IT voorziening. Daarin kunnen we als testers nog forse stappen voorwaarts maken.
Teven ben ik ervan overtuigd dat we ook over de grenzen van test heen moeten kijken. We zullen gebruik moeten maken van expertise en samen moeten werken met andere vakgebieden. Dat wil niet zeggen dat dat de stap is naar het volgende volwassenheidsniveau van test. Nee, dan blijf je aanhaken bij de ontwikkelingen in de industrie. Uiteraard ook bijzonder noodzakelijk. Als test zelf moeten we verder professionaliseren en daar zit de uitdaging en de link naar deze column. Weten we dat in te vullen dan kunnen we de komende jaren met vertrouwen tegemoet zien. Echter, dat gaat niet vanzelf! We zullen echt aan het werk moeten.
Kortom, mijn initiële oproep blijft staan. Wie durft? Meld je aan en ik zal een eerste sessie organiseren!
————————
Jos van Rooyen is senior testadviseur/ principal consultant testen bij Bartosz ICT bv
Jos,
Dank voor je reactie! Goed om te zien dat je er op door gaat. Een zin in het bijzonder roepen wel wat vragen bij me op:
“We blijven stilstaan en dreigen langzaam aan achterop te raken bij andere delen van de IT industrie.”
Kun je dit eens onderbouwen? Op basis van welke waarnemingen concludeer je dit? En hoe is dit gerelateerd aan de vragen die ik noem in mijn reactie op je vorige column?
“De laatste weken worden we bijna dagelijks geconfronteerd in het nieuws met grote problemen in de IT voorziening. Daarin kunnen we als testers nog forse stappen voorwaarts maken.”
Ligt dat dan aan de tester die “slechts” een advies geeft wat blijkbaar niet wordt opgevolgd of aan druk van buiten een IT-organisatie op diezelfde tester om zijn werk maar af te raffelen om de aanpassing het liefst vorige week al in productie te hebben. De organisatiepolitiek even buiten beschouwing latend.
Je vraagt “ligt dat dan aan de tester die slechts een advies geeft”. Wat is je achterliggende gedachte daarbij? In mijn ogen geeft de tester inderdaad een advies, over de kwaliteit van het geteste product en de eventuele risico’s die men neemt met in productie name. En dan is het aan de beslissingsbevoegden om er al dan niet naar te luisteren. Als men besluit een product in productie te nemen, terwijl de kwaliteit onvoldoende is, kan dat dus niet aan de tester liggen.
@David: Dat is eigenlijk de (deel)vraag die ik aan Jos stelde aangezien hij de oorzaak van een probleem (deels) neerlegt bij “de tester”.
Hierop voortbordurend: Wat zouden wij, in de rol die je benoemd, dan nog aan moeten passen om die forse stap voorwaarts te kunnen maken?
Aanpassingen in methoden en technieken zijn maar een deel van de oplossing, maar zullen niet zaligmakend zijn. Een verandering van attitude t.o.v. het werk helpt ook, maar de meesten willen hun partner ook wel eens zien (of niet..) buiten de reguliere slaaptijden om.
Blijft eigenlijk het afdwingen van een verandering in de organisatie attitude over om de werkelijke “klant en zijn haar behoefte” weer centraal te stellen en niet langer “de aandeelhouder” die een zo hoog mogelijk ROI wil hebben en een organisatie daardoor dwingt om de infrastructuur langer dan noodzakelijk te benutten.
maar daar heb ik (bij wijze van schrijven) helemaal geen zin in, want ik ben tester, geen psychiater of psycholoog
Het is natuurlijk niet zo dat testers alleen verantwoordelijk zijn voor de uiteindelijke kwaliteit van het informatiesysteem. De tester geeft een advies en de beslissers kunnen daar gebruik van maken. Dat is best wel gemakkelijk. Volgt men het advies niet op dan kun je altijd zeggen; zie je wel, ik heb het wel gezegd. Neem men het advies over dan is dat natuurlijk goed. Wat ik wil meegeven is dat we als testers best stevig positie mogen innemen als uit de testen blijkt dat het benodigde kwaliteitsniveau niet bereikt is. Dan ga je inderdaad wat verder dan alleen advies brengen. Je gaat nadrukkelijk meepraten en evt. meebeslissen. Dan komen we als testers waar we eigenlijk moeten zitten. In de cockpit van het project.
De ene softwaretester is de andere niet, maar voor mij is de essentie van een goede test destructief. Aantonen dat een product werkt volgens specificaties is niet spannend. Het moet wel gebeuren, maar er is weinig eer aan te behalen. Als de test slaagt, is dat volgens verwachting en dus geen nieuws. Als de test niet slaagt, heeft iemand zijn werk niet goed gedaan en dat is slecht nieuws. Het wordt pas leuk als je, buiten de specificaties om, situaties bedenkt waarin het fout kan gaan. Als het dan inderdaad fout gaat, ontstaat er een kans om het product te verbeteren. In principe is dat goed nieuws.