Bij het testen van software zijn er tientallen verschillende testmethoden te overwegen.

Softwaretests helpen ontwikkelaars eventuele gebreken in een softwarepakket te elimineren, zodat zij een product kunnen leveren dat voldoet aan de behoeften en verwachtingen van alle belanghebbenden. Met de juiste testoplossing beschikt u over alle kennis die u nodig hebt, maar het correct kiezen van een test kan tijd kosten.

Grey box testing is een van de meest veelzijdige vormen van testen die testers ter beschikking staan, en biedt veel inzicht zonder al te veel middelen in beslag te nemen.

Lees meer over wat grey box testing is, hoe grey box testing werkt en waarom bedrijven deze testmethode gebruiken.

 

Wat is Grey box testing?

Grey box testing is een vorm van testen die white-box testing en black-box testing combineert, met behulp van een gedeeltelijk begrip van het onderliggende ontwerp en de manier waarop het systeem is geïmplementeerd.

Deze combinatie betekent dat de tester iets weet van wat er op de achtergrond gebeurt zonder de code volledig te kennen, wat meer inzicht geeft in de mogelijke oorzaken van problemen in de software wanneer die zich voordoen.

Het uitvoeren van gray box tests is de verantwoordelijkheid van testers, met een kwaliteitsborgingsteam dat onafhankelijk van het ontwikkelingsteam aan het project werkt.

 

1. Wanneer en waarom moet je grijze dozen testen bij het testen van software?

 

Er zijn verschillende momenten dat bedrijven in het ontwikkelingsproces gebruik maken van grey box testing.

Wanneer een applicatie bijvoorbeeld moet samenwerken met een tool van een derde partij om goed te kunnen draaien, hebben de testers geen toegang tot de broncode die deel uitmaakt van de externe software. Dit is een gedwongen beperking van de toegang voor QA-tester en maakt het testen tot een grijze doos zonder dat er een keuze is.

 

2. Wanneer u geen grijze dozen hoeft te testen

 

Er zijn een paar momenten in het testproces dat grey box testing niet nodig is, en de eerste daarvan is vroeg in het ontwikkelingsproces.

Functioneel testen vindt plaats wanneer ontwikkelaars in eerste instantie testen om er zeker van te zijn dat hun code de meer elementaire taken uitvoert, hetgeen volledig transparant is. Aangezien er geen code of documentatie verborgen is voor de tester, wordt dit niet beschouwd als grey box testing.

Een ander moment waarop je geen grey box tests nodig hebt, is wanneer je helemaal aan het eind van de ontwikkeling test wanneer je een compleet product hebt. Dit is het geval wanneer u de eindgebruiker laat helpen bij het testen en wordt ook wel “bètatest” of “end-to-end test” genoemd.

Gebruikers testen de toepassing zonder toegang tot code of ontwerpdocumenten, en nemen de software in plaats daarvan op zijn eigen merites. Dit is een vorm van black box testing, aangezien het proces volledig ondoorzichtig is.

 

3. Wie is betrokken bij Grey Box Testing?

Er zijn verschillende mensen en rollen die betrokken zijn bij het testen van grijze dozen, waarbij enkele van de belangrijkste rollen in het proces zijn:

 

– QA Manager:

Een QA manager, of quality assurance manager, is een medewerker in het softwareontwikkelingsproces die verantwoordelijk is voor het toewijzen van taken aan het testteam.

Dit omvat het opstellen van roosters, het onderzoeken van rapporten en het omgaan met conflicten die in het team ontstaan.

 

– Tester:

Een tester is een professional die verantwoordelijk is voor het voltooien van de testgevallen die deel uitmaken van het grey box testproces.

Dit vereist veel aandacht voor details bij het schrijven van rapporten en het herhaaldelijk doorlopen van nauwkeurige testgevallen.

 

– Ontwikkelaar:

Ontwikkelaars zijn de professionals die verantwoordelijk zijn voor het creëren van code en het aanpassen ervan afhankelijk van de resultaten van de grey box tests.

Hoewel deze niet noodzakelijkerwijs betrokken zijn bij het testen zelf, ontvangen zij mededelingen van testers over de resultaten.

 

– QA Analist:

De rol van QA-analist is gebruikelijk in testprocessen die veel gebruik maken van automatisering. Een analist schrijft testcasecode voor automatische tests en analyseert daarnaast de gegevens die de tests aan het eind van het proces terugsturen.

 

Voordelen van Grey box Testing

Er zijn een paar grote voordelen van het gebruik van grey box testing bij het onderzoeken van software. Door deze voordelen optimaal te benutten, verbetert u de standaard van uw toepassing in de loop der tijd.

 

Enkele van de redenen waarom bedrijven deze vorm van testen gebruiken zijn:

 

1. Kennis van interne mechanismen helpt bij het ontwerpen van tests

 

Een van de belangrijkste voordelen van het gebruik van grey box testing op de werkplek is het feit dat je een aantal interne mechanismen in de applicatie kent. Hierbij moet worden begrepen wat elk van de functies doet en welke modules off-the-shelf zijn in vergelijking met de op maat geschreven code voor sommige van de andere functies.

Kennis van de interne functionaliteit betekent dat een tester beter begrijpt wat hij test en deze tests kan afstemmen op het ontwerp van de applicatie. Bedrijven krijgen nauwkeuriger resultaten die de software goed weergeven.

 

2. Resulteert in een onmiddellijke oplossing van de problemen

 

In sommige gevallen, wanneer een probleem zich voordoet in een test en de tester toegang heeft tot de code achter het probleem, kan het probleem onmiddellijk worden opgelost.

Dit staat haaks op een black box testmethode, waarbij testers niets kunnen zien van de code achter de schermen van de software die zij onderzoeken. Door de code te zien, kunnen testers met veel ontwikkelingservaring ontwikkelaars wijzen op wat het probleem precies is en hoe een toekomstige update het kan oplossen.

Grey box testing bespaart veel tijd die anders zou worden besteed aan het onderzoeken van problemen en helpt bedrijven hun tijd efficiënter te besteden.

 

3. Scheidt testers en ontwikkelaars

 

Het gebruik van grey box testing zorgt voor een duidelijke scheiding tussen de ontwikkelaars van de applicatie en de mensen die de software testen.

Dit komt omdat het uitvoeren van grey box tests afhankelijk is van testers die geen bestaande kennis hebben van de manier waarop de software werkt, waarbij de afstand tussen beide een noodzaak wordt voor nauwkeurigere testresultaten die niet worden beïnvloed door vertekening.

Testers in grey box scenario’s zitten in een heel ander team dan ontwikkelaars en bieden accurate informatie zonder dat bestaande opvattingen hun output beïnvloeden.

Ook ontwikkelaars profiteren hiervan omdat ze een kritischer blik op hun werk krijgen, waardoor ze zowel de bestaande app als hun vaardigheden voor de toekomst kunnen verbeteren.

 

Uitdagingen van Gray Box Testing

Er zijn een paar grote nadelen aan het gebruik van grey box testing bij uw ontwikkelingswerk.

Door deze nadelen te begrijpen en ze waar mogelijk te beperken, verhoogt u de algemene kwaliteit van uw werk aan het einde van de QA-fase.

 

Enkele van de belangrijkste nadelen van grey box testing zijn:

 

1. Potentieel voor ongeziene code

 

Grey box testing betekent dat er bepaalde aspecten van de code verborgen blijven voor de tester, en als er problemen optreden in de test kan dit leiden tot verdere problemen.

Met ongeziene code hebben medewerkers die betrokken zijn bij het testen zowel moeite om hun tests zo te sturen dat ze het maximale uit de toepassing halen, als verliezen ze het voordeel dat ze meteen de oorzaak van een probleem zien.

Het proces van bug fixing wordt ondoorzichtiger, waardoor langere updatetijden noodzakelijk worden en bedrijven moeite hebben om de problemen in hun code te vinden.

Eindproducten kunnen door deze ongeziene code bugs bevatten en van een lager niveau zijn.

 

2. Tests kunnen onnauwkeurig zijn als handelingen mislukken

 

Het hebben van nauwkeurige tests is een must bij elke vorm van softwaretests, waarbij een hogere mate van nauwkeurigheid teams wijst op updates die zij in toekomstige versies kunnen voltooien, en daarnaast een ontwikkelingsteam helpt meer vertrouwen te hebben in hun producten.

