We houden ons met z’n allen al weer een tijdje bezig met testen en de processen daaromheen. Ikzelf formeel zo sinds 1994, anderen al veel langer. Een veel gehoorde opmerking is dat we gedurende die tijd niet zoveel nieuws geleerd hebben, dat aan het begin van de ontwikkeling van het testen (zo rond 1979) de fundamenten zijn gelegd en dat die niet opzienbarend veel zijn veranderd.
Bij veel organisaties en bedrijven blijken dezelfde basisprincipes met betrekking tot testen nog steeds te gelden: je treft een goedbedoelde “chaos” aan en de eerste verbeterstappen bestaan uit het structureren van het testproces, het proberen om testrollen te definiëren en bewustzijn te verbeteren.
Daarbij zie ik een fundamenteel verschil tussen “Europees” en “Amerikaans” testen. Waar de Europeaan zich richt op het aantonen dat het product zonder al teveel risico’s in productie kan worden genomen, richt de Amerikaan zich meer op het vinden van fouten. Dit blijkt uit de testtechnieken die in deze twee verschillende werelden worden gebruikt.
Ik zeg niet dat er geen vermenging ontstaat; bij ons hoor je meer en meer dat technieken als exploratory testing in combinatie met scripted testing worden toegepast. Maar ET vindt over de plas nog steeds meer plaats dan hier. En natuurlijk zijn er veranderingen in het testproces waarneembaar maar deze zijn meestal ingegeven door de verandering in de systeemontwikkeling en beheer, zoals agile en cloud.
In bijna alle gevallen dat we over productkwaliteit hebben gaat het over het testproces en we hebben een aantal jaren geleden bedacht dat het verbeteren van dat proces een elementaire actie is om tot betere producten te komen. Methoden als TPI (-Next) en TMMi worden toegepast om de volwassenheid van het proces te meten en met de resultaten van die meting de verbetering vorm te geven. We zijn inderdaad in staat gebleken bij een groot aantal organisaties het testproces naar een hoger volwassenheidsniveau te brengen
Ik zie echter een keerzijde van deze aanpak: de tester loopt zover voorop dat de businessanalist, systeemontwikkelaar en de business het soms niet meer kunnen bijhouden. Hoe vaak is het niet de testmanager die aangeeft waar de zwakke plekken in het voortbrengingsproces binnen een organisatie zitten? Testers hebben behoefte aan een goed functionerend configuratiemanagement, een projectmanagement dat aligned is enzovoort.
En nu gaan we nog een stapje verder: we zien dat het testproces wel erg zwaar wordt en daarom onderzoeken we mogelijkheden om het proces “Lean” te maken en waste uit te bannen, onder andere door wachttijden – een belangrijke waste in het testproces - te verkorten. Echter, deze wachttijden nemen juist toe als gevolg van optimalisatie van het testproces! Immers, de testers hebben sneller door wat er fout gaat en er worden met hogere frequentie bevindingen in het administratiesysteem opgenomen met als gevolg dat systeemontwikkeling het niet meer kan bijhouden.
De focus zou dus moeten verschuiven van verbeteren van het testproces naar verbetering van het systeemontwikkelingsproces. Testen loopt voorop en daar kunnen we gebruik van maken; bijvoorbeeld door middel van oorzaakanalyses uitmondend in verbetervoorstellen voor het gehele proces. Zo kunnen we komen tot een optimaal systeemontwikkelingsproces waarin het testproces is geïntegreerd.
Dus niet via Test Proces Improvement maar via Test Proces Integration naar verbetering van de productkwaliteit!
————————————
© Chris C. Schotanus, Principal IT Consultant
Logica Testing & Quality Management
Testen maakt onlosmakelijk deel uit van het ontwikkelproces, dus “test process integration” is niet nodig. Door producten van ontwerpers en bouwers kritisch te beoordelen dragen testers bij aan de verbetering van ontwerpactiviteiten en programmeeractiviteiten. Daarnaast is iedere ontwikkelaar, of het nu een ontwerper, een programmeur of een tester is, verantwoordelijk voor continue vergroting van zijn eigen vakmanschap. Misschien dat sommigen daar hulp bij kunnen gebruiken, maar het is niet nodig om testprocesverbetering daarom tijdelijk stil te zetten.
Beste Chris,
Je hebt het over “een fundamenteel verschil tussen ‘Europees’ en ‘Amerikaans’ testen”.
Je noteert twee verschillen tussen de aanpak van testen op de verschillende continenten. Je stelt dat de ‘twee werelden’ verschillende testtechnieken gebruiken. Ik ben benieuwd naar de verschillen die je ziet. En je stelt dat Europa zich richt op risico’s en Amerika op het vinden van fouten. Heb je hier voorbeelden van?
Je categoriseert de manier waarop testen benaderd wordt naar geografische locatie. Daar is op zich wat voor te zeggen maar het onderscheid kan naar mijn mening helderder worden weergegeven door gebruik te maken van de ’schools of testing’ zoals geidentificeerd door Bret Pettichord.
Op het Europese continent houden we ons waarschijnlijk voornamelijk bezig met het testproces; de ‘factory/standard school’ in Pettichord’s classificering. In de Verenigde Staten is de ‘context-driven school’ erg in opkomst.
Als je een onderscheid maakt naar de manier waarop deze twee scholen kijken naar het verbeteren van testen dan zie je inderdaad grote verschillen. Onze factory school verkeert in de veronderstelling dat we testen kunnen verbeteren door het strikt implementeren en reguleren van formeel uitgeschreven en afgebakende werkzaamheden.
Een nuancering met betrekking tot geografische locatie die ik hierbij wil aanbrengen is dat onze ‘Europese benadering’ voor het merendeel stoelt op Amerikaans onderzoek, gedaan in de jaren zeventig en tachtig door onder andere Barry Boehm, Boris Beizer, Tom Gilb, Watts Humphrey, Frederick Brooks, William Howden, Capers Jones, Gerald Weinberg, William Hetzel, David Parnas, Philip Crosby, Allan Albrecht, James Martin, Michael Fagan, John Musa, Victor Basili, David Gelperin, Thomas McCabe, Walter Edwards Deming, Edward Yourdon, Tom DeMarco en Cem Kaner. En als we het dan toch over testmethodieken hebben dan denk ik dat bijvoorbeeld ‘onze’ TMap voor een groot deel schatplichtig is aan de namen die ik hiervoor genoemd heb. Een zuiver onderscheid tussen een Europese en Amerikaanse benadering is dus niet te maken.
Een van de belangrijkste bevindingen die naar mijn mening aanleiding heeft gegeven tot het ontstaan van de context-driven school is dat juist software ontwikkeling zich niet in het formele productieproces laat vangen. Of nauwkeuriger; dat onze manier van proces- en productiematig ontwikkelen van software voorwaarden stelt die niet aansluiten bij de karakteristieken van software. De belangrijkste karakteristiek is dat software, het inzicht in het software product, altijd, dus ook tijdens het ontwikkelproces, evolueert/verandert. Zoals Michael Bolton stelde tijdens zijn key note op het TestNet voorjaarsevenement: waarom zouden we een test plan gaan uitwerken aan het begin van het project, op het moment dat we het minste van het software product weten?
Wat je constateert, de “goedbedoelde ‘chaos’”, is naar mijn mening niet het gevolg van het ontbreken van een proces maar juist het gevolg/symptoom van pogingen om een proces te implementeren waarvan de voorwaarden niet aansluiten bij hetgeen de organisatie probeert te bereiken.
Dat wij als testers ons bezig moeten gaan houden met het omvormen van de organisatiestructuur en de bedrijfscultuur zodat deze aansluiten bij het proces dat wij als testers (graag?) zouden willen volgen is voor mijn gevoel discutabel. Los van het feit dat we als testers expliciet en met een goede reden niet beschikken over de positie, de kennis en de vaardigheden om dat te doen.
Vriendelijke groet,
Joris
@Joris, goede aanvullingen/vragen is er wel een geografische opdeling.
@Chris, verbeteren van processen heeft altijd te maken met de omgeving immers krijg je anders sub optimalisatie. Een goede verbeteraar kijkt verder dan slechts testen. Testen krijg je nooit goed als je niet kijkt naar de anderen. Volgens mij is dit geheel werelddeel onafhankelijk.
Het gaat dus niet om test proces verbetering, maar ik zou me meer de vraag stellen, hoe kan ik de omgeving beïnvloeden zodat ik zo gemakkelijk als mogelijk mijn werkzaamheden kan uitvoeren, ongeacht the school of testing.