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.
Om te stellen dat regressietesten helemaal-niet-testen is gaat mij echt veel te ver. Goede regressietests geven duizenden softwarebedrijven dag-in-dag-uit (zeker als ze automatisch na een nightly build worden uitgevoerd) de garantie dat er in ieder geval niets is “omgevallen” in de code. Regressietests zijn ook niet statisch en zouden zoveel mogelijk code coverage moeten bieden. Dat kan niet gelijk, maar zal groeien naarmate het software product volwassener wordt.
“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.”
In een omgeving waar het testen als dicipline en als proces niet bekend is zal een tester dit juist moeten doen.
Cem Kaner maakt exact dezelfde fout als alle TMAP aanhangers in Nederland, namelijk dat ze als doelstelling hanteren : het natreven van een perfecte testmethode en testproces, terwijl het doel meot zijn: het leveren van een kwalitatief goed product binnen het geplande budget en voor de geplande deadlineen binnen het kader wat door bestaande bedijfsprocessen en opvattingen wordt gedicteerd.
Ik sluit me volledig aan bij null.
Hoe meer coverage de regressietest heeft, hoe waardevoller deze is. Het doel moet inderdaad zijn om te kijken “of er niets is omgevallen”, niet voor het testen van nieuwe functionaliteit.
Bij mijn huidige klant werken ze op dezelfde manier: een regressietest om aan te tonen dat er niets is omgevallen, en vervolgens wordt getest of de nieuwe/gewijzigde code ook doet wat het moet doen.
Idealiter worden deze nieuwe testen vervolgens weer toegevoegd aan de regressie-test-kit.
De uitdaging is om de regressietest zo volledig mogelijk te houden, maar dat deze nog wel binnen de gestelde tijd te draaien is.
Zou zijn workshop graag willen volgen, ben het namelijk met weinig eens in z`n artikel.
Voorbeeld:
Op de vraag: “Hoe kan een projectmanager het werk van een testgroep vergemakkelijken?”
Antwoord hij: “Idealiter door schone en testbare code aan te leveren, bijvoorbeeld via een ‘agile’ ontwikkelingsproces.”
Alsof:
– De projectmanager de code schrijft? Volgens mij moet hij het project besturen en maakt het niet uit welke code er achter zit
– Agile schone code oplevert? Volgens mij doen de ontwikkelaars dat ongeacht de methode
– het om schone en testbare code gaat in plaats van goede code in overeenstemming met de requirements
Hoop dat er wat presentaties online komen.
@Frans:
TMap heeft niet het doel overal hetzelfde perfecte proces neer te zetten maar aan te sluiten bij de klant z`n testdoelen (twee belangrijke aspecten van TMap zijn juist Business Driven en Adaptief)
De schrijver van het artikel lijkt te suggereren dat het veel voorkomt dat testers zonder na te denken alleen regressietesten uitvoeren. Als dit inderdaad op grote schaal het geval zou zijn heeft hij een punt. Dat is echter niet de praktijk die ik als testmanager ervaar. Meestal controleren testers eerst de gewijzigde software en voeren zij vervolgens en indien nodig regressietesten uit. De tijd die testers krijgen voor het testen van de wijzigingen en het uitvoeren van regressietesten is afhankelijk van het risico dat door de organisatie is ingeschat. Als een organisatie veel last heeft van productieverstoringen als gevolg van het optreden van regressie kan het uitvoeren van regressietesten een prima maatregel zijn om productieverstoringen te beperken. Uiteraard wel in combinatie met maatregelen om het optreden van regressie in de software zoveel mogelijk te voorkomen.
In de praktijk kom ik nog wel vaak tegen dat organisaties regressietesten routinematig uitvoeren. In veel gevallen vindt dan vooraf geen afweging plaats of de uitvoer van regressietesten in het betreffende geval wel noodzakelijk is. Dan kan regressietesten onnodig veel tijd kosten. Zeker als men regressietesten interpreteert als het herhalen van alle beschikbare testscripts.
De titel van het artikel is denk ik provocerend opgesteld en ik ga mee in de reacties dat het op punten wat kort door de bocht gaat.
Ik heb zelf het boek “Lessons learned” in de kast staan en heb de hoofdstukken over regressie-testen er nog eens bijgepakt. Vooral de les “Automated regression test die” spreekt mij wel aan.
Ik heb het in de praktijk meegemaakt dat er bij een klant jarenlang gebruik werd gemaakt van dezelfde automatische testset terwijl er niemand meer in dienst was die inhoudelijk wist wat er getest werd en hoe afwijkingen te verklaren waren.
Ik sluit mij aan bij Johan Vink dat regressietesten een prima aanvulling kan zijn in de mix van test-technieken. Maar dan moet er wel goed mee worden omgegaan. (dat geldt natuurlijk voor alle test technieken)
Een discussie met Cem Kaner en de personen die hierboven hebben gereageerd lijkt mij niet verkeerd!
Ik denk dat de schrijver van dit artikel de uitspraken van Cem Kaner hier en daar wat aangescherpt heeft, ik geloof namelijk niet dat deze “Goeroe” zomaar roept dat regressietesten geen testen is.
Het gaat denk ik meer om de zin: “Een van de meestvoorkomende misverstanden in softwaretesten is om te zwaar te vertrouwen op het hergebruik van dezelfde test, steeds opnieuw”. Zijn kritiek zal met name gericht zijn op het blindelings vertrouwen van de bestaande testset en de vanzelfsprekendheid dat alles nog goed werkt alleen omdat de regressietest geen fouten aan heeft getoond. Wat is de conclusie als er wel fouten uit de regressietest komt, de regressieset heeft zijn nut bewezen of de tester heeft zijn analyse werk niet goed genoeg gedaan?
@Andreas:
– De projectmanager is wel degelijk verantwoordelijk voor het opleveren van de code.
– ontwikkelaars leveren (helaas) veel te weinig schone code
Als je het zo wienig met hem eens bent, waarom schrijf je je dan niet in voor de presentatie of workshop?
@Frans:
Als er bij een organisatie geen standaard testproces is, zal de tester juist dan volgens bepaalde methode moeten gaan werken. Discussies over processen moet je overlaten aan procesanalisten en ervaren testers die al heel lang meelopen in de organisatie.
Met TMap ben je niet bezig om de perfectie na te streven. Het is een hulpmiddel om zaken gestructureerd op te zetten. Overigens leveren testers geen kwaliteit, de testers constateren de mate van kwaliteit van het opgeleverde product!
@Nico n.a.v. opmerking Andreas:
De projectmanager is inderdaad verantwoordelijk voor het opleveren van de code. Ook is hij verantwoordelijk voor het opleveren van “kwalitatief goede” code. (waarbij ik met “kwalitatief goed” o.a. bedoel “conform de acceptabele grenzen van de wensen/specs van zowel de business, maar ook de beheerafdeling, etc). Echter ik ben van mening dat een projectmanager die werkt volgens de middelen van een project (budget/tijd/middelen) nooit een 100% objectief oordeel kan geven over de kwaliteit die hij oplevert. Hoewel ik absoluut geloof in de integriteit van projectmanagers, wil je deze rol eigenlijks niet in de positie brengen dat hij/zij keuzes maakt in de communicatie naar de stuurgroep over de kwaliteit van de projectdeliverables. Daarom pleit ik er nog steeds voor om dit aspect bij een rol te beleggen die niet binnen het projectteam valt en direct verantwoording aflegt aan de stuurgroep i.p.v. de projectmanager. Een kwaliteitsadviseur naast de projectmanager.
@Frans:
Exact!! Er is niets mis met in discussie gaan over een proces dat niet optimaal functioneert en hierdoor mogelijk de uiteindelijke kwaliteit van het product in het gedrang brengt! Natuurlijk moet de discussie zelf het proces niet gaan hinderen. Reageer dus net als met een bevinding: Rapporteer je mening, met voldoende informatie naar personen met mandaat om het probleem te analyseren en (mogelijk) op te lossen en ga verder met je werk.
@Nico n.a.v. opmerking Frans:
Zelfs testers die lang meelopen in de organisatie zijn geen garantie voor het correct functioneren van het testproces, noch voor het krijgen van een product naar wens (omdat het testproces goed zou zijn). Dat is een teameffort. Het testproces is maar een radertje in het geheel. Zonder dat testradertje loopt de motor waarschijnlijk niet optimaal. Maar zonder een ander radertje zal dat ook het geval niet zijn. De ervaren tester kan hooguit als keyuser fungeren als het gaat om informatie over het testproces.
Daarnaast vind ik het gevaarlijk om te roepen dat, als er geen proces is, men zou moeten werken volgens een methode en er dan ook direct een bekende “methode” mee te associeren. Ik zie TMap meer als een boek met wat tips en trucs die je mogelijk kunt adopteren in je testproces. Maar het proces zelf is voor ieder bedrijf verschillend. De te volgen methode dus ook. Een bedrijf dat zegt het proces ingericht te hebben volgens de TMap methode laat dus waarschijnlijk ook een hoop goede tips en trucs naast zich liggen, omdat ze niet in TMap genoemd worden. Ronduit zonde. Wees dus als tester altijd methodisch onafhankelijk! Laat je leiden door je ervaring. Niet door een methode.
@Nico: testers leveren wel degelijk kwaliteit! Kwaliteit in hun werken en doen! Maar ik weet dat je het over toevoegen van kwaliteit in het product hebt 😉
Om even terug op het onderwerp zelf te komen. Met regressietesten is volgens mij niets mis, zolang er een goed proces omheen zit om de regressietestset up-to-date te houden. Ik vergelijk het altijd met een functioneel ontwerp. Deze dient ook in overeenstemming te zijn met de programmatuur. Voor een regressietestset geldt dit net zo. Zolang dit het geval is, heeft een regressietestset zeker wel waarde. Ik krijg het gevoel dat het artikel enigszins provocerend bedoeld is tegen alle groeperingen die werken met een statische regressietestset. Volgens mij onderschat Cem (of de schrijver van het artikel) daarmee echter de competenties van ons Nederlanders. Als ik de way-of- testing in Nederland vergelijk met sommige topics die ik op diverse internationale fora voorbij zie komen, dan doen wij het nog helemaal zo gek nog niet. Het kan altijd beter. Maar dat hoeft niet per definitie stap 1 in het verbeterproces te zijn.
Leuk eerst de definitie van regressietesten veranderen en dan roepen dat het geen testen is. Juist bij software waar vele jaren aan gesleuteld is, zijn regressietests een erg belangrijk onderdeel van het testen. Gebruikers reageren bovendien veel negatiever op nieuwe fouten bij oude functionaliteit dan bij nieuwe functionaliteit.
“Er zijn ook ontwikkelgroepen die zo’n hoog kwaliteitsbewustzijn hebben, dat ik ze afraad om hun software te laten testen” Dus ook geen peer reviews (is ook testen)? Dat lijkt me onaannemelijk.
Alleen wiens mening is dat, van Cem Kaner of Jolein de Rooij?
Ik denk dat de zin “Regressietesten is geen testen” een beetje uit zijn verband is gerukt en misschien wel bewust om een discussie te doen losmaken (zoals deze).
Alleen als je, zoals Cem Kaner aangeeft, “Een te groot vertrouwen op hergebruik van dezelfde test” hebt dan slaat deze zin wel degelijk hout omdat een testset op den duur ‘immuum’ kan worden voor fouten en je deze dus regelmatig moet bijwerken zoals Michel Kraaij ook al aangeeft. Met name regressietestsets worden nogal lang hergebruikt zonder aanpassingen.
Zonder een gedegen impactanalyse en het toetsen van de regressietestset voor het gebruik ervan kun je niet altijd de juiste conclusies verbinden aan de uitkomsten van een regressietest.
In het kort zou mijn aanpak zijn het a.d.h.v. een impactanalyse in kaart brengen van de ongewijzigde delen die getest moeten gaan worden. Vervolgens voor deze delen de regressietestset bijwerken zodat je voorkomt dat je iedere keer precies dezelfde test uitvoert en deze hun waarde verliezen.
Ik denk dat Cem Kaner hetzelfde bedoelt omdat hij in Lessons Learned o.a. zegt dat “automatic regression
tests die”, oftewel doodgaan. Testen herhalen is uiteraard goed maar blind vertrouwen op jaren oude testware niet.