Deze nauwkeurigheid vermindert wanneer operaties in grey box tests mislukken. Testers krijgen gewoon een “Operatie mislukt” bericht van de software als ze geen toegang hebben tot de code, waardoor ze geen feedback kunnen geven over de manier waarop de software presteert.

Om gunstige metriek te krijgen, moeten ontwikkelaars de software patchen voor de volgende testfase. Anders kan een tester alleen maar zeggen dat de functie in haar huidige vorm niet werkt.

 

3. Strijd met gedistribueerde systemen

 

Gedistribueerde systemen zijn softwaresystemen die op verschillende plaatsen worden gehost, of afhankelijk zijn van functies zoals cloud-hosted data en verwerkingsdiensten.

Dit maakt het testen uiterst moeilijk, omdat een aanzienlijk deel van de software verborgen blijft achter een derde instantie, waarbij de testers eenvoudigweg een output ontvangen van een onbekend proces.

Wanneer zich problemen voordoen met software die gebruik maakt van systemen van derden, kan het moeilijk zijn om vast te stellen of het probleem ligt bij de applicatie zelf, de functionaliteit van derden of de manier waarop de twee geïntegreerd zijn, vooral wanneer een tester de code niet kan zien terwijl die werkt.

 

Kenmerken van Grey Box Tests

Er zijn een paar kenmerken die grey box tests met elkaar delen, waarbij het herkennen van deze tests u helpt een strategie voor uw organisatie op te stellen.

Enkele van de belangrijkste voorbeelden van grey box testkenmerken, naast de wijze waarop deze kenmerken belangrijke onderdelen zijn van het grey box testproces, zijn:

 

– Verhoogde dekking:

Toegang tot een deel van de broncode zorgt voor een grotere dekking in tests, waarbij verdere details een nauwkeuriger opsporing van bugs mogelijk maken.

 

– Gegevensstromen:

Bij veel grey box tests ligt de nadruk op gegevensstromen en het verkrijgen van inzicht in hoe informatie door een systeem beweegt.

 

– Niet-algoritmisch:

Grey box testing werkt niet bij het onderzoeken van algoritmen, want dat is een extra niveau van versluiering van de code.

 

Wat testen we in Grey box tests?

Elk verschillend type test komt het best tot zijn recht wanneer het gericht is op specifieke onderdelen van de software in kwestie. Hetzelfde geldt voor grey box testing, waarbij de methodiek het meest bruikbaar is in enkele onderscheidende delen van een app.

 

Enkele voorbeelden van wat testers beoordelen bij het uitvoeren van grey box tests zijn:

 

1. Beveiliging van de toepassing

 

Grey box tests zijn ideaal voor penetratietests die de veiligheid van een toepassing onderzoeken. Testers kunnen alle code zien en daarbij zoeken naar mogelijke kwetsbaarheden.

Ethische hackers zijn ideale testers voor het testen van applicatiebeveiliging, omdat zij potentiële zwakheden en gebreken in software op een meer natuurlijke wijze herkennen dan degenen die geen ervaring hebben met het doorbreken van softwarebeveiliging.

 

2. Databank testen

 

Veel bedrijven gebruiken grey box testing voor database testing, omdat je de gegevens door elke subfunctie in de software kunt volgen.

Testers kunnen alle wijzigingen die de software aanbrengt zien en beoordelen of deze correct zijn.

Dit is een nuttige implementatie van grey box testing, aangezien databasetests van nature voorspelbaar zijn, waarbij bedrijven databases gebruiken om bestaande informatie te organiseren in plaats van nieuwe gegevens te genereren.

 

3. Webtoepassingen

 

Webapplicaties profiteren van het gebruik van grey box testing vanwege de veelzijdigheid van de testmethode.

Grey box tests kunnen worden gebruikt voor beveiliging, database, integratie, UI en browser testen, stuk voor stuk belangrijke aspecten van webapplicaties.

Het is niet nodig om tussentijds van testmethode te veranderen, dus u profiteert van een grotere continuïteit.

 

Wat verwarring ophelderen:

Grey box vs. White box vs. Black box Testing

Grey box testing is een vorm van testen die verwant is aan zowel white box als black box testing, wat betekent dat er veel kans is op verwarring tussen de methodologieën.

Lees meer over wat white en black box testing zijn en wat de fundamentele verschillen zijn met grey box testing bij softwareontwikkeling:

 

1. Wat zijn white box tests?

 

White box testing is een vorm van applicatietesten die de tester uitgebreide informatie over de applicatie verschaft.

Dit houdt in dat de tester volledige toegang heeft tot de broncode en alle ontwerpdocumenten van de software, waardoor hij een veel beter inzicht krijgt in de manier waarop de software werkt.

Testers gebruiken dit inzicht om meer te zien van de problemen die zich voordoen in de applicatie, en rapporteren een nauwkeuriger perspectief van hoe de applicatie werkt voor gebruikers.

Een voorbeeld van white box testing is het bekijken van de stroom van een specifieke gegevensinvoer door een applicatie om te zien waar zich een probleem voordoet in de processen van de app, in plaats van simpelweg te kijken of er een probleem is of niet.

Er zijn een paar momenten in ontwikkelingsprocessen waarop bedrijven white box tests gebruiken.

De eerste daarvan is bij het uitvoeren van eenheidstests, waarbij wordt nagegaan of elk afzonderlijk stukje code of module in een softwarepakket het werk doet dat de ontwikkelaar verwacht.

Unit testing helpt testers om de meeste problemen in een applicatie te vinden, omdat alle functionaliteit in de app wordt onderzocht.

White box testing helpt ook bij het vinden van geheugenlekken. Door alle code in detail te onderzoeken, vindt een QA-analist waar de applicatie het geheugen van het apparaat gebruikt en mogelijke gebieden waar het veel te veel gebruikt.

Dit helpt de applicatie sneller en efficiënter te draaien in toekomstige iteraties, omdat het geheugenlek zo snel mogelijk een patch krijgt.

 

Wat zijn de verschillen tussen Gray box en White box Tests?

 

Er zijn een paar grote verschillen tussen white box en grey box tests, waarbij de mate van informatie waartoe iemand toegang heeft de eerste verandering is.

White box testing heeft volledige toegang tot de broncode en ontwerpdocumenten voor het programma, terwijl grey box testing slechts gedeeltelijk toegang heeft tot een deel van deze informatie, voornamelijk ontwerpdocumenten.

Deze verandering betekent ook een verschil in de mensen die de tests uitvoeren, waarbij de ontwikkelaars zelf primair verantwoordelijk zijn voor white box tests.

Grey box testing daarentegen is de verantwoordelijkheid van een QA-team, omdat de testers geen grondige kennis van de code kunnen hebben.

Grey box testing kost ook minder tijd dan white box testing. White box testing is end-to-end en onderzoekt zowel de gebruikerskant van de software als de code zelf. Dit neemt veel meer tijd in beslag en betekent dat een grey box testproces veel sneller gaat.

White box heeft echter meer mogelijkheden voor automatisering, omdat de testers weten hoe de interne code werkt.

 

2. Wat is Black Box Testing?

 

Van black box testing is sprake wanneer een tester een softwarepakket onderzoekt zonder enig inzicht te hebben in de werking van het systeem.

Dit betekent dat zij geen toegang hebben tot de code die deel uitmaakt van de toepassing of tot de ontwerpdocumenten of briefings die beschikbaar zijn. Testers hebben gewoon een lijst van functies die ze testen en een reeks testgevallen die ze moeten voltooien.

Een voorbeeld van black box testing is end-to-end testing, waarbij een tester het complete softwarepakket ontvangt en de gehele applicatie test om er zeker van te zijn dat de functionaliteit werkt zoals deze is ontworpen.

De meeste ideale testcases voor black box testing zijn die tegen het einde van een proces, waarbij klanten en hun perspectief op een product betrokken zijn, en waarbij het ontbreken van toegang tot de code voorkomt dat de visie van de gebruiker wordt beïnvloed.

Bedrijven gebruiken black box tests voornamelijk wanneer alle functietests van een applicatie zijn afgerond. Als alle eenheidstesten en functietesten klaar zijn, begrijpen de ontwikkelaars dat de applicatie werkt zoals ze verwachten, tenminste als alle modules geïsoleerd werken.

Black box testing zorgt ervoor dat de totale applicatie na compilatie werkt zoals verwacht, waarbij alle broncode theoretisch al in orde is.

 

