Een te groot vertrouwen op hergebruik van dezelfde test, is één van de meest voorkomende misverstanden bij het testen van software. Dat zegt Cem Kaner, professor in software engineering en auteur van de bestseller Lessons learned in software testing. 'We noemen dat regressie-testen, maar je kunt het beter helemaal-niet-testen noemen.' Kaner komt in oktober naar Nederland om een driedaagse workshop aan testers te geven.
Wat kan een testgroep doen om de kwaliteit van hun werk te verbeteren?
Eén van de meest voorkomende misverstanden in software testen is om te zwaar te vertrouwen op het hergebruik van dezelfde test, steeds opnieuw. We noemen dat regressie-testen, maar je kunt het beter helemaal-niet-testen noemen. Dat soort tests leveren het meeste op wanneer ze voor het eerst worden gedraaid.
Het testen van software is niet hetzelfde als het controleren van onderdelen op een lopende band: softwaretesters zijn niet op zoek naar problemen die in één op de honderd exemplaren voorkomen. We zijn op zoek naar nieuwe manieren waarop een product zou kunnen worden gebruikt, die bugs aan het licht kunnen brengen die we nog niet eerder gecontroleerd hebben.
Wat maakt het verschil tussen een goede en slechte tester?
Testen is een empirisch onderzoek. Elke test is een experiment. Competente testers ontwikkelen onderzoeksvaardigheden. Ze leren allerlei verschillende technieken aan en passen ze toe waar nodig. Bijvoorbeeld: wanneer je me vraagt de kosten te schatten van het ondersteunen van een product in het veld, test ik op een andere manier dan wanneer je me vraagt om díe bugs te vinden die ervoor zorgen dat de kosten van diezelfde ondersteuning zo laag mogelijk worden.
En ik test wéér anders als je me vraagt om een product te vergelijken met de productspecificaties. Competente testers rapporteren daarnaast hun bevindingen helder, beknopt, en op zo'n manier dat de gevolgen ervan duidelijk worden. Minder competente testers zijn meer geneigd conflicten aan te gaan over het 'proces', dan dat ze zich bezighouden met het managen van hun eigen werk. Ze laten te veel van hun mening zien en te weinig data.
Wat is belangrijker: software op tijd leveren, of software leveren zonder bugs?
Ik denk niet dat het mogelijk is producten zonder bugs te leveren, omdat het onmogelijk is om een programma volledig te testen. Je kunt echter wel rekening houden met twee realistische trade-offs. Ten eerste: hoe kunnen we ons ontwikkelproces aanpassen zo dat de kans op fouten zo klein mogelijk wordt?
En: hoe besluiten we, wanneer we eenmaal een probleem gevonden hebben, of we het gaan repareren? Aan ontwikkelprocessen die zijn geoptimaliseerd om het gemakkelijk en goedkoopmaken om het ontwerp of de implementatie van een product aan te passen, ook laat in het proces, geef ik de voorkeur. Boven processen die zijn ingericht om een product in een vroege fase schijnbaar te controleren.
Testmanagers hebben geen controle over het ontwikkelproces. Hun invloed licht meer in het helpen van het ontwikkelteam met het verantwoord evalueren van bugs. Er is geen een bedrijf dat alle bugs repareert. De uitdaging is om te bepalen welke bugs de grootste invloed hebben op gebruikers. Hoe beter het onderzoek door de testers, hoe beter het ontwikkelteam hierover beslissingen kan nemen.
Hoe kan een projectmanager het werk van een testgroep vergemakkelijken?
Idealiter door schone en testbare code aan te leveren, bijvoorbeeld via een 'agile' ontwikkelingsproces. De realiteit is echter dat bedrijven vaak werken met twintig jaar oude legacy software, en die niet zomaar volledig kunnen herschrijven. Dan kan een projectmanager er alleen voor zorgen dat een testgroep voldoende budget heeft, en dat er goed naar hen wordt geluisterd.
Hoe ga je als tester om met een projectmanager die het halen van deadlines boven alles stelt?
Dat is heel moeilijk. Dat soort mensen verliezen hun baan uiteindelijk. Ik ken een aantal directeuren die zulke slechte beslissingen hebben genomen dat ze nooit meer aan de slag kwamen in de Silicon Valley. Maar ze kunnen een hoop schade aanrichten, en vaak ook een hoop geld verdienen, voordat ze het veld ruimen.
Het is echter een veel voorkomende fout van testmanagers om de strijd aan te gaan met projectmanagers. Test managers kunnen meer invloed hebben door zich ervan te verzekeren dat de juiste mensen de juiste gegevens krijgen dan door zich bezig te houden met kantoorpolitiek.
Durft u een schatting te maken van het percentage software dat ongetest op de markt verschijnt?
Nul procent. Programmeurs testen op zijn minst hun eigen code. Er zijn twee soorten bugs: publieke en private. Publieke bugs worden ontdekt door een tester of een gebruiker, privébugs door de ontwikkelaar zelf. Door gebruik te maken van compilers, debugging tools, en simpelweg door hun eigen code na te lezen, vinden ontwikkelaars ruim negentig procent van hun eigen bugs.
Er zijn ook ontwikkelgroepen die zo'n hoog kwaliteitsbewustzijn hebben, dat ik ze afraad om hun software te laten testen. Dat zou er alleen maar toe leiden dat ontwikkelaars hun code slechter nakijken. De meeste ontwikkelgroepen hebben echter de assistentie van testexperts nodig.
Wanneer een bedrijf een slecht product op de markt brengt, kun je nooit zeggen hoe dat komt: of het product niet goed getest is, of dat de belangrijke bugs wel zijn gevonden maar niet gerepareerd. In ieder geval, het grootste probleem is de keuze van zo'n bedrijf om er een gewoonte van te maken om het ene na het andere slechte product op de markt te brengen. Slecht testen is alleen maar een symptoom van een dieperliggende ziekte.
Cem Kaner
Cem Kaner is Professor in Software Engineering op het Florida Institute of Technology en Directeur van het Center for Software Testing Education & Research van Florida Tech. Hij doceert en doet onderzoek naar software engineering, waarbij de nadruk ligt op het testen van software, softwaremetrieken en computerwetgeving en -ethiek. In zijn carrière staat steeds hetzelfde thema centraal: het verbeteren van de tevredenheid en veiligheid van klanten, -gebruikers en -ontwikkelaars van software. Hij schreef, samen met Bret Pettichord en James Bach, het standaardwerk 'Lessons Learned in Software Testing'.
Cem Kanerweek
Wil jij weten hoe Cem Kaner aankijkt tegen de huidige crisis? Wat betekent de crisis voor ons als Test Professionals en welke kansen biedt het? Welke lessen hebben we eerder geleerd en moeten we nu niet vergeten toe te passen? En welke test technieken komen nu het beste van pas? Immune.IT presenteert van 26 tot en met 28 oktober 2009 Cem Kaner – De Workshop.
Vijf lessen
Dit is een lijstje met vijf 'lessons learned' die testcoördinator Willem ten Brinke van Immune.IT na aan het hart liggen:
Lesson 26 – Intuition is a fine beginning, but a lousy conclusion
Vaak zegt je gevoel dat iets fout of goed is; dit is op zichzelf geen verkeerd vertrekpunt. Zorg er echterwel voor dat je testresultaten altijd gefundeerd zijn en niet slechts op basis van een "gevoel".
Lesson 40 – You're harder to fool if you know you're a fool
Wij 'testers' zijn ook mensen, ook wij maken fouten. Door je daar van bewust te zijn, ben je alerter op eigen en andermans fouten. Het is een gemakkelijk toe te passen verbetering, aangezien het een houdingsaspect betreft. Je hoeft er geen cursus voor te volgen of ervaring mee op te doen.
Lesson 85 – Report the problem clearly, but don't try to solve it
Een valkuil voor veel testers is om bij het vastleggen van defects zelf te veel in de "oplossende modus" mee te gaan denken. Onze taak is het om de defects zo nauwkeurig mogelijk te rapporteren. Wanneer je als tester de vermoedelijke oorzaak denkt bloot te leggen of zelfs de uiteindelijke oplossing dekt aan te kunnen dragen zonder onderliggende kennis van programmacode en/of de beweegredenen van ontwerpers, dan loop je het risico de verkeerde conclusie te trekken waardoor jouw bevinding vrijwel zeker geweigerd zal worden.
Lesson 185 – 'Enough testing' means 'enough information for my clients to make good decisions'
100% testen is ondoenlijk en doorgaans ook niet nodig. Het gaat erom voldoende informatie te kunnen verschaffen voor de beslissingen die genomen moeten worden. Dus: niet testen tot alle defects gevonden zijn maar totdat je redelijkerwijs kunt aangeven dat de kans gering is dat het product nog belangrijke onontdekte fouten bevat.
Dit geeft het belang aan van een risk-based teststrategie en testplanning.
Lesson 276 – The real test plan is the set of ideas that guides your test process
Vaak wordt een (master) testplan opgesteld door middel van het invullen van een omvangrijke template. In deze exercitie wordt nogal eens voorbijgegaan aan de essentie van een testplan. Les 276 geeft aan dat een testplan geen lijvig document hoeft te zijn, zolang het maar de richtingbepalende aspecten in jouw testproces bevat.
Bron: Kaner, Cem; James Bach & Bret Pettichord (15 December 2001). Margaret Eldridge. ed. Lessons Learned in Software Testing: A Context-driven Approach. New York: Wiley. LCC QA76.76.T48 K34 2001 ISBN 0-471-08112-4.
Cem Kan weet natuurlijk wel dat een regressietest niet simpelweg uit een set oude tests bestaat. Maar of onze psychologe dat ook weet.
Na de invoering is nieuwe functionaliteit oude functionaliteit geworden en kan het daarna onderwerp van een regressietestset worden. Verdwenen functionaliteit moet uit de regressietestset gehaald worden.
Nul procent van de software komt ongetest op de markt. Het gaat er om hoe er getest wordt en een regressietest is noodzakelijk indien je releasematig werkt.
Ik ben zeer benieuwd wat onze amerikaanse software testprofessor naar NL denkt te exporteren en hoe hij tegen Tmap Next aankijkt. Mijn mening is dat Tmap Next een mooi staaltje verkoopsucces is van Sogeti.