Softwaretesten is een vak. Een softwaretester moet, net als een vakman, een grondig begrip hebben van de tools voor softwaretesten die tot zijn beschikking staan. We hebben een lijst samengesteld van 9 verschillende soorten softwaretesten en de tools die voor elk type worden gebruikt, om QA-analisten en iedereen die in het beroep van softwaretesten werkzaam is te helpen hun vak beter te begrijpen.
Waarom hebben we softwaretesten nodig?
Soms is het belangrijk om eraan herinnerd te worden waarom wat je doet ertoe doet. Het simpele feit is dat elk softwareproduct dat ooit is ontwikkeld en succesvol is geworden, dat heeft gedaan met de hulp van softwaretesters die onvermoeibaar werkten om ervoor te zorgen dat het product aan een zo hoog mogelijke standaard voldeed. Hier zijn drie redenen waarom softwaretesten belangrijk is.
- Klanttevredenheid: Tijdens het ontwikkelen van een project is het gemakkelijk om te verdwalen in het bos van code en te vergeten dat de gebruiker ook tevreden moet zijn over de werking van de software. QA-analisten en andere QA-medewerkers vervullen die rol.
- Productkwaliteit: Elk beroep waarin een team of individu iets vanaf nul creëert, vereist een ander team om hun fouten op te sporen. Schrijvers hebben redacteuren nodig. Filmregisseurs hebben ook redacteuren nodig. Softwareontwikkelaars hebben geen redacteuren nodig, maar wel een QA-team dat een objectief standpunt biedt en eventuele fouten opspoort.
- Beveiliging: Met elke voorbijgaande dag lijkt dit punt steeds belangrijker te worden. Klanten willen gerustgesteld zijn dat de informatie die ze in de software invoeren en het werk dat ze erin doen privé blijft. Een onderdeel van QA is ervoor zorgen dat klanten dat vertrouwen hebben.
Methodologieën voor softwaretesten
Elke in dit artikel genoemde techniek voor softwaretesten behoort tot een van twee hoofdcategorieën: statisch testen en dynamisch testen. Voordat we de specifieke details van de negen verschillende technieken voor softwaretesten bekijken, leg ik het verschil tussen deze twee methodologieën uit en hoe ze in de softwareontwikkelingscyclus worden toegepast.
Statisch testen
Statisch testen is een vorm van softwaretesten die vroeg in de ontwikkelingscyclus wordt uitgevoerd. Het is een kosteneffectieve manier om bugs te vinden voordat ze grote problemen voor het ontwikkelingsteam worden. Statische tests worden vroeg in de ontwikkelingscyclus uitgevoerd omdat ze kunnen worden gedaan zonder volledig functionerende software. Dat klopt, de software kan al worden gedebugd voordat deze ook maar in de buurt van voltooiing is. Zie je hoe handig dat kan zijn?
Statische tests worden op twee manieren uitgevoerd:
- Handmatige controles: Code wordt geanalyseerd door een QA-analist of tester.
- Automatische analyse: Een testtool controleert automatisch het programmadocument en noteert eventuele fouten.
Statisch testen is:
- Uitgevoerd zonder code uit te voeren.
- Kosteneffectief.
- Nuttig om ervoor te zorgen dat de software aan de verificatiespecificaties voldoet.
- Een manier om de hoofdoorzaak van bugs vast te stellen.
De meeste statische tests worden uitgevoerd in de vorm van documentbeoordelingen. In dit scenario is een document ofwel een schriftelijke beschrijving van een product (bekend als een softwareontwerpdocument) ofwel de broncode van het programma. Hier zijn enkele technieken voor statisch testen die elke QA-analist zou moeten kennen:
- Informele beoordeling: Er zijn geen strikte richtlijnen voor de informele beoordeling. Het team bekijkt de testdocumenten en geeft commentaar op wat het ziet. Er is geen documentatie.
- Doorloop: De auteur van de code loopt zijn document door en het QA-team stelt vragen en uit zorgen. Doorlopen zijn doorgaans zeer informeel en een goede manier om onderwerpen te bespreken met mensen buiten het softwarevakgebied.
- Technische beoordeling: Technische experts komen samen en beoordelen de technische specificaties van de code. Door dit vroeg in het ontwikkelingsproces te doen, wordt ervoor gezorgd dat het eindproduct aan de vereiste specificaties voldoet.
- Inspecties: De meest formele van alle beoordelingen. Een team van getrainde moderatoren inspecteert de documenten grondig tijdens de vergadering. Alle gevonden bugs worden formeel gedocumenteerd en geregistreerd voor beoordeling. Er volgt een controle om na te gaan of de gedocumenteerde bugs zijn opgelost.
In de meeste gevallen zijn statische testbeoordelingen nuttig, omdat het volledige QA-team het product analyseert en wijzigingen voorstelt op basis van problemen die ze zien en problemen die ze verwachten. Naast het voordeel dat er een grote verscheidenheid aan stemmen bij het gesprek wordt betrokken, heeft dit als bijkomend voordeel dat alle teamleden op de hoogte worden gebracht van de voortgang en het ontwerp van het project.
Gebruik statisch testen als je team:
- Vroeg in het ontwikkelingsproces zit.
- Op zoek is naar een kosteneffectieve manier om bugs te vinden.
- Software heeft die nog niet kan worden uitgevoerd.
- Fouten vroeg in de ontwikkeling wil opsporen.
Have an account? Log In
Dynamisch testen
In tegenstelling tot statisch testen is dynamisch testen een vorm van softwaretesten waarbij code moet worden uitgevoerd. Uiteraard vereist dit dat de ontwikkeling verder gevorderd is in de productiecyclus. Het voordeel van het testen van uitvoerbare code is dat QA-analisten kunnen bekijken hoe de software presteert tijdens het uitvoeren in een praktijksituatie. Het is een uitstekende manier om het functionele gedrag van de software en andere zaken, zoals CPU-gebruik, te controleren. Dynamisch testen controleert of het verwachte resultaat overeenkomt met het resultaat in de praktijk. Het belangrijkste doel van dynamisch testen is verifiëren dat het product voldoet aan de ontwerp- en functionele vereisten die vóór de start van het project zijn vastgesteld.
Bij het dynamisch testen van systeemsoftware zijn doorgaans vier stappen betrokken die QA-analisten moeten kennen:
- Unittesten: Wanneer software wordt getest met unittesten, wordt deze opgedeeld in de kleinst mogelijke onderdelen en afzonderlijk getest. Door op deze manier te testen, kunnen QA-analisten erop vertrouwen dat elk afzonderlijk onderdeel van de software werkt zoals bedoeld. En als er een bug wordt gevonden, is die in deze ontwikkelingsfase gemakkelijker op te lossen, omdat de probleemcode snel kan worden geïsoleerd. Wanneer het QA-team begint met dynamisch testen (hoewel deze testfase soms door het ontwikkelingsteam wordt uitgevoerd), begint het doorgaans met unittests.
- Integratietesten: Nadat de software grondig is opgesplitst in onderdelen en via unittesten is getest, wordt de software in groepen samengevoegd en opnieuw getest. Als unittesten ervoor zorgen dat elk afzonderlijk onderdeel goed werkt, controleert integratietesten of die afzonderlijke onderdelen met elkaar communiceren zoals bedoeld. Zie het als de montage van een auto. Tijdens elke montagestap worden de auto-onderdelen (de motor, de pedalen, het stuurwiel) afzonderlijk getest. Vervolgens wordt de auto als geheel gemonteerd en getest om er zeker van te zijn dat het gaspedaal goed met de motor communiceert (en dat de remmen dat ook doen!). Wil je zorgen voor een naadloze integratie tussen modules? Onze aanbevolen softwaretesttools kunnen je daarbij helpen.
- Systeemtesten: Systeemtesten vormen het derde niveau van softwaretesten. In deze fase wordt volledig geïntegreerde software getest. Het doel van de systeemtest is ervoor te zorgen dat de software aan de vereisten voldoet, oftewel doet waarvoor deze is ontworpen.
- Acceptatietesten: De laatste fase van dynamisch testen. Bij de acceptatietest wordt opnieuw getest aan de hand van de vereisten en wordt gecontroleerd of de software is afgewerkt volgens een aanvaardbare norm. Dit gebeurt om ervoor te zorgen dat er geen fouten door de andere testfasen zijn geglipt. In wezen is het een extra controle uit veiligheidsoverwegingen.
Fasen van dynamisch testen
- Unittesten
- Integratietesten
- Systeemtesten
- Acceptatietesten
Snelle tip: verificatie- versus validatietesten
Verificatietesten hebben alle belangrijke kenmerken van statisch testen. Het doel van een verificatietest is om alle documenten en code te verifiëren. Dit gebeurt via dezelfde methoden die bij statisch testen worden gebruikt.
Op dezelfde manier hebben validatietesten alle belangrijke kenmerken van dynamisch testen. Een verificatietest richt zich op het bevestigen dat de software van hoge kwaliteit is, en dat is precies waar systeem- en acceptatietesten zich ook op richten.
Nu we enkele belangrijke concepten rondom softwaretesten hebben behandeld, bekijken we de 9 soorten softwaretesten die elke QA-analist zou moeten kennen.
9 soorten softwaretesten die elke QA-analist zou moeten kennen:
- Black-box testen
- White-box testen
- Grey-box testen
- Geautomatiseerd testen
- Unittesten
- Regressietesten
- Verkennend testen
- Functioneel testen
- Gebruiksvriendelijkheidstesten
1. Testen met de black box
Testen met een black box is een softwareteststrategie waarbij het ontwerp van het softwaresysteem dat wordt getest onbekend is bij de tester.
Herinner je je die scène aan het einde van Pulp Fiction, waarin Samuel Jackson de koffer opent en zijn gezicht oplicht? Als publiek weten we wat de koffer betekent en vertegenwoordigt in de context van de film, maar we komen nooit te weten wat erin zit. Een tester van de black box is het publiekslid dat weet wat het ding (of het nu een koffer of systeemsoftware is) hoort te doen, maar niet waaruit het bestaat.
Een tester die verantwoordelijk is voor het testen met een black box van tijdregistratiesoftware opent het programma zonder kennis van het interne ontwerp van de software en probeert de verschillende functies en menu's uit om er zeker van te zijn dat ze werken zoals verwacht. De reden voor het testen met een black box is dat de tester de software zonder diepgaande kennis van het ontwerp ervan benadert met verwachtingen die vergelijkbaar zijn met die van de eindgebruiker.
Enkele voordelen van testen met een black box zijn:
- Testers hebben niet veel kennis van programmeertalen nodig, omdat de tester de software gebruikt vanuit het perspectief van een gebruiker.
- Biedt een onbevooroordeelde beoordeling van de software, omdat de softwaretest wordt uitgevoerd door het QA-team in plaats van door de softwareontwikkelaars.
- De testers hoeven niet volledig op de hoogte te zijn van de ontwikkeling van de softwaresystemen, waardoor er zeer weinig voorbereidingstijd nodig is voordat de tests kunnen worden uitgevoerd.
Gerelateerd artikel: 10 beste hulpmiddelen voor testen met een black box
2. Testen met de white box
Bij testen met een white box begrijpt het QA-lid de interne structuur en het ontwerp van de software die wordt getest volledig. De tester benadert de test als een inspecteur en zorgt ervoor dat elk onderdeel van het programma goed werkt. Testen met een white box wordt soms testen met een doorzichtige box genoemd, omdat de tester de interacties tussen eenheden observeert tijdens het testen van de software. In tegenstelling tot testen met een black box maakt een tester van de white box zich veel minder zorgen over de gebruikerservaring.
Enkele voordelen van testen met een white box zijn:
- Tests kunnen in vroege ontwikkelingsfasen worden uitgevoerd. De grafische gebruikersinterface (GUI) hoeft nog niet volledig functioneel te zijn.
- De tests zijn grondiger en doelgerichter dan tests met een black box.
In het voorbeeld van Pulp Fiction is de tester van de white box het personage van Tim Roth, die rechtstreeks kijkt naar wat er in de koffer zit.
3. Testen met de grey box
Bij testen met een grey box heeft de tester enige kennis van de interne structuur en het ontwerp van de software (white box), maar test hij nog steeds vanuit het perspectief van een eindgebruiker (black box). Zo ontstond testen met een grey box. Bij testen met een grey box wordt het ontwerp van de test ontwikkeld door naar de interne structuur van de software te kijken, terwijl de daadwerkelijke test wordt uitgevoerd met behulp van de gebruikersinterface.
Nogmaals, als dit die beroemde scène uit Pulp Fiction zou zijn, is de tester van de grey box noch het publiek, noch Tim Roth. Deze keer is de tester Quentin Tarantino zelf.
4. Geautomatiseerd testen
Geautomatiseerde tests gebruiken software om taken uit te voeren zonder handmatige instructies van een tester.
Bij handmatig testen schrijft de tester de code die hij wil uitvoeren of plant hij het softwarepad waarvan hij wil controleren of het goed werkt. Geautomatiseerde tests nemen dergelijke zaken namens de testers voor hun rekening. Hier volgt een korte lijst met geautomatiseerde software- en QA-hulpmiddelen die QA-analisten zouden moeten kennen:
Bekijk voor een diepgaandere beoordeling van hulpmiddelen voor geautomatiseerd testen de lijst met beste hulpmiddelen voor geautomatiseerd testen die je zou moeten gebruiken.
5. Unittesten
Hulpmiddelen voor unittesten zorgen ervoor dat elk afzonderlijk onderdeel van de software correct werkt. Het is uiterst belangrijk om ervoor te zorgen dat unittesten goed wordt uitgevoerd, anders zal het ontwikkelingsteam grote vertraging oplopen wanneer het later ontdekt dat een belangrijk onderdeel van de software niet werkt.
6. Regressietesten
Hulpmiddelen voor regressietesten voeren oude tests uit op nieuwe softwareversies om ervoor te zorgen dat de software nog steeds werkt zoals bedoeld. Het uitvoeren van regressietests beschermt ontwikkelaars tegen latente effecten door ervoor te zorgen dat een wijziging in de software op punt A niet per ongeluk iets op punt D heeft stukgemaakt.
Voor een QA-analist moeten twee stappen vooruit en één stap achteruit niet als iets negatiefs worden gezien. Door af en toe één stap achteruit te zetten, zorg je ervoor dat je later niet op het punt staat om vijftig stappen achteruit te zetten.
7. Verkennend testen
Verkennend testen is testen voor mensen die niet van plannen houden. In de meeste andere situaties wordt de testcase grondig gepland voordat deze wordt uitgevoerd. Hier niet. Wanneer een tester een verkennende test uitvoert, verkent die de software zonder vooraf opgesteld plan, met behulp van gespecialiseerde hulpmiddelen voor verkennend testen.
Het voordeel van verkennend testen is dat de tester zich direct kan aanpassen aan de bevindingen, zonder dat er een nieuwe testcase hoeft te worden geschreven. Verkennend testen maakt ook samenwerking, theorievorming en overleg mogelijk, allemaal direct tijdens het testen.
Naarmate de agile ontwikkelingstheorie prominenter is geworden, is ook verkennend testen belangrijker geworden. Doordat QA-testers hun intuïtie kunnen gebruiken, worden veel interessante fouten gevonden waar een traditionele testuitvoering mogelijk niet naar zou hebben gezocht.
Let op: verkennend testen kan veel creativiteit vereisen.
More Articles
8. Functioneel testen
Functioneel testen wordt uitgevoerd om ervoor te zorgen dat de systeemsoftware voldoet aan de projectvereisten die vóór de ontwikkeling zijn vastgesteld.
De softwaretester controleert of de ingevoerde gegevens overeenkomen met de verwachte uitvoer. Dit gebeurt tijdens een van de laatste testfasen, hetzij tijdens systeemtesten, hetzij tijdens acceptatietesten, en het is uitsluitend een vorm van black-box-testen, omdat het niet gaat om de manier waarop de software werkt, zolang deze maar werkt.
9. Bruikbaarheidstesten
Bruikbaarheidstesters zorgen ervoor dat ontwerpkeuzes functioneel en toch intuïtief zijn.
Als je voorspelt dat veel gebruikers van je software elke dertig minuten een back-up van hun documenten willen maken, kun je de back-upfunctie het beste op een gemakkelijk toegankelijke plaats zetten in plaats van deze achter vier submenu's te verbergen.
Vaak is er software ontwikkeld die vlekkeloos werkt en voorziet in een belangrijke behoefte op de markt, maar vanuit gebruikersperspectief volledig onmogelijk te navigeren is. Dit kan worden verklaard door een gebrek aan bruikbaarheidstesten tijdens de softwaretestfase.
Uiteindelijk zal het, hoe goed een softwareprogramma technisch ook is, moeilijk zijn om een markt te vinden als gebruikers het niet prettig vinden om ermee te werken.
Meer weten?
De softwaretestindustrie verandert voortdurend, en QA-analisten moeten op de hoogte blijven van actuele trends. Er zijn eindeloos veel bronnen over softwaretesten, waaronder podcasts, boeken, nieuwsbrieven en meer.
Abonneer je op de nieuwsbrief van The CTO Club voor productupdates, beoordelingen van hulpmiddelen en meer overzichten van bronnen.