Wat zijn de verschillen tussen Grey box en Black box Testing?

 

Het belangrijkste verschil tussen grey box en black box testen is de hoeveelheid toegang die een tester krijgt tot informatie.

In sommige gevallen kan een black box-tester de toepassing benaderen zonder enige voorkennis van de software, en gewoon het testproces doorlopen en de software gebruiken zoals een gewone gebruiker dat zou doen.

Aan de andere kant heeft een grey box tester toegang tot een deel van de ontwerpdocumenten en kan hij dus vergelijken wat de applicatie zou moeten doen met de werkelijke prestaties ervan, waardoor ontwikkelaars feedback krijgen over welke specifieke onderdelen van de app niet voldoen.

Een ander verschil is de hoeveelheid tijd die nodig is om een probleem op te lossen, waarbij tests met een grijze doos iets meer tijd vergen.

Het kruisen van documentatie en code met de manier waarop u de toepassing ervaart kan enige tijd in beslag nemen, wat in strijd is met de manier waarop black box testers werken door simpelweg de toepassing zelf te onderzoeken samen met eventuele functionaliteitsproblemen. Deze combinatie maakt black box testing een ideaal proces om te gebruiken aan het einde van een ontwikkelingsproces bij de voorbereiding van een productrelease, terwijl grey box beter werkt wanneer u in de UI-ontwikkeling en compilatiefase van de ontwikkeling zit.

 

3. Conclusie: Grey box vs. White Box vs. Black Box testen

 

Kortom, white box, grey box en black box testen maken alle deel uit van hetzelfde spectrum, waarbij de variërende factor de mate van toegang is die een tester tijdens het hele proces heeft.

Naarmate een testvorm meer “zwart” wordt, wordt het testen steeds ondoorzichtiger en wordt de toegang tot de informatie achter de software beperkt.

White box testing is ideaal voor de vroegste stadia van het proces, terwijl black box testing uitblinkt voor stadia als end-to-end testing, waarbij de gehele applicatie vanuit het perspectief van de gebruiker wordt bekeken.

Grey box testing fungeert als een middenweg tussen de twee concepten, en helpt problemen te vinden in het midden van het ontwikkelingsproces door meer inzicht te bieden terwijl een deel van de broncode verborgen blijft voor de tester.

 

Grey box testtechnieken

Grey box testing omvat een breed scala aan technieken, die elk de testnorm verhogen, meer bugs voor de ontwikkelaar vinden en leiden tot een completer product aan het eind van het proces.

 

Enkele van de meest voorkomende grey box testing technieken die QA teams gebruiken zijn:

 

1. Matrix testen

 

Matrix testing onderzoekt het statusrapport van het lopende project. Dit omvat in sommige gevallen een eenvoudige PASS/FAIL-status, terwijl lopende processen meer details geven over hoe de processen continu werken.

Waar veel tests zich richten op de inputs en outputs van een stuk code, onderzoeken matrix tests de status van de processen zelf in plaats van de resultaten van die processen.

Het gebruik van matrixtesten zorgt voor een grotere focus op de toepassing zelf, waardoor bugs en problemen worden gevonden, zelfs als de output correct lijkt.

 

2. Regressietests

 

Regressietests bestaan om de software te testen na een reeks updates. Dit omvat zowel functionele als niet-functionele tests die ervoor zorgen dat de applicatie nog steeds voldoende goed werkt als de code verandert.

Testers die regressietests uitvoeren, gebruiken meestal automatisering, omdat regressietests in omvang toenemen naarmate het kwaliteitsborgingsteam meer en meer defecten vindt.

Handmatig testen is in sommige gevallen echter een noodzaak, waarbij bedrijven die de gebruikersinterface testen handmatige tests gebruiken om te zien hoe een menselijke gebruiker reageert op de wijzigingen die zijn aangebracht in menu’s, knoppen en navigatieopties.

 

3. Patroon testen

 

Patroontesten is een vorm van testen die zich richt op het volgen van een specifiek patroon in elke test die een organisatie uitvoert.

Testteams ontwerpen deze tests gericht op elke functie van de software, waarbij elke test een consistent niveau van informatie voor het bedrijf oplevert over de manier waarop individuele functies functioneren.

Bij het testen van patronen moet je soms het patroon aanpassen naarmate de tijd verstrijkt om er zeker van te zijn dat je elk van de systemen die aan het werk zijn beoordeelt, maar als je eenmaal een patroon hebt dat werkt, vermijd je afwijkingen om meer consistentie in je resultaten te krijgen.

 

4. Orthogonale array testen

 

Orthogonal array testing is in de eerste plaats een black-box georiënteerde testtechniek die optreedt wanneer testers een aanzienlijk aantal inputs gebruiken dat te groot is om elk afzonderlijk systeem uitputtend te testen.

In deze gevallen levert elk afzonderlijk gegeven zijn eigen unieke informatie op, omdat er mogelijk geen correlatie bestaat tussen specifieke gegevens. Dit is het orthogonale aspect van het systeem, waarbij unieke stukken informatie worden gebruikt om met minimale inspanningen een maximum aan gegevens te verstrekken.

De testtijd wordt verkort, en u hebt een ideale balans van gegevens om aan een ontwikkelingsteam te verstrekken.

 

Grey box-testen in de levenscyclus van software-engineering

Grey box testing valt in een specifieke fase van de software engineering levenscyclus. Deze levenscyclus is een ingewikkelde reeks stappen die bedrijven volgen bij de ontwikkeling van hun producten, waarbij elke stap leidt tot een hoger productniveau.

Hoewel testen een onderdeel is van het proces dat voortdurend plaatsvindt, is er maar weinig tijd voor grey box tests.

Dit gebeurt nadat de eerste functionaliteit is voltooid en getest door middel van white box tests en voordat de software klaar is voor publieke vrijgave, waarbij bedrijven de voorkeur geven aan black box tests in de laatste stadia.

Grey box is het perfecte instrument om functies samen te voegen en ervoor te zorgen dat ze niet alleen onafhankelijk, maar ook in combinatie met elkaar goed werken.

 

Handmatige of geautomatiseerde Grey Box Tests?

Zoals bij elke vorm van softwaretests hebben kwaliteitsborgingsteams de keuze tussen handmatig testen met behulp van deskundige medewerkers of automatisch testen, waarbij een reeks testgevallen wordt gecodeerd en herhaaldelijk uitgevoerd om tot nauwkeurige resultaten te komen.

Leer meer over handmatig en geautomatiseerd testen, met enkele van de voordelen en uitdagingen van elk, naast welke van de twee vormen van testen ideaal is voor een bedrijf dat de problemen met zijn product beter wil begrijpen.

 

Handmatige Grey Box Testing – Voordelen, Uitdagingen, Proces

 

Handmatig testen is een fundamenteel onderdeel van veel soorten testen, waaronder grey box testen.

Dit proces houdt in dat menselijke testers een stuk software onderzoeken, nagaan of de software werkt zoals u verwacht, en deze vergelijken met de reeds bestaande ontwerpdocumenten en de zichtbare code om na te gaan of hierin duidelijke gebreken zitten die problemen kunnen veroorzaken.

Gevallen waarin handmatig testen gebruikelijk is omvatten meer gecompliceerde stukken software waarvoor een mens nodig is om kwalitatief inzicht te verschaffen.

Andere toepassingen zijn kleinere bedrijven die hun software grondig willen beoordelen, aangezien kleine toepassingen en pakketten relatief weinig middelen vergen van bedrijven om te beoordelen in vergelijking met grotere programma’s van grotere bedrijven.

 

1. Voordelen van handmatig grijs vak testen

 

Er zijn verschillende voordelen van het handmatig testen van een willekeurige software. Als u deze voordelen kent, kunt u uw tests daarop richten, meer problemen in uw software ontdekken en de kwaliteit van uw werk verhogen dankzij een beter testregime.

 

De belangrijkste voordelen van handmatige grey box testing zijn:

 

Gedetailleerde feedback

 

Het eerste grote voordeel van handmatige grey box testing is dat menselijke testers de ontwikkelaar veel feedback kunnen geven.

Bij geautomatiseerd testen worden testgevallen ontworpen om keer op keer zeer specifieke statistieken te produceren die analisten inzicht geven wanneer zij tijd hebben om de gegevens te beoordelen.

