Black box testen in software engineering

Black box testen in software engineering beoordeelt een product van buitenaf, zonder zicht op de broncode, precies zoals uw klanten het gebruiken. Die beperking is bewust gekozen, want wie ervoor betaalt kan ook niet naar binnen kijken. Toch vinden zij de kapotte onderdelen binnen enkele dagen na een lancering.

Er is ook een commerciële reden om er belang aan te hechten. Testers die uw code nooit ontvangen, kunnen die ook niet laten uitlekken. Daarom huren veel bedrijven een externe partner in voor handmatig testen in plaats van hun systemen open te stellen.

In deze gids nemen we u uitgebreid mee door black box testen en de vier belangrijkste technieken. We bespreken ook wanneer u in echte projecten beter black box of white box testen inzet.

Wat black box testen in software engineering werkelijk is

De naam komt uit de techniek, waar een black box elk systeem is dat uitsluitend wordt beoordeeld op wat erin gaat en wat eruit komt. Testers werken op dezelfde manier. Sommigen hebben geen toegang tot de code, de rest kiest ervoor niet te kijken.

Het vakgebied heeft hier een tweede term voor, specificatiegebaseerd testen, en die beschrijft het werk eerlijker. ISTQB, het orgaan dat wereldwijd de standaardterminologie voor testers beheert, definieert het als een testaanpak die gebaseerd is op de specificatie van een component of systeem. Eenvoudig gezegd: iemand schrijft op wat het product zou moeten doen, en een tester controleert of het precies dat doet.

Een tester hoeft niet te weten hoe de software is gebouwd. Hij werkt vanuit de requirements, de functiebeschrijvingen en de schermen voor zich, en vergelijkt vervolgens wat er gebeurt met wat er beloofd was.

White box testen begint juist aan de andere kant. De engineer leest de broncode en brengt elke beslissing in kaart die daarin wordt genomen, zoals betalende klanten de ene kant op sturen en gratis gebruikers de andere. Elk van die keuzes krijgt vervolgens een eigen test, zodat er binnenin niets ongecontroleerd blijft.

Geen van beide aanpakken wint zonder meer, omdat ze verschillende vragen beantwoorden. De ene vertelt u of het product zijn werk doet. De andere laat zien of de code eronder deugt. De meeste gezonde teams doen allebei, op verschillende momenten en meestal met verschillende mensen.

De vier kerntechnieken van black box testen

U kunt niet alles testen. Een boekingsformulier met slechts vijf vragen, die elk tien verschillende antwoorden toelaten, levert al 100.000 combinaties op. Omdat niemand de tijd heeft om ze stuk voor stuk door te lopen, gebruiken specialisten vier black box testtechnieken die de lijst terugbrengen tot de controles die de meeste kans maken echte bugs te vinden.

Equivalentiepartitionering: test één waarde uit elke groep

Software behandelt zelden elke invoer als uniek. Ze sorteert invoer in groepen en past op elke groep dezelfde regel toe.

Stel u een aanmeldformulier voor dat kandidaten van 18 tot 65 jaar accepteert. Iedereen binnen dat bereik wordt identiek behandeld, dus eerst 34 en daarna 47 proberen leert u niets nieuws. Er bestaan hier feitelijk drie uitkomsten: te jong, geaccepteerd en te oud. Equivalentiepartitionering betekent dat u één waarde uit elke groep kiest en erop vertrouwt dat die voor de rest staat.

Die 48 geaccepteerde leeftijden hebben samen aan één test genoeg, terwijl de twee afgewezen groepen er elk één vragen. Deze techniek dekt ook invoer die zou moeten mislukken, zoals letters in een getalveld of een leeg gelaten vak, en dat bewust aftasten heet negatief testen.

Grenswaardeanalyse: test de randen van elke groep

Bugs verzamelen zich aan de randen van elke groep, precies op de punten waar het antwoord omslaat van geaccepteerd naar afgewezen. Het aanmeldformulier uit ons voorbeeld heeft er twee: de stap van 17 naar 18 en de stap van 65 naar 66.

Hier gaat het mis. De regel zegt dat kandidaten 18 of ouder moeten zijn, maar wie het formulier bouwt schrijft in plaats daarvan „ouder dan 18”. Die twee formuleringen lijken identiek, totdat een 18-jarige zich probeert aan te melden en wordt geweigerd.

Dus test u de waarden aan weerszijden van elke rand: 17 en 18 aan de onderkant, 65 en 66 aan de bovenkant. Dat zijn vier controles, en ze vangen een fout af die voortdurend in software sluipt. Onze gids over grenswaardeanalyse gaat verder en laat zien hoe hetzelfde idee geldt voor datums, bestandsgroottes en het aantal records dat een systeem in één keer accepteert.

Beslissingstabeltesten: breng elke combinatie van regels in kaart

Sommig gedrag hangt van meerdere voorwaarden tegelijk af, en daar raken teams het overzicht kwijt. Een beslissingstabel somt elke voorwaarde op en legt vervolgens vast wat er bij elke combinatie moet gebeuren.

Stel dat uw afrekenproces gratis bezorging biedt bij bestellingen boven 50 dollar, en dat leden van het loyaliteitsprogramma punten sparen op alles wat ze kopen. Twee voorwaarden leveren vier uitkomsten op:

Zo uitgeschreven worden de gaten meteen zichtbaar. Teams controleren standaard de eerste rij en de laatste, en leveren dan op zonder de twee ertussen te hebben geprobeerd. Precies daar betaalt een lid dat 40 dollar uitgeeft de juiste kosten en ontvangt het nooit zijn punten.

