Softwaretesten is een vak. Een softwaretester moet, net als een vakman, een grondig begrip hebben van de softwaretesttools die tot zijn beschikking staan. We hebben een lijst samengesteld van 9 verschillende soorten softwaretests en de tools die voor elk type worden gebruikt, om QA-analisten en iedereen die in het vakgebied van softwaretesten werkt 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 eenvoudige feit is dat elk succesvol softwareproduct dat ooit is ontwikkeld, dat succes te danken heeft aan de hulp van softwaretesters, die onvermoeibaar hebben gewerkt 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 kun je gemakkelijk verdwalen in het bos van code en 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 perspectief biedt en fouten opspoort.
- Beveiliging: Met elke dag die verstrijkt lijkt dit punt steeds belangrijker te worden. Klanten willen de zekerheid dat de informatie die ze in de software invoeren en het werk dat ze erin doen privé blijft. Een deel van QA bestaat uit ervoor zorgen dat klanten dat vertrouwen hebben.
Methodologieën voor softwaretesten
Elke in dit artikel genoemde softwaretesttechniek behoort tot een van twee hoofdcategorieën: statisch testen en dynamisch testen. Voordat we de specifieke details van de negen verschillende softwaretesttechnieken bespreken, leg ik het verschil tussen deze twee methodologieën uit en op welk moment in de softwareontwikkelingscyclus ze 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 worden gedebugd voordat deze zelfs maar bijna voltooid is. Zie je hoe handig dat kan zijn?
Statische tests worden op twee manieren uitgevoerd:
- Handmatige onderzoeken: De 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.
- Handig om ervoor te zorgen dat de software aan de verificatiespecificaties voldoet.
- Een manier om de hoofdoorzaak van bugs te bepalen.
De meeste statische tests worden uitgevoerd in de vorm van documentbeoordelingen. In dit scenario is een document een schriftelijke beschrijving van een product (bekend als een softwareontwerpdocument) of de broncode van het programma. Hier zijn enkele statische testtechnieken die elke QA-analist zou moeten kennen:
- Informele beoordeling: Er zijn geen strikte richtlijnen voor de informele beoordeling. Het team neemt de testdocumenten door en geeft commentaar op wat het ziet. Er wordt geen documentatie opgesteld.
- Doorloopcontrole: De auteur van de code neemt zijn document door en het QA-team stelt vragen en uit zorgen. Doorloopcontroles zijn doorgaans erg 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 moderators 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 verholpen.
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, biedt dit ook het extra 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 waarvoor code moet worden uitgevoerd. Dit vereist natuurlijk 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 realistische situatie. Het is een uitstekende manier om het functionele gedrag van de software en andere zaken, zoals CPU-gebruik, te controleren. Dynamisch testen controleert of de verwachte uitkomst overeenkomt met de uitkomst in de praktijk. Het belangrijkste doel van dynamisch testen is controleren of het product voldoet aan de ontwerp- en functionele vereisten die vóór de start van het project zijn vastgesteld.
Gewoonlijk zijn er vier stappen betrokken bij het dynamisch testen van systeemsoftware die QA-analisten moeten kennen:
- Unittesten: Wanneer software wordt onderworpen aan 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 deze in deze ontwikkelingsfase gemakkelijker op te lossen, omdat de probleemcode snel kan worden geïsoleerd. Gewoonlijk begint het QA-team bij het starten van dynamisch testen (hoewel deze testfase soms door het ontwikkelingsteam wordt uitgevoerd) met unittests.
- Integratietesten: Nadat de software grondig in onderdelen is opgesplitst en via unittesten is getest, worden de onderdelen samengevoegd tot groepen en opnieuw getest. Als unittesten ervoor zorgen dat elk afzonderlijk onderdeel correct werkt, controleren integratietesten of die afzonderlijke onderdelen met elkaar communiceren zoals ze horen te doen. Zie het als de assemblage van een auto. In elke assemblagefase 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 correct met de motor communiceert (en dat de remmen dat ook doen!). Wil je een naadloze integratie tussen modules garanderen? Onze aanbevolen softwaretesttools kunnen je precies daarbij helpen.
- Systeemtesten: Systeemtesten vormen het derde niveau van softwaretesten. In deze fase wordt volledige en 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 aan de vereisten getoetst en wordt gecontroleerd of de software tot een aanvaardbare standaard is afgewerkt. 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 het verifiëren van alle documenten en code, en dit wordt bereikt via dezelfde methoden die bij statisch testen worden gebruikt.
Ook validatietesten hebben 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 de systeem- en acceptatietesten zich op richten.
Nu we enkele belangrijke concepten rond 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
- White-box
- Grey-box
- Geautomatiseerd
- Unit
- Regressie
- Verkennend
- Functioneel testen
- Gebruiksvriendelijkheidstesten
1. Testen met een zwarte doos
Testen met een zwarte doos is een softwareteststrategie waarbij het ontwerp van het geteste softwaresysteem 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 leren nooit wat erin zit. Een tester van een zwarte doos is het publiekslid dat weet wat het ding (of het nu een koffer of systeemsoftware is) hoort te doen, maar niet waaruit het is opgebouwd.
Een tester die verantwoordelijk is voor het testen met een zwarte doos 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 naar verwachting werken. De reden voor het testen met een zwarte doos is dat de tester de software zonder diepgaande kennis van het ontwerp ervan benadert met vergelijkbare verwachtingen als de eindgebruiker.
Enkele voordelen van testen met een zwarte doos zijn:
- Testers hebben niet veel kennis van programmeertalen nodig, omdat de tester de software gebruikt vanuit het perspectief van een gebruiker.
- Levert een onbevooroordeelde beoordeling van de software op, 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, wat betekent dat er zeer weinig voorbereidingstijd nodig is voordat de tests kunnen worden uitgevoerd.
Gerelateerd artikel: 10 beste tools voor testen met een zwarte doos
2. Testen met een witte doos
Bij testen met een witte doos begrijpt het QA-lid de interne structuur en het ontwerp van de geteste software volledig. Hij of zij benadert de test als een inspecteur en zorgt ervoor dat elk onderdeel van het programma correct werkt. Testen met een witte doos wordt soms testen met een doorzichtige doos genoemd, omdat de tester de interacties tussen eenheden observeert tijdens het testen van de software. In tegenstelling tot testen met een zwarte doos houdt een tester van een witte doos zich lang niet zo veel bezig met de gebruikerservaring.
Enkele voordelen van testen met een witte doos zijn:
- Tests kunnen in vroege ontwikkelingsfasen worden uitgevoerd. De grafische gebruikersinterface (GUI) hoeft niet volledig functioneel te zijn.
- De tests zijn grondiger en doelgerichter dan tests met een zwarte doos.
In het voorbeeld van Pulp Fiction is de tester van een witte doos het personage van Tim Roth, dat rechtstreeks kijkt naar wat er in de koffer zit.
3. Testen met een grijze doos
Bij testen met een grijze doos heeft de tester enige kennis van de interne structuur en het ontwerp van de software (witte doos), maar test hij of zij nog steeds vanuit het perspectief van een eindgebruiker (zwarte doos). Zo ontstond testen met een grijze doos. Bij testen met een grijze doos 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 was, zou de tester van een grijze doos noch het publiek, noch Tim Roth zijn. Deze keer is de tester Quentin Tarintino 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 of zij wil uitvoeren of plant hij of zij het softwarepad waarvan gecontroleerd moet worden of het correct werkt. Geautomatiseerde tests nemen dergelijke zaken namens de testers voor hun rekening. Hier volgt een korte lijst met geautomatiseerde software- en QA-tools die QA-analisten zouden moeten kennen:
Bekijk voor een uitgebreidere beoordeling van tools voor geautomatiseerd testen de lijst met beste tools voor geautomatiseerd testen die je zou moeten gebruiken.
5. Testen van eenheden
Hulpmiddelen voor unit-tests zorgen ervoor dat elk afzonderlijk onderdeel van de software correct werkt. Het is uiterst belangrijk om ervoor te zorgen dat unit-tests goed worden uitgevoerd, anders krijgt het ontwikkelingsteam later te maken met een enorme tegenslag wanneer blijkt dat een belangrijk onderdeel van hun software niet werkt.
6. Regressietesten
Hulpmiddelen voor regressietests voeren oude tests uit op nieuwe builds 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 doen, zorg je ervoor dat je later niet het risico loopt 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 en het uitwerken van theorieën ter plekke mogelijk.
Naarmate de agile ontwikkeltheorie prominenter is geworden, is dat ook het geval voor verkennend testen. Door QA-testers hun intuïtie te laten gebruiken, worden veel interessante bugs ontdekt waar bij een traditionele testuitvoering mogelijk niet naar zou zijn gezocht.
Wees gewaarschuwd: verkennend testen kan veel creativiteit vereisen.
More Articles
8. Functioneel testen
Functioneel testen wordt uitgevoerd om ervoor te zorgen dat de systeemsoftware overeenkomt met de vereisten van het project voordat de ontwikkeling begon.
De softwaretester controleert of de invoer overeenkomt met de verwachte uitvoer. Dit wordt uitgevoerd tijdens een van de laatste testfasen, als onderdeel van systeemtests of acceptatietests, en is uitsluitend een vorm van blackboxtesten, omdat er niet wordt gekeken naar hoe de software werkt zolang deze maar werkt.
9. Bruikbaarheidstesten
Testers van de bruikbaarheid 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.
In veel gevallen is er software ontwikkeld die foutloos werkt en in een belangrijke marktbehoefte voorziet, maar vanuit het perspectief van de gebruiker volledig onmogelijk te navigeren is. Dit kan worden verklaard door een gebrek aan bruikbaarheidstests tijdens de softwaretestfase.
Uiteindelijk zal het, hoe goed een stuk software 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.