Dit is iets anders bij handmatig testen, omdat een tester na vergelijking met de ontwerpdocumentatie grondiger feedback kan geven over welke specifieke functie niet werkte en wat de mogelijke redenen voor het probleem waren.

Het gebruik van gedetailleerde feedback leidt niet alleen tot updates van de bestaande functies, maar ook tot potentiële nieuwe functies die een tester de gebruikers aanbeveelt.

 

Betere interpretaties

 

Geautomatiseerd testen betekent dat alle conclusies een kwestie zijn van het beoordelen van de gegevens die je uit een test ontvangt en het trekken van een rationele conclusie over wat dat betekent voor de software.

Integendeel, handmatige testers hebben veel meer inzicht in de werking van de applicatie zelf.

Zij kunnen de code van de grijze doos vergelijken met wat er in real time gebeurt, zodat zij op dat moment een nauwkeurige inschatting kunnen maken in plaats van achteraf conclusies te moeten trekken.

Sommige automatiseringsplatforms kunnen iets soortgelijks doen door een replay-functie, maar dit vereist nog steeds handmatige interventie.

 

Flexibel testen

 

Bij testautomatisering worden zeer specifieke testgevallen in een platform gecodeerd, waardoor de software die specifieke reeks taken steeds opnieuw uitvoert.

Hoewel dit ideaal is voor herhaling, brengt het een unieke uitdaging met zich mee, omdat er geen flexibiliteit is in de tests.

Het gebruik van een menselijke tester is in deze gevallen ideaal, omdat het proces dan flexibeler wordt. Als een menselijke tester een potentieel probleem opmerkt dat enigszins buiten een nauw omschreven testcase valt, kan hij dat onderzoeken en de resultaten aan het eind van het proces rapporteren.

Dit biedt bedrijven een uitgebreidere dekking van de software, waarbij bugs worden ontdekt die een geautomatiseerd systeem niet kan ontdekken.

 

2. Uitdagingen van het handmatig testen van grijze dozen

 

Hoewel er tal van voordelen zijn aan het gebruik van handmatig testen in uw softwareontwikkelingsproces, zijn er ook verschillende nadelen. Deze variëren afhankelijk van een aantal factoren, waaronder de specifieke software waaraan het bedrijf werkt, de omvang van het ontwikkelingsteam en het vaardigheidsniveau van de leden van de test- en ontwikkelingsteams.

 

Belangrijke uitdagingen bij handmatig testen zijn onder meer

 

Hoge arbeidskosten

 

Arbeidskosten behoren tot de belangrijkste uitgaven die een bedrijf maakt, omdat het betaalt om het beste personeel te krijgen zodat het bedrijf de kwaliteit van zijn werk kan verbeteren.

Aangezien handmatige gray box tests veel tijd kunnen kosten, moet het bedrijf zijn testers betalen om gedurende het hele proces te werken. Voor sommige van de grootste toepassingen kan dit uren duren en de kosten van handmatige testers doen stijgen.

Ontwikkelaars kunnen dit probleem proberen te ondervangen door een evenwicht te vinden tussen automatisering van grijze dozen en handmatig testen, of door te bezuinigen op de kosten van arbeid per uur, maar dit kan de kwaliteit van het testen aantasten.

 

Menselijke fout

 

Geautomatiseerde tests voeren eenvoudige processen doeltreffend uit en herhalen ze met grote nauwkeurigheid op een manier die een mens niet kan.

Mensen maken fouten en kleine vergissingen, die van alles kunnen zijn, van het per ongeluk indrukken van de verkeerde knop tot het verslappen van hun aandacht gedurende een paar seconden.

Fouten als deze kunnen leiden tot onnauwkeurige gegevens en ertoe leiden dat ontwikkelaars hun aandacht richten op het verkeerde deel van de software, waardoor kostbare ontwikkelingstijd verloren gaat en het product slechter wordt.

Probeer dit op te lossen door, waar mogelijk, herhaalde greybox tests uit te voeren om uw resultaten te verifiëren naarmate de tests vorderen.

 

Duurt lang.

 

Waar computers taken in een oogwenk kunnen voltooien, nemen mensen iets meer tijd.

Dit is te wijten aan alles, van reactietijden tot simpelweg langzamer werken dan hun optimale snelheid op sommige punten, wat het testproces vertraagt.

Een trager testproces betekent minder tijd voor ontwikkelingsteams om te werken aan het verwijderen van bugs en gebreken in het product, omdat alle tijd gaat naar het vinden van de problemen in de eerste plaats.

Dit is niet eenvoudig te ondervangen, waarbij een hybride testregime, zoals het balanceren van handmatige tests met geautomatiseerde grey box tests, een mogelijke oplossing is.

 

Gray box Test Automation – Voordelen, Uitdagingen, Proces

Testautomatisering verwijst naar het gebruik van een automatiseringsplatform om sommige onderdelen van het grey box testproces automatisch te maken.

Het proces werkt door testontwerpers te vragen een reeks testgevallen te creëren, waarbij QA-analisten of soortgelijke professionals deze tests coderen in de automatiseringsprogramma’s, waarbij sommigen robotische procesautomatisering gebruiken als extra hulpmiddel.

In deze gevallen begrijpen QA-analisten al een deel van de code of ontwerpdocumenten.

Dit soort testen komt vaker voor bij veel grotere softwarepakketten, omdat grey box testers niet de tijd hebben om alle aspecten van het proces handmatig grondig te testen.

Na een geautomatiseerd proces stuurt het platform een rapport terug voor de QA-analist, waarin staat waar er fouten zijn en een reeks belangrijke metrieken.

 

1. Voordelen van geautomatiseerde grey box testing

 

Er zijn een paar duidelijke voordelen van het gebruik van geautomatiseerde grey box tests in de processen van een kwaliteitsborgingsteam.

Door zich op deze voordelen te concentreren en ze optimaal te benutten, kan een bedrijf de doeltreffendheid van zijn grey box tests verhogen en zoveel mogelijk problemen in dit stadium van de workflow oplossen.

 

Enkele van de belangrijkste voordelen van het gebruik van automatisering bij uw grey box testwerk zijn:

 

Snel testen

 

Geautomatiseerde systemen zijn ontworpen om ongelooflijk snel te testen, door zo snel mogelijk een reeks processen te doorlopen. Dit voordeel wordt nog groter bij herhaalde gray box tests, omdat elke afzonderlijke run minder tijd kost.

De hoeveelheid tijd die u bespaart van run-to-run neemt aanzienlijk toe, waarbij uw bedrijf veel meer tijd heeft voor dringende taken zoals het bijwerken van de software zelf en het geven van feedback aan klanten en potentiële klanten.

Sneller testen is vooral nuttig bij post-release werk, omdat het zo snel mogelijk pushen van functionaliteitfixes een must is voor het verbeteren van de manier waarop mensen het bedrijf zien.

 

Nauwkeurige statistieken

 

Metrieken zijn een belangrijk onderdeel van de manier waarop softwaretests werken, omdat ze een tester numerieke informatie verschaffen om potentiële problemen aan te geven.

Computers en automatiseringsplatforms bieden zeer nauwkeurige statistieken, waarbij zaken als reactietijden tot op de milliseconde nauwkeurig kunnen worden gemeten.

Met nauwkeurigere statistieken kunt u kleine verschuivingen in de prestaties van een app volgen, zodat u weet of een update de prestaties heeft verbeterd of dat standaardworkflows meer tijd in beslag nemen.

 

Lagere kosten

 

Een van de grootste kosten van het testen in een software gray box ontwikkelingsomgeving is die van de grey box testers zelf.

Het inhuren van software test experts is duur, vooral wanneer u op zoek bent naar grey box testers, die een grotere verscheidenheid aan vaardigheden vereisen, om de hoogst mogelijke normen voor uw organisatie te leveren.

Automatisering betekent dat er minder mensen zijn die handmatige grey box tests uitvoeren, waardoor veel personeelskosten uit het proces verdwijnen.

Hoewel automatiseringsplatforms enige kosten met zich meebrengen, waarvan de meeste een abonnement op maandbasis vragen, is dit veel lager dan werknemers te moeten betalen om het werk voor u te doen.

 

2. Uitdagingen van het geautomatiseerd testen van grijze dozen

 

Er zijn tal van uitdagingen bij het gebruik van automatisering in uw grey box testprocessen.