Voeg een derde voorwaarde toe, zoals een kortingscode, en de tabel verdubbelt naar acht rijen. Die groei is juist het punt, want elke nieuwe regel is een combinatie waar uw klanten uiteindelijk op stuiten, of iemand die nu vooraf heeft geprobeerd of niet.

Toestandsovergangstesten: volg het pad dat een gebruiker aflegt

Bepaalde functies gedragen zich anders afhankelijk van wat er eerder is gebeurd, en die voorgeschiedenis onderzoekt deze techniek. De software bevindt zich in een toestand, een gebeurtenis brengt haar naar een andere, en de tester volgt de route.

Accountvergrendeling is het duidelijkste voorbeeld. In het begin staat iedereen goed aangeschreven. Dan levert één verkeerd wachtwoord een strafpunt op, een tweede nog een, en een derde blokkeert de login 15 minuten lang. Het op enig moment goed invoeren zou die teller echter moeten wissen en de persoon binnenlaten.

Wie dat pad aflegt, vindt de controles die de moeite waard zijn:

• De teller zou volledig moeten resetten, zodat er niets van dinsdag overblijft dat op vrijdag met twee nieuwe optelt.
• De vergrendeling zou zichzelf na 15 minuten moeten opheffen in plaats van te blijven staan tot de supportafdeling ingrijpt.
• Een vergrendeld account zou nieuwe pogingen moeten weigeren zolang het wacht.

Geen van deze controles vereist toegang tot de broncode. Ze vragen alleen om iemand die bereid is de hele reeks te doorlopen in plaats van elk scherm apart te testen.

Waar black box testen past in uw ontwikkelproces

Black box werk kan beginnen zodra er geschreven requirements zijn, en dat is eerder dan de meeste teams aannemen. Testers ontwerpen hun gevallen vanuit de specificatie zelf, dus de voorbereiding start terwijl de ontwikkelaars nog aan het bouwen zijn.

Het wordt de belangrijkste methode in twee latere fasen:

• Systeemtesten toetst het samengestelde product aan wat er is gespecificeerd en dekt het geheel in plaats van de onderdelen.
• Gebruikersacceptatietesten vraagt de mensen die om de software hebben gevraagd of die hun probleem oplost. Die beoordelaars hebben de code nooit gezien, en dat hoeft ook niet. Dat is black box testen in zijn zuiverste vorm.

Alfa- en bètatesten horen tot dezelfde familie. Beide geven een build aan echte gebruikers en kijken wat er stukgaat, één groep binnen het bedrijf en één daarbuiten. Onze vergelijking van alfa- en bètatesten laat zien hoe ze in de praktijk verschillen.

Deze methode kan echter niet aantonen dat elke regel van uw code is uitgevoerd. Een functie kan alle controles van buitenaf doorstaan terwijl er achter de schermen een hele logicatak onaangeroerd blijft, wachtend op een ongebruikelijke invoer. Ontwikkelaars dichten dat gat met unittests, kleine programma’s die de code rechtstreeks inspecteren. Geautomatiseerde tests draait vervolgens de gebruikersgerichte scenario’s opnieuw bij elke build, zodat u meteen merkt wanneer iets dat werkte het niet meer doet. Deze inspanningen vullen elkaar aan in plaats van te concurreren.

Waarom black box testen telt wanneer u QA uitbesteedt

Uw broncode aan een extern bedrijf overhandigen is een beslissing met juridisch gewicht. Contracten worden langer, securityreviews komen erbij, en sommige organisaties weigeren het eenvoudigweg.

Black box testen omzeilt die beslissing volledig. Een partner die deze technieken toepast heeft alleen uw requirements nodig, een werkende build en een paar accounts om mee in te loggen. Omdat uw code uw bedrijf nooit verlaat, hebben uw juristen veel minder te controleren. Testen kan binnen dagen beginnen in plaats van te wachten op goedkeuring.

Dat betekent ook dat een externe partner in elke fase kan instappen, zonder afgeronde build en zonder overdracht van code. Een toegewijd QA-team kan beginnen aan de helft van het product die al werkt, terwijl uw engineers de rest afmaken.

Zo ziet dat er in de praktijk uit: Escuela Coaching, gevestigd in Madrid, vroeg voor de lancering om een onafhankelijke beoordeling van hun onlineplatform. Onze engineers testten zowel het coach- als het klantportaal op 7 apparaten in ongeveer een maand en rapporteerden meer dan 100 defecten. Vandaag bedient het platform meer dan 300 organisaties.

Dezelfde redenering geldt voor security. Dynamisch securitytesten van applicaties tast een draaiend systeem van buitenaf af en zoekt naar zwakke plekken zonder ook maar één regel broncode te lezen. Daarmee hoort het securitytesten van webapplicaties tot dezelfde familie, en is het opnieuw werk dat een externe specialist zonder uw code kan doen.

Black box testen is een keuze, geen compromis

Werken zonder de broncode lijkt een tekortkoming van de methode, totdat u ziet wat het oplevert. De controles weerspiegelen hoe echte klanten het product gebruiken, en wie ze uitvoert heeft nooit toegang tot uw code nodig. Samen verklaren die twee feiten waarom zoveel testwerk bij een extern team terechtkomt.

QAwerk past deze technieken toe binnen ons handmatig testen, systeemtesten en acceptatietesten. Om te bepalen welke uw volgende release werkelijk nodig heeft, praat met onze QA-engineers.

Bekijk hoe Escuela Coaching hun onlinecoachingplatform op schema lanceerde nadat wij beide portalen op 7 apparaten hadden getest en meer dan 100 defecten hadden gerapporteerd.

Voer uw zakelijke e-mailadres in

Ontvang de casestudy