Softwaretesten kent vele kanten. Naast de keuze voor procedures en methodologieën is er een veelvoud aan gereedschappen in verschillende categorieën beschikbaar. Andrew Issaenko schept orde in de chaos en geeft een overzicht.
Softwaretesten is een onmisbaar onderdeel van het ontwikkelproces. Veel bedrijven hebben echter geen helder beeld van wat het precies inhoudt. Bij het invoeren van een testprocedure zijn er veel facetten waarop ze moeten letten, maar de uiteindelijke keuze komt neer op de kosten van testgereedschappen en -procedures, en de besparingen die het oplevert. De eerste stap bij het selecteren van de beste testmethode is het verzamelen en analyseren van informatie over de manier van softwareontwikkeling binnen het project of het bedrijf. Het is verstandig om de verwachtingen van een testtool vooraf te bepalen door een lijst van noodzakelijke vereisten te maken. Dit artikel biedt daarbij een richtlijn.
Er zijn verschillende categorieën testtools. Grofweg vallen ze uiteen in gereedschappen voor ondersteuning, voor statistische analyse en voor uitvoering van de tests. Ondersteunende gereedschappen hebben betrekking op het beheer en de planning van testen. Statistische gereedschappen analyseren de code zonder deze in werking te stellen, terwijl uitvoeringstools dat juist wel doen. Hieronder worden de drie categorieën uitgebreider behandeld.
Probleem opsporen
Bij ondersteunende gereedschappen kun je denken aan tools die helpen bij het ontwerp van de testen, het beheer van de testen, en gereedschappen om de gevonden problemen bij te houden. Ontwerptools helpen om de volledigheid van de software-eisen te analyseren voordat het plannen van de testcases begint. Ze helpen ook met het genereren van testcases en -gegevens uit softwarerequirements, beschrijvingen van module-interfaces en functionele modellen. Als de productspecificatie goed omschreven is, leveren deze gereedschappen een belangrijke bijdrage aan het versnellen en het efficiënter maken van het testontwerp.
Daarnaast zijn er beheertools om de informatie over elk van de testcases vast te leggen. Deze gereedschappen kunnen de informatie op verschillende manieren combineren, op basis van bijvoorbeeld soort of vereisten. Daardoor helpen ze met het plannen van de uitvoering. Enkele beheersgereedschappen zijn met testautomatiseringstools te koppelen, zodat ze de uitvoering van de case automatisch op het gewenste moment kunnen starten.
De doeltreffendheid van deze beheerstools hangt af van het aantal testcases in een project. Hoe meer dat er zijn, des te groter de doeltreffendheid van deze gereedschappen. Dit geldt ook voor een testteam dat meerdere gelijksoortige projecten onder zijn hoede heeft, zoals verschillende aangepaste versies van hetzelfde product.
Om de gevonden fouten in de software op te slaan en te analyseren zijn er problem tracking-tools. Ze geven inzicht in de aantallen gevonden en opgeloste fouten, de distributie over productgebieden, de probleemsoorten en de doeltreffendheid van de betreffende tests. Uiteindelijk zijn deze tools in staat om aan te geven hoe stabiel het product is, en of het klaar is om uitgebracht te worden. In deze tijd zijn er heel wat gratis problem tracking-tools en is het onbegrijpelijk dat sommige bedrijven deze nog niet gebruiken.
Camcorder
Naast gereedschappen om testinformatie te beheren zijn er uiteraard tools die de code zelf testen. Statistische analysetools werken zonder deze daadwerkelijk uit te voeren. Hiermee kunnen ontwikkelaars informatie verzamelen over verschillende aspecten van de code, zoals de complexiteit, de portabiliteit en afwijkingen van een specifieke codestandaard. Het gebruik hiervan kan zeer nuttig zijn voor het poorten van grote projecten naar andere platforms. Ook hebben ze veel nut als er delen voor grotere systemen worden ontwikkeld. De testengineer kan de statische analysetools dan gebruiken om de meest complexe module te vinden binnen een project.
Gereedschappen die de code wel in werking stellen voeren hun analyses op verschillende vlakken uit. Dynamische analysetools traceren softwarefouten die niet tijdens de statische analyse te ontdekken zijn, zoals prestatieproblemen, ’dode‘ code of problemen met het geheugenbeheer. Ze helpen om te begrijpen wat er in de software gebeurt tijdens het uitvoeren van de test. Het gebruik van dynamische analysetools is altijd zinvol bij hoogniveau programmeertalen. Voor laagniveau talen zoals assembly of bij microcontrollers is dit soort gereedschappen vaak niet beschikbaar. Het meten van de dekkingsgraad voor elke white box-testcase geeft meer zekerheid over de efficiëntie ervan.
Een andere categorie binnen de uitvoeringstools omvat de technische instrumenten, zoals compilers, simulatie- en debuginstrumenten en recorders. Ze kunnen een zeer eenvoudige vorm van testautomatisering bevatten of handmatige uitvoering van tests faciliteren. De doeltreffendheid van deze gereedschappen hangt niet af van het ontwikkelproces maar van de technische deskundigheid van de medewerkers. Voordat u overweegt om extra tools in te zetten om het testen efficiënter te maken, is het raadzaam om na te gaan welke tools al in gebruik zijn of worden overwogen.
Om een product op informele manier te testen is software nodig die alle acties controleert en registreert. Door het analyseren van de logs kunt u de oorzaak van softwareproblemen achterhalen. Als dergelijke software niet voorhanden is dan is een camcorder als alternatieve tool ook prima bruikbaar.
Testautomatiseringstools ofwel regressietestgereedschap helpen om tests automatisch of met een minimale handmatige inspanning uit te voeren. Ze bieden echter nooit een algemeen antwoord op alle testproblemen. De keus voor een regressietool hangt af van de meeste uitgevoerde testsoort. Bij de selectie is het verstandig om eerst alle aanwezige technische instrumenten in kaart te brengen. Regelmatig blijken de ontwikkelteams al te beschikken over hulpmiddelen voor het handmatig uitvoeren van sommige tests, bijvoorbeeld het verzenden en ontvangen van berichten naar apparaten. In dit geval is hier eenvoudig een engine omheen te bouwen die de acties automatisch uitvoert. Deze kan worden gemaakt met eenvoudige freeware testautomatiseringtools of met scriptingtalen zoals Javascript, Perl, Python, TCL of VBScript.
Kritiek
Als u verantwoordelijk bent voor het opzetten van een testproces voor de projecten binnen een bedrijf, dan weet u dat er een langetermijnstrategie voor de introductie nodig is. Ook moet er een kortetermijnplan liggen voor het huidige project. Voor beide plannen is het van vitaal belang dat u nauw samenwerkt met de ontwikkelaars, teamleiders en het management. Zij moeten begrijpen wat het doel van de genomen maatregelen is. Daarvoor is het nodig dat u hun verwachtingen van het testen kent en deze in lijn brengt met uw visie en de noodzakelijke maatregelen. Dat kan door personen te vinden met voldoende aanzien onder de ontwikkelaars en het management, en hen te overtuigen van uw visie.
Wanneer u precies weet hoe u het testen moet aanpakken, laat uw team dan duidelijk merken dat u overtuigd bent van de testmethode en organisatie. Probeer geen kritiek te leveren op de eerdere manier van testen, zeker als de ontwikkelaars dit deden. Mensen zijn alleen bereid zich volledig in te zetten als zij aan uw kant staan. Niemand houdt ervan om aan zijn fouten herinnerd te worden.
Als u een testprocedure aan het begin van de lifecycle wilt invoeren, is het belangrijkste doel om een testproces op te zetten dat de kwaliteit van de software garandeert. Is uw project al in de eindfase, dan is het doel om zo veel mogelijk fouten te vinden. Dan is het vaak de meest kosteneffectieve beslissing om geen gereedschappen te gaan gebruiken maar om zo veel mogelijk mankracht op het testtraject te zetten. Velen zien deze maatregel als ineffectief, maar met de juiste organisatie en coördinatie kan die wél werken. Een alternatief hiervoor is om een extern softwarehuis in de arm te nemen dat een ervaring heeft met het testen van vergelijkbare systemen.
Andew Issaenko is senior softwaretestengineer bij PTS Software. Hij is opgeleid aan de Belarusian State Technical University in Wit-Rusland en is ruim acht jaar werkzaam in diverse testfuncties. Tijdens de Bits&Chips Testdag op 4 oktober aanstaande geeft hij een lezing over de keuze van testtools.