Hoewel sommige organisaties zich concentreren op de voordelen, zijn er ook veel voordelen verbonden aan het kennen van de uitdagingen van gray box testing en het overwegen daarvan tijdens het werk.

U kunt grey box tests uitvoeren op een manier die de uitdagingen vermijdt en voorkomt dat u voortaan worstelt met beperkingen.

 

De belangrijkste uitdagingen van het geautomatiseerd testen van grijze dozen zijn:

 

Eerste installatie

 

De eerste opzet is een van de grootste uitdagingen van het automatiseringsproces. Dit heeft betrekking op de tijd die nodig is om over te stappen op een nieuw testplatform, inclusief de installatie van het platform, het leren van gebruikers hoe ze ermee moeten werken en het coderen van vroege tests op de software.

Dit is allemaal onproductieve tijd die een bedrijf zoveel mogelijk zal willen beperken.

In dit geval is het gebruik van automatiseringssoftware van topkwaliteit met deskundigen die klaarstaan wanneer dat nodig is, ideaal, omdat u ondersteuning van derden hebt die ervoor zorgt dat uw automatisering van grijze dozen, en andere soorten tests in dit verband, vanaf het begin soepel verloopt.

 

Hoge vaardigheidseisen

 

Hoewel handmatig testen een hoog vaardigheidsniveau vereist, moeten QA-analisten die met automatisering werken nog steeds over een hoog vaardigheidsniveau beschikken.

Dit komt in de vorm van codeervaardigheden, die vooral worden gebruikt om testgevallen te maken en de code te lezen die beschikbaar is in het scenario van de grijze doos.

Ontwikkelaars kunnen dit verzachten door specifiek testers in te huren die ervaring hebben met ontwikkeling of in het verleden met codeerprojecten hebben gewerkt. U beperkt de opleidingstijd op de werkplek en zorgt ervoor dat elke nieuwe aanwinst de capaciteit heeft om zich aan te passen aan de vereisten van grey box geautomatiseerd testen.

Sommige bedrijven willen als alternatief een codeloos automatiseringssysteem gebruiken om gray box tests uit te voeren, maar dit kan leiden tot minder flexibiliteit op de werkplek.

 

Voortdurend toezicht

 

Geautomatiseerd testen bestaat gedeeltelijk om de nadruk weg te nemen van het vertrouwen op mensen, waarbij bij handmatig testen voortdurend mensen betrokken zijn.

Het is niet de bedoeling dat dit het geval is met testautomatisering, maar bedrijven moeten toch een goed niveau van toezicht hebben.

Oversight houdt in dat de uitkomsten van de grey box tests worden onderzocht en onderhouden om er zeker van te zijn dat alles nog steeds werkt zoals de ontwikkelaar verwacht.

Bedrijven kunnen het niveau van het beschikbare toezicht op een aantal manieren helpen verbeteren, waarbij het ideaal is dat één deskundige verantwoordelijk is voor het toezicht op de tests.

Dit leidt tot een grotere specialisatie, waarbij die medewerker sneller en effectiever een grey box expert-tester wordt in het werken met automatisering.

 

Conclusie: Handmatig of Grey box Test Automation?

Kortom, zowel handmatige als geautomatiseerde tests hebben hun plaats in het testproces van software.

Kleinere bedrijven en startups hebben baat bij het uitvoeren van handmatige grey box tests wanneer hun code relatief klein en beheersbaar is, waarbij automatisering steeds nuttiger wordt naarmate toepassingen blijven groeien en meer functies krijgen.

Toch zal er altijd een plaats zijn voor handmatig testen, dankzij het grotere inzicht, de gedetailleerdheid en de flexibiliteit die het bedrijven biedt.

De ideale grey box-oplossing voor elk bedrijf is een hybride model, waarbij handmatige en geautomatiseerde tests op verschillende punten worden gebruikt om rekening te houden met de sterke en zwakke punten van beide technieken.

Een holistische aanpak legt meer van de problemen van een softwarepakket bloot, waardoor de software effectiever kan worden gerepareerd en de klanten uiteindelijk een veel beter product krijgen aan het eind van de ontwikkeling.

 

Wat heb je nodig om te beginnen met Grey Box Testing?

Er zijn een paar voorwaarden die bedrijven nodig hebben voordat zij met hun grey box testprocessen beginnen. Deze maken het testproces mogelijk of maken het testen van software veel eenvoudiger voor het kwaliteitsborgingsteam, omdat zij over meer middelen beschikken.

 

De voorwaarden voor het uitvoeren van grey box tests omvatten:

 

1. Ontwerpdocumenten of broncode

 

Het eerste wat je nodig hebt om het grey box testproces te starten is de ontwerpdocumentatie of de broncode. Testers moeten toegang hebben tot deze informatie om de test te kunnen beschouwen als een grey box test, die enig inzicht biedt in de innerlijke werking van de software zelf.

Deze informatie moet zo relevant mogelijk zijn, bijvoorbeeld de codestring voor de specifieke functie die de tester onderzoekt.

Bij het gebruik van grey box in plaats van white box testen verstrekt u slechts een deel van de code en ontwerpdocumentatie, dus wees voorzichtig met het niveau van toegang dat u verstrekt.

 

2. Productoverzicht

 

Een productbrief of application brief is een document dat bedrijven gebruiken om een volledig inzicht te krijgen in wat een klant zoekt in een softwarepakket. Hierin worden de exacte functionaliteit die een klant zoekt van de software, de vormgeving die een klant wenst en eventuele andere specificaties die nodig zijn, gedetailleerd vastgelegd.

Het lezen van een productbeschrijving betekent dat een grey box tester kan zoeken naar alle functies die een klant wil, ervoor zorgen dat die in de software zitten en ervoor zorgen dat het product voldoet aan alle doelstellingen die een bedrijf voor zijn toepassing heeft.

Sommige bedrijven beperken de hoeveelheid informatie die gray box testers kunnen zien, afhankelijk van het vertrouwelijkheidsbeleid in het bedrijf.

 

3. Testdoelstellingen

 

Ontwikkelaars en bedrijven hebben specifieke doelen bij het uitvoeren van tests, ook wel testspecificatie genoemd. Dit is zeer belangrijk in het grey box testproces, omdat het betekent dat ontwikkelaars grey box testers kunnen voorzien van alle juiste informatie, waarbij het kwaliteitsborgingsteam tests ontwerpt die overeenkomen met de doelstellingen voor het testproces.

Iedereen werkt in dit geval effectiever, omdat ze weten wat ze zoeken en hoe ze die doelen het best kunnen bereiken.

 

Grey box testproces

Grey box testing volgt een relatief consistent proces, met duidelijke stappen die de afzonderlijke stadia aangeven die een bedrijf moet doorlopen om zijn testdoelstellingen te bereiken.

Het duidelijk en consequent volgen van het proces levert nauwkeurige en consistente resultaten op die ontwikkelaars informeren over waar eventuele problemen zitten en hoe deze kunnen worden opgelost.

 

De belangrijkste stappen in een grey box test zijn:

 

1. Bepaling van inputs en outputs

 

De eerste stap in het proces is het bepalen van de inputs en outputs die u van de toepassing verwacht.

Kies een invoer die ligt binnen de grenzen van wat de app normaal gesproken zou moeten kunnen verwerken, zodat het een eerlijke test wordt, en bereken de uitvoer die u van die invoer verwacht.

Door deze voorspelling aan het begin van het project uit te voeren, weet u of er aan het eind van de tests iets mis is gegaan.

 

2. Identificeren van primaire stromen

 

Primaire stromen zijn de routes die gegevens in een stuk software volgen om hun uiteindelijke uitvoer te bereiken.

Door de primaire stroom te identificeren, kunt u beter nagaan hoe de informatie door de processen van een stuk software gaat, wat de potentiële gebieden zijn waar gebreken kunnen optreden en hoe u die kunt verhelpen als er een probleem is met de software.

 

3. Identificeer subfuncties, met inputs en outputs

 

Subfuncties zijn basisbewerkingen binnen een primaire stroom. Elke subfunctie wordt gevoed door een andere en voedt de volgende, wat uiteindelijk leidt tot de uiteindelijke output van de software.

Stel vast wat de input voor elke subfunctie moet zijn, samen met de verwachte output voor elke subfunctie.

Door dit op subfunctieniveau te doen, wordt een extra niveau van inzicht verkregen bij het opsporen van eventuele softwareproblemen.

 

