TestAutomatisering & PerformanceTesten

Wat is het Bug Filter?

Een algemeen gedeelde opvatting over het doel van testen binnen software ontwikkeling is “het tegenhouden van bugs en het afdekken van risico’s”. Over hoe dit vervolgens het best valt te organiseren, bestaan er echter vaak veel meningsverschillen.

In deze 2 minute snack sta ik graag even stil bij een inzicht dat verhelderend werkt in deze discussie, vooral wanneer het budget van belang is… Altijd dus. Mijn dank hiervoor gaat mede uit naar Katrina Clokie, via wie ik de term ‘Het Bug Filter’ als eerste heb gehoord.

De Test Automatiserings Piramide van Cohn/Crispin/Huggins kennen we ondertussen allemaal wel. Maar juist op de plek waar er beslissingen gemaakt worden op budgettair vlak, komt deze piramide nogal abstract over. Een veelgehoorde uitspraak is dan ook, “ja, maar als je de frontend test, dan test je indirect ook de backend toch”? Dit heeft dan vaak als uitkomst dat de, in mijn ogen foute, conclusie luidt: “Alleen (geautomatiseerde) testen op de frontend zou voldoende moeten zijn”.

Wij hebben het daarom graag over het Bug Filter. Deze wordt soms gevisualiseerd als een omgekeerde test piramide, maar in dit geval stellen we de Build en Deployment Pipeline als een echte pijplijn voor. Elke code check-in start links, gaat door de pijplijn en komt er rechts als het product uit. Om te controleren of de kwaliteit voldoende is kunnen we zoveel filters plaatsen als we willen. De zogenaamde bugfilters. Ze bestaan in drie soorten:

De Filters

Als eerste hebben we high-speed filters: Ze zijn snel te plaatsen, ze veroorzaken nauwelijks oponthoud wanneer het product passeert en ze zijn ook nog eens goedkoop.

Dan hebben we standaard filters: Ze houden een aantal bugs tegen die niet worden tegengehouden door de high-speed filters, maar ze zijn wat lastiger te plaatsen, ze veroorzaken wat oponthoud in de pijplijn en ze zijn behoorlijk duur.

Als laatste hebben we ultra-de-luxe filters. Deze zijn nog veel lastiger te plaatsen, ze zorgen voor veel oponthoud en zoals de naam al verraadt zijn ze ook nog eens schreeuwend duur. Waarom je deze aan zou willen schaffen? Nou, omdat ze bugs tegenhouden die niet worden afgevangen door de andere twee filters.

De Case

Stel je staat in de plaatselijke Bouw-en-Laat-Los winkel (wij hebben alles voor uw build proces) met een budget van 1000 euro. De filters komen met een respectievelijke prijs van 1, 10 en 100 euro. Wat is dan de beste inkoopstrategie?

Het Bug Filter gevisualiseerd op de Build Pipeline

Inkoop Strategieën

We kunnen 10 ultra-de-luxe filters kopen en daarmee houden we inderdaad 5 bugs tegen. Maar 3 ervan hadden we ook kunnen tegenhouden met een high-speed filter, 1 met een standaard filter en inderdaad, 1 hadden we nooit kunnen tegenhouden zonder een ultra-de-luxe filter. De vraag is: Hoeveel bugs hebben we níet tegen kunnen houden?

Een andere strategie is eerlijk verdelen: we verdelen het budget (350/350/300) over de verschillende filters voor respectievelijk 350, 35 en 3 filters. Hiermee houden we 87 tegen met het high-speed filter, 6 met het standaard filter en 1 met het ultra-de-luxe filter. Een veel betere score!

Of een voortschrijdend inzicht benadering: We kopen net zoveel high-speed filters in totdat we zien dat extra filters niet meer zoveel zin meer hebben. Vervolgens doen we dat met de standaard filters en daarna met de ultra-de-luxe filters. Dit past ook beter bij een Agile aanpak; het maken van geautomatiseerde testen doe je tijden het ontwikkelproces, niet achteraf.

Filters en Testen

De drie filters staan hier natuurlijk voor unit testen, systeem-en-integratie testen, en de functionele acceptatie testen. Maar praten over “Bug Filters” in plaats van “test soorten” laat veel duidelijker zien waarom alleen frontend automation vaak geen verstandige keus is. Een gebalanceerde benadering biedt better-bang-for-buck, is sneller te bouwen en geeft tijdens build tijd sneller resultaat. Combineer dat met een verstandige plaatsing in de pijplijn en het juiste moment van plaatsing, en je hebt die snelle feedback loop waar al die Continuous Delivery experts het altijd over hebben.

Dit bericht is geplaatst in Testautomatisering en getagd in Bug Filter CI/CD Test Automatisering

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

De ‘waar begin ik met testautomatisering’ handleiding.

11/04/2018

