Testen met testtools – slapend werken?

Auteurs: Maurice Siteur ● maurice.siteur@capgemini.com & Rob van Steenbergen ● redactie@testnet.org

Rob van Steenbergen:
Ik heb het boek doorgebladerd en kwam bij de paragraaf ‘Toekomstig testscenario’ het volgende tegen: ‘Al filosoferend zou je tot het volgende testscenario kunnen komen, dat in een jaar of tien een feit zou kunnen zijn: Functionele ontwerpen worden in gestructureerd Nederlands opgezet of omgezet. Een SCA-testtool beoordeelt de kwaliteit van het ontwerp. Testontwerptool maakt testontwerp. Deze testontwerpen kunnen ingelezen worden in de capture/playback testtool. Het enige wat nog moet gebeuren, is het controleren of de uitvoer van de testgevallen wel conform de verwachtingen is.’
Het lijkt veel op wat we nu noemen, Model Based Testing (MBT).
Maurice reageert:
‘Dit is nog steeds in ontwikkeling dertien jaar later. Het wordt bij sommige bedrijven gebruikt, maar is zeker nog geen gemeengoed. MBT is zeker wel populairder geworden. Er zijn allerlei tools op de markt, die het toch allemaal wat anders doen. In de SAP hoek zie je mooie voorbeelden van geïntegreerde testoplossingen.’

De wereld van de testautomatisering heeft zeker niet stil gezeten. Cloud, Agile, internet zijn er gekomen met een veelvoud aan tools. De weg kwijtraken in het bos van testtools is geen enkel probleem. Was vroeger het aantal defectmanagementtools enorm, nu lijkt elk type tool genoeg varianten te hebben.
Vijf jaar later in 2005 heeft Maurice een Engelse versie van zijn boek geschreven en daarin stond:
‘Test generation will be the key to success. Testing, even automatic testing, takes too long to set up and maintain. Test suites that have to be changed will be regenerated. Capture and playback tools will be used to execute the generated tests. Better testing must be accompanied by better development using tools for unit testing and static analysis. Development means delivering software with little to no error.
The ideal test tool does not exist at this moment and will not exist in the future. The tester will use different tools for different purposes. The best tester will be the one with the best set of tools, both commercial and free. Free tools have a future, because some of them are very good and simple enough to be used effectively. For the next couple of years test tool integration will be important.’
In zijn poging er een derde versie van te maken heeft hij het volgende geschreven:
‘The ideal test tool does not exist at this moment and will not exist in the future. The tester will use different tools for different purposes. The best tester will be the one with the best set of tools, both commercial and free. Free tools have a future, because some of them are very good and simple enough to be used effectively.

Tools are so different. Integrating tools seems not to be wise. That would require complete reengineering of tools. The past learned that tools are built for a certain functionality and should stick to that. For the next couple of years test tool integration will be important. Open APIs are needed to make this happen. Tools that work together are vital for the efficiency improvements needed.’
Maurice zijn opmerking hierover:
‘Testautomatisering is springlevend en zolang testen dat is, zullen de hulpmiddelen er ook zijn. Toch sprak ik onlangs een manager van HP op de HP Discover in Barcelona. Die zag dat steeds meer hardware-matige zaken software worden. Alles krijgt een sensor. De wereld verandert door. De snelheid van de mogelijkheden idem dito. Zijn we met testen überhaupt wel in staat om tempo te volgen? En dat is niet alleen het probleem voor testen.

Slapend werken is nog ver weg, maar als we de programmeersnelheid van sommige Agile projecten kunnen vertalen naar kwalitatief goed werkende software over een brede linie, dan zie ik nog licht aan het einde van de tunnel. Alleen als dat ‘Testing by incident’ wordt, dan gaan we toch de kant van de kwaliteitsregisseur op.’
Misschien Maurice jaarlijks maar eens een visie vragen van waar we naar toe gaan?