4. Ontwikkelen van een testcase

 

Een testcase verwijst naar een reeks gebeurtenissen die in de software optreden en die nagaan of de toepassing presteert zoals u verwacht.

Zorg ervoor dat deze grey box test case het deel van de software dat u bekijkt goed onderzoekt.

Focus ook op consistentie, zorg ervoor dat de testcase gemakkelijk te repliceren is om preciezere resultaten te krijgen van je gray box test.

 

5. Het testgeval uitvoeren

 

Begin de testcase uit te voeren.

Hierbij worden de inputs in elk van de subfuncties ingevoerd en wordt gekeken wat de outputs zijn, waarbij alle resultaten worden genoteerd.

Bij geautomatiseerde grey box tests verloopt het registratieproces automatisch, waarbij de handmatige testers zelf aantekeningen maken van alle inputs en outputs.

Test, indien mogelijk, alle subfuncties afzonderlijk voordat u de hele stroom in één keer uitvoert, om te controleren of elke functie onafhankelijk werkt.

 

6. De resultaten verifiëren

 

Nadat u de gegevens van de testcase hebt ontvangen, begint u met de verificatie van deze resultaten.

Dit betekent dat u kijkt naar de outputs die u van de software krijgt en deze vergelijkt met de outputs die u aan het begin van het proces verwachtte.

Als er een verschil is tussen de twee, wijst dit erop dat er een bug in de software kan zitten, aangezien deze niet presteert op de manier die u aanvankelijk had verwacht.

 

7. Maak een verslag

 

Maak aan het eind van het grey box-testproces een rapport over de resultaten van de test.

Dit omvat een basissamenvatting van wat de problemen met de software waren, een beoordeling van enkele mogelijke oplossingen voor de problemen en, waar mogelijk, alle gegevens die de tests hebben opgeleverd.

Het gebruik van deze structuur geeft de lezer een hoofdles alvorens alle nodige bewijzen te leveren, zodat het uiteindelijk een samenhangend document wordt dat veel houvast biedt.

 

Beste praktijken voor Greybox-tests

Beste praktijken verwijzen naar processen, taken en principes die medewerkers in een QA-test uitvoeren om de hoogst mogelijke normen te bereiken.

 

Enkele van deze best practices voor QA-teams die de standaard van hun werk willen verhogen zijn:

 

1. Werk zorgvuldig

 

Zoals bij elke testmethode moet u de tijd nemen en zorgvuldig te werk gaan. Een enkele fout kan een test ongeldig maken, dus langzaam en gestaag werken om ervoor te zorgen dat uw werk nauwkeurig is, bespaart u op de lange termijn tijd en verbetert de kwaliteit van de software. Dit geldt vooral bij grey box testing, omdat je niet weet met welke delen van de broncode je op een bepaald moment werkt.

 

2. Communiceer voortdurend

 

Er moet een constante communicatie zijn tussen ontwikkelaars en grey box testers. Dit geeft ontwikkelaars direct feedback over bugs die het testteam ontdekt en betekent dat testers weten waar ze op moeten letten.

Als de bug deel uitmaakt van het zichtbare aspect van de grijze doos, laat de ontwikkelaars dan precies weten waar hij zit.

 

3. Strikte grenzen stellen

 

Wanneer bij grey box testing kunstmatige beperkingen op informatie worden gebruikt, waarbij het bedrijf zelf beslist welke informatie aan de testers wordt gegeven, zorg dan voor strikte beperkingen.

Geef het QA team alleen de rechten die ze nodig hebben, anders loop je het risico dat ze “achter het gordijn kijken” en sommige broncode of ontwikkelingsdocumenten zien die je verborgen probeert te houden.

 

7 fouten en valkuilen bij het uitvoeren van Grey Box Tests

Met honderdduizenden toepassingen die elk jaar het testproces doorlopen, zijn er enkele fouten en valkuilen waar QA-teams in trappen.

Als u deze kent, kunt u ze effectief vermijden, waardoor uw werk verbetert en de kans kleiner wordt dat u middelen verspilt aan slechte teststrategieën.

 

Enkele van de meest voorkomende fouten en valkuilen bij grey box tests zijn:

 

1. Testen van gedistribueerde systemen

 

Grey box testing vereist toegang tot de broncode, en gedistribueerde servers gebruiken code van andere locaties. Dit zorgt voor problemen bij grey box testing, omdat het betekent dat er problemen zijn die testers misschien niet kunnen zien.

 

2. Het voltooien van inconsistente testen

 

Inconsistent testen verwijst naar een situatie waarin een testgeval varieert tussen runs. Dit kan leiden tot onnauwkeurige resultaten, waarbij ontwikkelaars zich vervolgens richten op het verbeteren van de prestaties op basis van onjuiste statistieken.

Maak elke test waar mogelijk identiek om de precisie en de nauwkeurigheid van de tests te vergroten.

 

3. Haastige tests

 

Als een voorgestelde productreleasedatum nadert, kunnen QA-teams in de verleiding komen om haast te maken met grey box testprocessen.

Dit is echter een teken van slechte planning, en moet niet worden beantwoord met meer slechte beslissingen. Overhaast testen leidt tot onnauwkeurige resultaten en tijdverlies later in de ontwikkelingsfase.

 

4. Handmatige en automatisering niet samen uitvoeren

 

Noch handmatig testen, noch geautomatiseerd testen zijn perfecte methoden voor grey box testing.

Door de twee naast elkaar te gebruiken, kunt u rekening houden met de problemen van beide, waardoor u uiteindelijk effectiever werkt.

Overweeg op zijn minst de twee methoden te combineren om beter te kunnen testen.

 

5. Werken zonder gereedschap

 

Testtools zijn ontworpen om het werken als grey box tester zo gemakkelijk mogelijk te maken. Werken zonder gereedschap beperkt onnodig je eigen mogelijkheden.

Onderzoek en koop grondig alle hulpmiddelen die uw ontwikkeling kunnen helpen om de efficiëntie te verhogen en de kans op fouten te verminderen.

 

6. Slechte communicatie

 

Interne communicatie tussen afdelingen kan een strijd zijn, maar zo duidelijk mogelijk communiceren is een must tussen test- en ontwikkelingsafdelingen.

Betere communicatie betekent dat ontwikkelaars weten welke verbeteringen ze onmiddellijk moeten aanbrengen en problemen kunnen oplossen zonder misleid te worden door slechte interne berichtgeving.

 

7. Actief zoeken naar bugs

 

Grey box tests bestaan om eventuele bugs te vinden, maar ook om de algemene prestaties van de software te onderzoeken.

Te lang bezig zijn met het vinden van bugs kan veel tijd in beslag nemen en afleiden van het hoofddoel, namelijk de werking van een app verbeteren.

 

Soorten outputs van Gray Box Tests

Grey box tests genereren verschillende soorten informatie aan het eind van een proces. Daarbij gaat het niet om de output van de software zelf, maar om de gegevens die ontwikkelaars kunnen gebruiken om de software te verbeteren.

 

De belangrijkste soorten output zijn:

 

1. PASS/FAIL-berichten

 

Een eenvoudig PASS/FAIL-bericht dat een ontwikkelaar informeert of de softwareoperatie een succes was.

Dit soort output geeft een ontwikkelaar niet veel inzicht, maar het gebruik van grey box testing betekent dat een tester kan zien op welk specifiek punt de software faalde en waarom, wat helpt om het probleem op te lossen.

 

2. Metriek

 

Metrieken verwijzen naar eenvoudige statistieken die een gebeurtenis weergeven, zoals de tijd die nodig is om een bepaalde taak tot op de milliseconde nauwkeurig uit te voeren. Deze komen vaak voor bij geautomatiseerde grey box tests, waarbij computerplatforms deze informatie automatisch verzamelen met een grotere nauwkeurigheid dan een handmatige tester zou kunnen.

Deze informatie is nuttig voor het vaststellen van de prestaties van een app.

 

3. Kwalitatieve gegevens

 

Beschrijvende informatie die u krijgt van een gray box tester uit hun ervaring met de software. Onkwantificeerbaar, wat analyse moeilijker maakt, maar een beter inzicht geeft in de gebruikerservaring en klanten meer vertrouwd maakt met de software.

 

Voorbeelden van Grey Box Tests