Wij worden regelmatig gevraagd te helpen bij het opzetten of verbeteren van testautomatisering in een Agile omgeving bij een klant. En hoeveel ervaring je ook hebt, wat je opdracht ook precies inhoudt en in welk team je ook terechtkomt, het is altijd even zoeken waar te beginnen. Onderstaand stappenplan ondersteunt hierbij. PerformanceArchitecten organiseert veel kennissessies. Zo […]

Wat is het Bug Filter?

26/03/2018

Een algemeen gedeelde opvatting over het doel van testen binnen software ontwikkeling is “het tegenhouden van bugs en het afdekken van risico’s”. Over hoe dit vervolgens het best valt te organiseren, bestaan er echter vaak veel meningsverschillen. In deze 2 minute snack sta ik graag even stil bij een inzicht dat verhelderend werkt in deze […]

Testen? Begin bij de basis! | Het belang van unittesten

19/02/2018

Inleiding Mijn vrouw en ik zijn op dit moment bezig met het bouwen van een huis. In dit geval niet als bouwvakker of aannemer, maar dan toch wel als opdrachtgever. Spannend vinden we het zeker, leuk ook. Wat heeft dit te maken met unittesten zou je denken. Nou, het volgende… Het huis wordt namelijk gebouwd […]

De Absolute Beginners Guide voor API Testen met rest-assured.io

16/01/2018

Omdat het moeilijk was om een eenvoudige tutorial te vinden voor rest-assured.io, ben ik na eerst zelf uit te vinden hoe het werkt, maar eens begonnen met een tutorial die de absolute basics uitlegt over rest-assured. In deze post laat ik zien hoe we op een zo eenvoudig mogelijke manier een API test kunnen maken met […]

APACHE MPM (op *nix servers)

07/11/2017

Benieuwd naar de impact van het wijzigen van Apache MPM Prefork naar Worker? Lees dan door! Bij één van onze klanten heb ik dit onderzocht. Omdat dit ook interessant kan zijn voor anderen, deel ik mijn resultaten en ervaringen graag. Het is misschien wat technisch allemaal, maar voor performancetesters, de doelgroep, is het vast goed […]

Performancetesten en CI/CD, gaat dat samen?

13/10/2017

De afgelopen najaarseditie van Testnet stond onder het thema Continuous Everything vooral stil bij CI/CD en natuurlijk testen. Gezien DevOps en CI/CD ook grote invloed hebben op het vakgebied performance (testen), zijn wij blij dat we vanuit PerformanceArchitecten een bijdrage mochten leveren door middel van het delen van onze visie hierop. Onze collega René Meijboom […]

Een eerste indruk van Gauge

08/09/2017

Tijdens één van onze kennismiddagen hebben we gekeken naar het testtool Gauge. Doel van de sessie was om een beeld te krijgen wat de toegevoegde waarde van Gauge is voor een tester. Benieuwd naar onze ervaringen? Lees dan snel verder! Gauge is een open source project, gesponsord door ThoughtWorks en belooft in het kort het […]

Test Automation Framework BDD

16/06/2017

De afgelopen tijd heb ik in een opdracht collega’s mogen adviseren over de positieve impact van het Test Automation Framework BDD rondom het thema Agile. In een vorige blog ‘Transformation’ is te lezen wat BDD voor mij betekent en hoe BDD voor synergie zorgt tussen verschillende disciplines binnen Agile-teams met als doel het leveren van kwalitatief hoogwaardig […]

Creëer meer eenheid in je SpecFlow steps met Step Argument Transformations

11/04/2017

Laatst kreeg ik de vraag, “Hoe maak je in je testdata onderscheid tussen een regular expression en een gewone tekst”. Oftewel: Hoe beheer je verschillende soorten steps als ze alleen verschillen in de manier waarop data vergeleken wordt. Je hebt een veld en je wilt controleren of er een bepaalde waarde in staat, maar soms […]

SSL/TLS versie en cipher in HP LoadRunner

29/03/2017

In deze blog wil ik even stilstaan bij de resultaten van een performance test die niet overeenkwamen met de verwachtingen die wij als team hadden. Een aantal transacties gingen in responstijd omhoog en het CPU gebruik nam flink toe. Omdat het ons veel tijd heeft gekost, deel ik dit graag met jullie zodat wij performance […]

Regular Expressions en Testautomatisering, twee problemen of juist een oplossing?

25/03/2017

Bij geautomatiseerde checks wil je regelmatig een verwachte waarde controleren tegen een actuele waarde. Vroeg of laat kom je dan in aanraking met wildcards: Je wilt bijvoorbeeld weten of de tekst “Er zijn 42 resultaten gevonden” voorkomt, maar het aantal, hier 42, kan variabel zijn. Van 42 wil je dan een wildcard maken. De meest […]

Automated Approval Testing with Dynamic Data Sets

21/02/2017

For some tests, you’ll need to check if files or documents are the same as they were before, or that they comply with a certain format. When something differs, you need to “reject” or “approve“ them, or even make them the new baseline if you are welcoming the changes. We call this Approval Testing. For more […]