In sommige gevallen biedt het kennen van de theorie rond een vorm van testen niet genoeg inzicht, en levert het geen goed begrip op. Kennis van enkele voorbeelden van grey box tests is essentieel om uw begrip van de werking van de testmethodologie te verbeteren.

Zie hieronder enkele voorbeelden van tests in de grijze doos die meer details geven over tests in de echte wereld en hoe de theorie van toepassing is op praktische werkplekken.

 

1. Voorbeeld van een succesvolle beveiligingstest

 

Een bedrijf creëert een database met veel persoonlijke gegevens en plant veiligheidstests om ervoor te zorgen dat de gebruikersgegevens worden beschermd.

Een handmatige tester doorloopt het proces, op zoek naar mogelijke fouten in de code en mogelijkheden om toegang te krijgen tot delen van de applicatie.

Nadat hij een zwakke plek heeft gevonden, deelt de tester de ontwikkelaar mee waar de zwakke plek zich bevindt en hoe hij deze heeft uitgebuit.

Wanneer de software is gepatcht, voert de tester dezelfde test opnieuw uit om er zeker van te zijn dat het systeem veilig is.

 

2. Voorbeeld van mislukte databasetests

 

Ontwikkelaars die een database maken hebben een strakke deadline voor de release en moeten snel testen.

De testers razen een paar basistestcases bij elkaar en werken ze snel af, waarbij ze fouten maken bij de uitvoering, geen outputvoorspellingen maken en nalaten subfuncties te onderzoeken.

Aangezien zij geen outputprognoses opstellen, realiseren zij zich geen outputproblemen, waardoor zij een product verzenden dat niet goed werkt.

 

Soorten fouten en bugs die door Grey box Testing worden opgespoord

Een van de belangrijkste doelen van grey box testing is het vinden van fouten en bugs in een programma, waarbij bedrijven waar mogelijk hoogwaardige apps willen leveren waar hun klanten op kunnen vertrouwen.

Er zijn een paar specifieke soorten fouten en bugs die testers kunnen vinden in het grey box testproces, die elk kunnen wijzen op een ander probleem met de code.

 

De soorten fouten en bugs die bij grey box testing worden opgespoord zijn onder meer:

 

1. Processtoring

 

De eerste vorm van fouten is het falen van het proces.

Dit is wanneer de test geen enkel resultaat oplevert en gewoon vastloopt.

Er bestaan verschillende mogelijke oorzaken van deze problemen, en in het ideale geval kan een grey box tester vaststellen waar een probleem vandaan komt en hoe een ontwikkelaar een antwoord kan coderen.

 

2. Onjuiste output

 

Sommige fouten bij grey box testing treden op wanneer de output van een proces niet de output is die de ontwikkelaars verwachten.

Dit is een ernstig probleem in gevallen zoals een databank, waarin het veilig bewaren van correcte informatie een noodzaak is.

 

3. Veiligheidsfouten

 

Beveiligingsfouten doen zich voor wanneer de toepassing van een bedrijf enigszins onveilig is en derden toegang verleent tot de daarin opgeslagen informatie.

Veiligheidslekken in een toepassing kunnen een GDPR-probleem vormen en ervoor zorgen dat de toepassing niet voldoet aan een reeks internationale voorschriften.

 

Gemeenschappelijke Grey Box testcriteria

Metrieken verwijzen naar constante metingen die een bepaalde gebeurtenis of reeks gebeurtenissen onderzoeken, meestal in de vorm van kwantitatieve gegevens.

Door het gebruik van metrieken kunnen testers en kwaliteitsborgingsteams de software die een greybox-test ondergaat, onderzoeken en precies zien wat er fout gaat, of dat nu is in de vorm van meer fouten of verschillende functies die er langer over doen om te laden.

 

Enkele van de meest voorkomende grey box testing metrieken die QA testers gebruiken bij het beoordelen van software zijn:

 

– Tijd tot uitvoer:

De hoeveelheid tijd die de toepassing nodig heeft om een uitvoer te produceren na de start van de test.

 

– Tijd om te reageren:

De tijd die de software nodig heeft om te reageren op input van de gebruiker, in de vorm van een resultaat of gewoon een bevestiging van de input.

 

– Aantal fouten:

Het zuivere aantal fouten dat de software in zijn processen heeft.

 

– Fouten per functie:

Het aantal bestaande fouten gedeeld door het aantal functies in de software, gebruikt om de foutdichtheid vast te stellen.

 

Beste Grey Box Test Tools

Grey box testing kan vertrouwen op externe hulpmiddelen om de kwaliteit van uw werk te verbeteren, door sommige processen te automatiseren en u te ondersteunen bij het maken van een oplossing voor gevonden bugs.

Hoe beter het testinstrument dat u gebruikt, hoe meer problemen u zult ontdekken en hoe beter de kwaliteit van uw eindproduct zal zijn, terwijl u tijdens het testen tijd en middelen bespaart.

Bekijk hieronder enkele van de beste grey box testing tools, naast de voor- en nadelen van het gebruik van elk platform.

 

5 beste gratis Grey Box testtools

 

Wanneer een kleiner bedrijf wil beginnen met grey box testing, is het hebben van de juiste tools een must, maar het hebben ervan tegen een redelijke prijs kan net zo belangrijk zijn. Elke cent telt in een klein bedrijf, en een app-ontwikkelaar is niet anders, met krappe budgetten die leiden tot moeilijke beslissingen.

Het gebruik van gratis grey box testing tools is perfect voor kwaliteitsborging met minimale middelen.

 

Enkele van de beste gratis grey box testing tools zijn:

 

1. ZAPTEST GRATIS EDITIE

De gratis editie van ZAPTEST biedt een hoogwaardige automatiseringservaring voor zijn gebruikers, met full-stack softwareautomatisering die het testen vanaf het begin van de ontwikkeling ondersteunt.

Met parallelle uitvoering kunt u meerdere tests tegelijk uitvoeren om uw processen te versnellen, en wanneer u klaar bent om de sprong naar het volgende niveau te maken, maakt de Enterprise-editie de overgang zo eenvoudig als maar kan. Als extra voordeel biedt ZAPTEST ook geavanceerde RPA-technologie, zonder extra kosten.

De perfecte keuze voor iemand in het begin van zijn testperiode.

 

2. Appium

 

Appium is een grondige testtool om ervoor te zorgen dat mobiele apps aan de normen voldoen. Appium heeft een actieve ondersteuningsgemeenschap, maar voert tests relatief langzaam uit. In combinatie met een moeilijke opzet is dit voor veel bedrijven niet de beste gratis tool.

 

3. Chrome hulpmiddelen voor ontwikkelaars

 

Google Chrome biedt een reeks ontwikkeltools voor webapps, en met de integratie in de populairste browser lijkt het een must.

Het is echter beperkt tot het testen van boxelementen, waardoor het een beperkt testinstrument is.

 

4. JUnit

 

JUnit is een open-source framework waarmee gebruikers keer op keer herhaalbare tests kunnen uitvoeren in Java, waarbij het beperkt blijft tot één enkele taal.

Op zich is deze limiet geen probleem, maar het gebrek aan een eenvoudige API en interface kan het voor nieuwere testers afschrikwekkend maken.

 

5. DBUnit

 

DBUnit richt zich op de ondersteuning van database-georiënteerde projecten, waarbij bekende toestanden worden gebruikt om de resultaten nauwkeurig te verifiëren en de resultaten uitgebreid te onderzoeken.

Dit is perfect voor databases en soortgelijke toepassingen, maar een gebrek aan integratie-ondersteuning betekent dat het moeite heeft met cross-platform taken.

 

5 beste Enterprise Grey Box Testing tools

 

Naarmate een ontwikkelaar groeit, groeien ook zijn testvereisten, waarbij grotere bedrijven grotere toepassingen hebben en daardoor uitgebreidere testpakketten nodig hebben.

Enterprise grey box testing tools bestaan om bedrijven in deze situatie te ondersteunen, en bieden meer toegang tot geavanceerde functies die amateur en kleinschalige ontwikkelaars misschien niet nodig hebben.

 

Enkele van de beste enterprise-grade test tools bij het uitvoeren van een grey box test zijn:

 

1. ZAPTEST ENTERPRISE EDITIE

De Enterprise-editie van ZAPTEST biedt meer testmogelijkheden dan de gratis versie, met als een van de belangrijkste voordelen de constante toegang tot een ZAP Expert. Een ZAP Expert fungeert in feite als adviseur en lid van uw team op afstand en ondersteunt alle testbehoeften van uw bedrijf.

Ontwikkelaars die investeren in ZAPTEST Enterprise edition kunnen tot tien keer het rendement op hun investering zien dankzij geavanceerde Computer Vision-technologieën, 1SCRIPT, platform-, apparaat- en browseroverschrijdende uitvoering en bovenal onbeperkte licenties.

De onbeperkte licenties, in aanvulling op de meest geavanceerde test- en RPA-technologie, betekent dat ondernemingen profiteren van vaste kosten, ongeacht hoe snel en hoeveel ze groeien.

 

2. TestRail

 

Een oplossing voor het beheer van testcases waarmee u alle tests die u uitvoert per testcase kunt opsplitsen, zodat de gegevens nauwkeuriger worden geregistreerd.

TestRail is echter niet per se ideaal voor grey box tests, omdat het moeite heeft een evenwicht te vinden tussen handmatig testen en het geautomatiseerd vastleggen van tests.

 

3. Testim

 

Een testplatform dat zich richt op het aanbieden van stabiele tests op maat, waarbij zowel gecodeerde testgevallen als niet-gecodeerde alternatieven worden geïmplementeerd.

Aangezien dit alleen gratis is voor een bepaald aantal tests per maand, kunnen grotere organisaties moeite hebben om het maximale uit dit platform te halen.

 

4. TestRigor

 

TestRigor is een alom gewaardeerd platform dat een AI-engine gebruikt om tests te voltooien, waarbij AI-testonderhoud een van de aantrekkelijkere functies is.

Dit komt echter tegen een aanzienlijke prijs; andere platforms geven een beter rendement op de investering.

 

5. Kobiton

 

Kobiton is een testplatform met een relatief flexibele prijsstelling, waarbij tests per gebruiker worden geautomatiseerd na afloop van een gratis proefperiode.

Een zorg die sommige gebruikers hebben rond Kobiton is een relatief gebrek aan ondersteuning van Kobiton als het gaat om het oplossen van vragen van testers.

 

Wanneer moet u Enterprise vs. Freemium Grey box tools gebruiken?

Zowel enterprise als freemium grey box tools bieden hun gebruikers tal van voordelen. Bedrijven beginnen idealiter met een freemiumproduct om het testproces te leren kennen en gaan dan over op een bedrijfseditie als hun behoeften toenemen.

Dit zorgt voor een zekere continuïteit in het project en beperkt de herscholing van het personeel.

Het omschakelingspunt verschilt van bedrijf tot bedrijf, maar op een bepaald moment wordt het rendement van een ondernemingsproduct onvermijdelijk.

 

Checklist grijze doos testen, tips en trucs

Grey box testing is een vrij complex proces, dus met een checklist om mee te werken kunt u er zeker van zijn dat u alles hebt gedaan wat u moet doen.

 

Enkele van de belangrijkste kenmerken van een grey box checklist, naast enkele tips om de kwaliteit van uw tests te verbeteren, zijn:

 

1. Grondige planning

 

Uitgebreide planning is een van de eerste dingen om af te vinken in een test, want ervoor zorgen dat je absoluut elk aspect van een test plant is een must.

Hoe meer u plant, hoe meer structuur er achter uw tests zit, want de mensen weten welke tests ze afwerken en wanneer ze dat doen.

Dit leidt ook tot consistente gegevens, wat ideaal is voor betere oplossingen voor ontwikkelaars.

 

2. Onmiddellijke rapportage van gegevens

 

Wanneer u werkt aan een grey box testproces, probeer dan onmiddellijk gegevens te rapporteren. Door rapporten zo snel mogelijk te maken, verhoogt u de nauwkeurigheid van uw rapportageprocessen omdat alle informatie vers in het geheugen ligt.

Dit geldt met name voor kwalitatieve informatie, aangezien deze door de tester moet worden geschreven in plaats van eenvoudigweg te worden opgeslagen op een testplatform.

 

3. Verantwoordelijkheden vaststellen

 

Zorg er tijdens de testprocessen voor dat iedereen op de werkplek zich richt op het hebben van specifieke verantwoordelijkheden. Door de verantwoordelijkheden op deze manier vast te leggen, weet iedereen wat zijn rol is op de werkplek en weet hij hoe hij zijn taken productief en met minimale onderbrekingen moet uitvoeren.

Hoewel dit meer een managementconcept is dan een checklistpunt, heeft het een grote invloed op de resultaten.

 

4. Constante vergelijking

 

Vergelijk uw resultaten met verschillende dingen op een bijna constante basis. Vergelijkingspunten zijn de oorspronkelijke ontwerpdocumentatie, eerdere testresultaten en het tijdschema van de organisatie voor de voltooiing van het project.

Met deze referentiekaders weet u altijd hoe het softwareontwikkelingsproces verloopt, waar verbeteringen mogelijk zijn en welke aanpassingen mogelijk zijn.

 

Conclusie

 

Concluderend, grey box testing is een van de meest veelzijdige vormen van testen die beschikbaar zijn, waarbij de functionaliteit van white box wordt gecombineerd met de biasbeperking van black box tests.

Door handmatige en geautomatiseerde testmethoden te combineren in uw grey box inspanningen, kunnen bedrijven de impact van bugs op hun software aanzienlijk verminderen door fixes aan te brengen die leiden tot een beter product.

Grey box testing is het perfecte hulpmiddel voor elke ontwikkelaar, en de bovenstaande tips kunnen ervoor zorgen dat u het goed gebruikt.

 

Veelgestelde vragen en bronnen

Als u vragen hebt over grey box testing, bekijk dan enkele van onze veelgestelde vragen om meer te weten te komen en uw begrip van dit type test te verbeteren:

 

1. Beste cursussen over Grey box Test Automation

 

Er zijn relatief weinig cursussen die specifiek gericht zijn op grey box testautomatisering, waarbij deze algemene software test cursussen een ideale manier zijn om te beginnen:

– “Software Testing Foundation met examen”- Opleidingsaanbiedingen

– “6-weekse Software Testing Essentials Training”- Futuretrend Technologies Ltd

– “Cursus Software Testen”- Koninklijke cursus

– “Black-box en white-box testen” – Coursera

– “Software Testing – Black-Box Strategieën en White-Box Testing”- NPTEL

 

2. Wat zijn de top 5 interviewvragen over Grey Box Testing?

 

– Welke ervaring heeft u met grey box testing, en hoe vond u dat?

– Waarom gebruiken bedrijven grey box tests, en op welk punt in het proces?

– Vergelijk white box, grey box en black box testen

– Wat zijn enkele van de grootste uitdagingen van grey box testing en hoe kun je die overwinnen?

– Hoe werkt testautomatisering?

 

3. Beste YouTube-tutorials over Grey Box Testing

 

– “Wat is Gray Box Testing? Wat zijn technieken die gebruikt worden in Gray Box Testing? Met voorbeeld uitgelegd”- Software Testing Hacks

– Gray box testing | software engineering |”- Education 4u

– “Black Box, White Box en Grey Box Testing” – Miracle Education

– Advies voor nieuwe handmatige QA-testers | Werken met ontwikkelaars + dingen die ik heb geleerd als softwaretester”- Madeline Elaine

– “Wat is Grey Box Testing? (Software Testing Interview Vraag #54)”- QA Fox

 

4. Hoe Grey Box Tests onderhouden?

 

Het onderhouden van uw grey box tests is een vrij eenvoudig proces. Zorg er bij handmatig testen voor dat de medewerkers goed zijn opgeleid en telkens dezelfde taken uitvoeren. Lees voor geautomatiseerde tests alle code voor testgevallen en controleer de resultaten.

 

5. Beste boeken over Grey Box Testing

 

Deze sectie bevat tijdschriftartikelen naast boeken, om de hoogst mogelijke normen van schriftelijke hulp voor QA testers te bieden:

 

– “Grey-Box Technique of Software Integration Testing Based on Message”- TanLi M. et al.

– “Een vergelijkende studie van white box, black box en grey box testtechnieken”- Ehmer, M., Khan, F.

– “Grey-box FSM-gebaseerde teststrategieën”- Petrenko, A.

– “Software Engineering”- Saleh, K.A.

– “Internationale conferentie over computertoepassingen 2012”- Kokula Krishna Hari K.

Download post as PDF