Tester, maak je niet druk over acceptatiecriteria

Dit artikel is eerder gepubliceerd op het TestNetNieuws Blog

Ik werk vooral in agile omgevingen: Als een user story voldoet aan de acceptatiecriteria, dan is het ‘done’. Dit is een regel die veelvuldig voorkomt bij agile/scrum in de ‘Definition of Done’. Echter, veel teams hebben moeite met het opstellen van deze acceptatiecriteria. Ja, het opstellen van goede acceptatiecriteria is lastig. Ik vraag me af: kost het niet te veel moeite ten opzichte van de baten? Leidt het opstellen van criteria niet af van het echte doel van een tester? Namelijk: Testen.

Verschillende methoden
Er worden manieren en methoden gezocht om het opstellen van de acceptatiecriteria te verbeteren. Een paar veel voorkomende voorbeelden:

Er wordt bijvoorbeeld een formule gebruikt, lijkend op het opstellen van een user story: Given… when…. Then….. Dit zijn pré conditie, situatiebeschrijving en gevolg. Dit is vaak de start voor de ontwikkelmethode ‘Behavior-driven development’ (Ref 1).

Ook is er de aanpak om in een groep van mensen door praktijksituaties te lopen en uiteindelijk verschillende situaties uit te werken in tabelvorm. Deze is dan het uitgangspunt om software te bouwen en automatische scripts te genereren om te testen. Men noemt dat ‘Specification by example’ (ref 2)

Er is de aanpak om met de Product Owner te gaan zitten en te bespreken wat hij goed genoeg vindt. Bijvoorbeeld met een checklist van kwaliteitseigenschappen die leidend kunnen zijn voor het gesprek. (ref 3)

Geautomatiseerd checken
De eerste twee genoemde voorbeelden zijn vooral input voor geautomatiseerde uitvoering van testen. Over het algemeen wordt het geautomatiseerd testen beschouwd als ‘checken’. (ref 4)

Testability en acceptatiecriteria
Als je wat rond zoekt op internet, vind je veel definities van user stories en vaak de uitleg dat een belangrijk deel van de user stories de acceptatiecriteria zijn. Want als je niet weet hoe men het stukje software gaat accepteren, hoe kan je het dan testen? Vaak valt het onder de T(testable) van de mnemomic INVEST. (ref 5)

Acceptatiecriteria van tevoren uitwerken
Over acceptatiecriteria en de uitwerking hiervan wordt best wel anders over gedacht. Bijvoorbeeld: moeten de acceptatiecriteria van tevoren worden vastgesteld, voordat een user story af is? Of mogen ze in de basis klaar zijn en dan verder uitgewerkt worden? (ref 6 & 7)

Focus op acceptatiecriteria in agile zonder en met testersIk zie de voordelen van, en de toepassing van acceptatiecriteria in een ontwikkeltraject om een user story helder te krijgen. Waar het vaak op uitdraait is dat het controleren van acceptatiecriteria dan ook het enige testfocus is in veel projecten. Het testen of de software werkt zoals is opgesteld. Dit komt vaak voor als de leden van een team nog nooit met een tester hebben gesproken en naar hun idee de testen uitwerken naar unit tests. Overigens komt nog vaker voor dat er helemaal geen acceptatiecriteria worden gebruikt, maar gewerkt wordt vanuit de logische gedachte van de developer om deze testen uitgewerkt.

Het lijkt erop dat de meest geaccepteerde manier van testen in de agile wereld ‘checken’ is. Dit omdat agile teams vooral een technisch oorsprong hebben en de focus ligt bij hen op het ontwikkelen en schrijven van code. Ontwikkelaars leren op school en van elkaar dat het checken van software gelijk staat aan testen.

Bij teams waar wel een tester wordt betrokken zie je dat er meer focus komt op de acceptatiecriteria, omdat dit voor veel testers het uitgangspunt is voor hun werk. Als er te weinig focus is op goede specificaties in een team, is vaak de tester die dit naar voren brengt en probeert dit binnen een team onder de aandacht te brengen.

De problemen met acceptatiecriteriaDe focus zou niet op acceptatiecriteria moeten liggen met als belangrijkste redenen:

• Acceptatiecriteria promoten het werken in ‘waterval modus’
• Acceptatiecriteria  verstevigen de onbewuste vooringenomenheid van bevestiging

Waterval promotendJe kan zeggen, doordat je probeert acceptatiecriteria van tevoren vast te stellen, dat je eigenlijk bezig bent met een soort van waterval. Wat is goed genoeg om de user story af te krijgen? Bijna altijd geldt voor een periode van een sprint hetzelfde als bij grote waterval projecten: voortschrijdend inzicht komt met de tijd en te gedetailleerde criteria worden aangepast in de loop van de tijd. Het aanpassen van criteria door uit ervaring te leren is goed, maar te uitgewerkte criteria was zonde van de tijd. Natuurlijk worden criteria aangepast in veel teams, maar het komt ook voor dat iets niet gedaan wordt tegen beter weten in: ‘Omdat het niet in de acceptatiecriteria staat’.

Onbewuste vooringenomenheid van bevestiging (confirmation bias)
De woorden zeggen het al: we kunnen deze software accepteren als het voldoet aan deze criteria. Onze uitwerking van de software en het testen van de software zal bij het gebruik van acceptatiecriteria vooral gericht zijn op het valideren van de juiste werking. Het is zo dat onze (ja ook van jou, maar ook van je teamleden) hersenen de acceptatiecriteria zien als een bevestiging van wat gedaan moet worden. Focus op goed werkende software. En hier is iets mis mee. Een onbewust proces in onze hersenen zorgt ervoor (in min of meerdere mate) dat we niet meer bezig zijn om te bedenken welke situaties er van toepassing kunnen zijn om de software totaal in de soep te laten lopen. Dit noemen we de ‘confirmation bias’ (ref 8).

‘Old school’ risico’sWaarom beginnen we niet bij de risico’s? Dan praat je niet over hoe het wel zou moeten werken, maar dan ga je nadenken in welke situaties de software fout zou kunnen gaan.

Geen risico’s? Niet testen!

In een discussie hierover met een collega kwamen de woorden ‘old school’ naar boven. En ja, het is al een tijdje in de test wereld zo dat veel testen een basis vinden in risico’s. Ook in traditionele proces-gebaseerde methoden zoals TMap of ISTQB begint men met de risico’s als basis voor de verdere uitwerking van een teststrategie. Maar ook bij de testschool ‘Context Driven Testing’ (ref 9)wordt er vanuit risico’s gedacht. Zowel product-, proces- als projectrisico’s.

Praten vanuit risico’s over testen helpt ook de rest van je team nadenken over de foutpaden en het bepalen van testdiepgang en prioriteit van wat er bekeken moet worden.

Tester, maak je niet druk over acceptatiecriteriaEr is iets wat je als tester zou moeten realiseren: je hebt geen acceptatiecriteria nodig om te testen (ref 10). In plaats van mee te gaan met de agile trend om in user stories de acceptatiecriteria te beschrijven, zouden we vanuit testperspectief altijd moeten praten over risico’s. Teams vergeten wat voor risico’s er zijn en nemen deze niet mee in het testen van de software. Verder leidt het gebruik van acceptatiecriteria vaak tot het van tevoren maken van specificaties, wat een watervalachtig karakter kan krijgen. Hierbij worden voortschrijdend inzicht en de ideeën die hieruit ontstaan worden genegeerd, of in het lichtste geval gelimiteerd tot ‘iets om later uit te werken’.

Referenties

1. Behavior driven development – https://en.wikipedia.org/wiki/Behavior-driven_development
2. Specification by example – https://en.wikipedia.org/wiki/Specification_by_example
3. Lijst van kwaliteits eigenschappen – http://thetesteye.com/blog/2011/11/software-quality-characteristics-1-1/
4. Testing and checking refined – http://www.satisfice.com/blog/archives/856
5. INVEST – https://en.wikipedia.org/wiki/INVEST_(mnemonic)
6. Why Acceptance Criteria Are Needed Before User Stories Can Be Relatively Sized –https://www.scrumalliance.org/community/articles/2014/june/why-acceptance-criteria%E2%80%9D-is-needed-before-user-sto
7. User Story Acceptance Criteria Versus the Definition of Done –https://www.scrumalliance.org/community/articles/2015/february/user-story-acceptance-criteria-vs-definition-of-do
8. Confirmation bias – https://en.wikipedia.org/wiki/Confirmation_bias
9. You don’t need acceptance criteria to test – http://www.developsense.com/blog/2015/02/very-short-blog-posts-26-you-dont-need-acceptance-criteria-to-test/
10. Context Driven Testing – http://context-driven-testing.com/

Some emotions about the Agile Testing Days in Potsdam

Sitting in my hotel room, after the conference. I took some time to reflect a bit on the past few days.

Being in the European Championship on Software testing felt like doing a concentrated breakdance for three hours. 

So much stuff that has been said, what I've experienced in workshops and even more important, what was discussed in between all these gives a lot to think about for the next few months.

Crazy wild wild west party

Sometimes this conference seems like one big nerdy professional testing party.

Where should I go? It's hard to choose from all those tracks... Feels like a rush and sometimes had the feeling I had to run from and to rooms. It sometimes was even impossible to escape from a room...

I feel empowered by lot of the talks and workshops and know I'm again a better tester. My colleagues will notice that when I get back home

Although I will fly by plane, after this conference it will feel like this.

THANK YOU organizer's, I really had a great time. THANKS fellow team members for the championship. THANK YOU all speakers and all volunteers. THANK YOU all people I met!

Bye, safe travel and see you next year! If you haven't been to the Agile Testing Days, go next time, it is time well spent.

Een testcongres proeverij...

Je hebt avonden die georganiseerd worden, waar je wijn kan proeven of kaas. Voor de liefhebbers. Maar we hebben in Nederland deze maand (10 maart 2015) ook een testcongres proeverij gehad. "Tasting Let's test Benelux".

Dit is een proeverij waar je alle smaken van het grote Let's test testevenement in Zweden kon proberen. Zoals gezegd wordt bij het congres van 10 maart: Met allemaal testnerds 24 uur over testen praten in een hotel wat afgelegen ligt van de bewoonde wereld.

Context-driven testing
Dit congres is georganiseerd door mensen uit de context-driven testwereld. De eerste smaak die ons aangeboden werd tijdens het congres van 10 maart was dan ook één van de bekendste, of dan misschien wel dé bekendste tester van deze testschool: James Bach.

Hij kwam op als een rock held, net als alle andere sprekers overigens, met muziek en de nodige rook uit de rookmachine. Het congres werd ook gehouden in een rock podium (http://www.mezz.nl/)

Voor wie James Bach en zijn mening over testen kent, hij heeft nogal een sterke mening over wat testen is en wat het ook expliciet niet is. Zijn lezing ging in op 'checken', wat nogal opvallend is voor James, omdat hij een verschil maakt tussen checken en testen en het feit dat checken geen testen is. Hij ging er in zijn presentatie wat genuanceerder op in.

Meer over de inhoud van de diverse presentaties kan je vinden op deze live blog van Nathalie Rooseboom de Vries van Delft.

Diverse smaken
Omdat de blog van Nathalie een mooie samenvatting heeft van de dag hoef ik hier verder niet op in te gaan. Een opsomming van de diverse smaken tijdens het congres is voldoende:

• Een internationaal gezelschap: Ik heb onder andere gesproken met testers uit Engeland, Duitsland, België en Kroatië. 
• Geen lezing, maar een grote testsessie: James Lyndsay nodigde iedereen in het publiek met een laptop uit voor een gezamenlijke test.
• Zeer diverse onderwerpen: enerzijds hoe iemand Context Driven Testing in zijn eigen organisatie heeft geïntroduceerd, maar ook over hoe je een nieuwe tester zo snel mogelijk in kan werken en een track over testautomatisering. 
• Discussie: Pascal Dufour kwam met een discussie 'track' waar de zaal op zijn aanpak kon reageren.
• Een testlab waar je zelf software kon testen, uitdagende spelletjes kon doen en met robots kon spelen.
• Hotdogs, friet en bier, het echte rock eten.

  

Vragen en antwoorden met kaarten (open season)

Nog iets afwijkends is het feit als het tijd wordt voor de vragen en antwoorden na een presentatie. Er wordt minstens een kwartier gebruikt bij dit congres. En het gaat op een speciale manier. Elke deelnemer krijgt een rode, gele en groene kaart. als je vragen hebt na een presentatie, houdt je je groene kaart omhoog (daar staat een nummer op geschreven). Zo worden alle vragen verzameld door een facilitator. Mocht je tijdens de beantwoording van de vraag van iemand anders nog een gerelateerde opmerking of vraag hebben, dan kan je je gele kaart omhoog houden. De rode kaart betekent onmiddellijke onderbreking van de discussie. De rode kaart werd niet gebruikt 10 maart. 

Het is een prettige manier van vragen stellen, niet iedereen gaat door elkaar roepen en iedereen komt aan bod. Doordat je met de gele kaart op bepaalde onderwerpen in kan gaan kan er een aardige verdieping ontstaan in de discussie. Op Let's test zelf kan het zijn dat de 'open season', zoals het genoemd wordt, langer kan duren dan de presentatie zelf.

Interactiviteit en leren

Zoals je uit dit verhaal begrijpt is het een zeer interactieve manier om een test bijeenkomst te beleven. Hierdoor zullen de meeste mensen meer onthouden van de onderwerpen en meer leren dan op een 'normale' bijeenkomst, waar je vaak toch gaat zitten luisteren naar een spreker en daarna de vragen aanhoort en weer naar huis gaat. En dat kan je dan ook drie dagen doen in Zweden.

Links:

• Blog Nathalie Rooseboom de Vries van Delft
• Website Let's Test
• Een blog over het gebruik van de drie kleuren kaarten in de 'open season'

James Bach komt naar Nederland voor training... Hallo? Iemand?

Vorig jaar rond oktober kreeg ik te horen dat James Bach naar Nederland komt in 2015.

Er was wel een maar... James Bach zou sowieso komen voor een 3 daagse training (de Rapid Software Testing training), maar daarna zou er nog ruimte zijn voor een 2-daagse training over Exploratory testing. Dit zou doorgaan bij voldoende belangstelling. Ik heb zelf al RST gevolgd en was geïnteresseerd om deze training ook te gaan volgen (er valt zoveel te leren). Zodoende vroeg ik collega's of zij geïnteresseerd waren. Een paar gaven aan dat zij de training wilde volgen.

Een paar maanden later was er nog geen enkele aanmelding.

Mijn eerste reactie was: Whaaat?
Hoe kan het zijn dat als de bekendste tester van de wereld naar Nederland komt er geen interesse is? En dit voor een onderwerp wat nu toch echt wel belangrijk voor het testen zou moeten zijn? Ik kan wel wat redenen verzinnen waarom testend Nederland niet getraind wil worden. Laten we dat eens op een rijtje zetten.

• De twee dagen training is te duur (1400 Euro)
• Exploratory testing wordt onderschat
• Het is voorjaarsvakantie of iets dergelijks
• Er is nog steeds een voorkeur voor TMap, ISTQB
• De naam van de training is verkeerd (Session Based Test Management)
• Past niet in mijn huidige werk omstandigheden

Te duur?
Kijk eens rond op internet naar ICT en test trainingen en vergelijk de prijzen.

Onderschatten van ET
Laatst had ik een sollicitant die op zijn CV had staan dat hij een Exploratory Tester was. Toen ik vroeg wat dat dan betekende voor hem kreeg ik het antwoord dat hij dan op basis van ervaring... Euh ging testen.
Er is een groot verschil tussen euh.. op ervaring testen (error guessing) en ET. Error guessing gaat tot het niveau dat je zonder kennis en ervaring in principe kan proberen bugs te vinden. Om exploratory testing te bedrijven is het echter wel nodig dat je je verdiept in de ideeën, uitwerkingen, technieken en skills die nodig zijn om exploratory testing goed, efficient en effectief te doen. Het lijkt waarschijnlijk simpel als je er niets van weet. Het omgekeerde is waar: hoe meer je er van weet, hoe meer er valt te leren in dat gebied. Ik weet hoe ik een auto moet besturen, simpel toch? Herinner je je eerste rijles nog in het echte verkeer? Een stuur, gaspedaal en rem brengen je nog niet veilig en snel door een drukke stad heen.

Voorjaarsvakanties?
http://www.schoolvakanties-nederland.nl/schoolvakanties-2015.html

Voorkeur voor TMap
Een groot onderwerp, natuurlijk kan het zijn dat het de bedoeling is dat je gecertifieerd bent voor TMap of ISTQB of iets dergelijks. Dit zijn trainingen die je ook nog de rest van het jaar kan volgen. Een training over exploratory door Mr. James Bach komt niet al te vaak voor.

Misschien is de naam verkeerd?
Wat is Session Based Test Management? Wellicht is de naam van de training te onduidelijk en daarmee onbekend en onbemind?

Dus hierbij de oproep om iets verder te kijken en de brochure te lezen, of op internet rond te kijken.
Brochure: http://improveqs.nl/files/Brochure2015/Brochure_SBTM_NL_2015.pdf

Een paar quotes uit de brochure van de training:

• It can be thought of as structured exploratory testing
• Session-Based Test Management is a way to organize exploratory testing
• SBTM is a systematic approach to documenting and estimating testing. 

Je leert hoe je exploratory testing moet doen, hoe je het kan managen, hoe je omgaat met aantekeningen, hoe je dit in een team samen kan uitvoeren, hoe je metrieken kan opbouwen, zaken over tools die je kan gebruiken en meer.

Past niet bij mijn werk
Zit je bij de Belastingdienst in een waterval traject? Of doe je agile testing in een scrum team? Of is er geen enkele methodiek, maar doet men gewoon zijn best?
Het klinkt misschien wat cliché, maar wat je hier gaat leren is overal bruikbaar. Veel testmethoden en aanpakken gaan er van uit dat er gedetailleerde en up-to-date ontwerpen zijn waar je testgevallen op maakt. Ook geven deze methoden aan dat als de ontwerpen niet duidelijk zijn, of als je nog tijd over hebt, dat je exploratory testing kan uitvoeren als aanvulling.

Ik heb zelf een flink aantal jaar ervaring met exploratory testing bij meerdere bedrijven, meerdere projecten, met diverse aanpakken. Als er goede documentatie is dan kan je nog steeds exploratory testing uitvoeren. Agile, waterval of anders. Met goede resultaten. Je bent veel flexibeler en kan goed op onverwachte en veranderende situaties inspelen. Mits je natuurlijk weet wat je doet. En dat kan je leren.

Conclusie
Ik wilde deze blog niet te lang maken, het is een groot onderwerp en niet alles valt uit te leggen in een korte blog. Voor mij betekent exploratory testing de basis voor een goede testaanpak.
Ik denk dat ET door testers en managers nog steeds zwaar onderschat wordt, omdat men er te weinig van weet en het vaak het idee is dat het niet meer is dan error guessing. De kans om het te leren van de beste is er niet zo vaak, dus dit is een kans die een professionele tester moet nemen. Dit is een kans voor een testmanager om het testen binnen zijn team een stuk te verbeteren. Een manier van denken over testen wat nog vaak ontbreekt bij de reguliere opleidingen.

Vroeger maakte ik wel eens de grap: 'De tester is de roepende in de woestijn in een IT ontwikkelomgeving'. Misschien is de nieuwe kreet wel: 'De exploratory tester is de roepende in de woestijn van de testwereld'. Laat mij ongelijk zijn hierover.

Disclaimer: Ik ben geen Improve medewerker, ik vertegenwoordig niet expliciet de mening van Improve of James Bach. Ik schrijf dit niet om de training te verkopen en doe niet aan 'sales' voor Improve of andere bedrijven die dit soort trainingen geven. Deze blog is puur geschreven als reactie op de NUL aanmeldingen die er waren voor deze specifieke training. Nou.. Ja. Nul? Eén aanmelding dan, die van mij.

Neem gerust contact op als je vragen hebt.

Rob van Steenbergen - rob@chickenwings.nl

Column: Het nieuwe testen (vieze woorden)

De wereld is volop in beweging, dus ook de wereld van het testen. Er is een tijd geweest waarin het, voor mij althans, leek alsof de wereld van het testen stil stond. Een testproces bestond jarenlang voornamelijk uit het gebruik van een mooie verzameling van testtechnieken en de juiste documentsjablonen. Dit maakte het voor mij en de klant een logisch en compleet verhaal. Aan de hand van deze onderdelen kun je...

Deze column is gepubliceerd op Testnieuws.nl - Lees hier verder

Call For Papers Test automation day

Volgend jaar in juni is weer één van de beste congressen over testautomatisering (aanrader dus!)
Als je ervaring hebt met testautomatisering die je graag wilt delen, dan heb je nog een paar weken om een voorstel voor een presentatie te leveren.

Ga snel naar de website en meld je aan!

http://www.testautomationday.com/call-papers-test-automation-day/

Effectief communiceren op kantoor (via chat programma)

In mijn column 'Een tester hoort niet thuis te werken' op Testnieuws.nl schreef ik 'Communicatie via dit soort technische op lossingen is niet altijd ideaal.' Inclusief video van een grappige situatie. Ik kwam afgelopen week een poging tegen om via Skype in een groep-chat sessie informatie te delen. Wat best leuk is om te lezen:

-----------------------------------------------------------------------------------------------------
Frederick [14:54]:
Even een snelle status update Frisco
Frederick [14:55]:
Vandaag spoed overleg gevoerd met applicatie beheer over:
verstoorde sessies, issues met transport
Frederick [14:59]:
Evaren jullie op dit moment ook nog problemen?

Miranda [15:00]:
Ik ben net vandaag even met heel andere dingen bezig dan Frisco. Ik kan het nog even navragen bij de heren op de 8e.

Frederick [15:01]:
als je namen hebt, dan voeg ik ze toe aan deze sessie

Miranda [15:02]:
Martine Brandts en Vera Tiggelaar
Sandra Hofvijver is misschien ook aan het werk in Frisco

Frederick [15:03]:
brandts

...

Frederick [15:07]:
Omdat er veel mensen offline zijn, zal ik mijn actie van nu staken. Ik stel mijn vragen in de mail. Weet i.i.g. dat  er naarstig gezocht wordt naar oplossingen. Woensdag a.s. plan ik uit voorzorg een meeting waarin ik de laatste status wil delen.
hebben jullie nog meer namen van mensen die daar graag geinformeerd worden.

Sandra [15:08]:
Waar gaat dit over Frederick? Over de performance van CrediBab?
Frisco bedoel ik

Miranda [15:08]:
Sandra, gaat over Frisco

Sandra [15:08]:
Ok, dan graag ook Desiree, Randy en Selma hierin meenemen.

Miranda [15:09]:
ik was hetzelfde aan het typen ;-)

Frederick [15:09]:
Performance Frisco!

...

Frederick [15:11]:
Dank voor de namen. Ik stuur het hele gespreksverslagje even in de mail mee. Anders is er voor de laatst aangehaakten geen touw aan vast te knopen.
Ik eindig deze sessie. Dank voor jullie inbreng.

-----------------------------------------------------------------------------------------------------
Meer informatie over Chickenwings Test Consultancy op www.chickenwings.nl

Kom naar de workshop 'Getting a grip on Exploratory testing' van James Lyndsay

Workshop 'Getting a grip on Exploratory testing'  van James Lyndsay

In 2013 is het mij gelukt om James Lyndsay in Nederland te krijgen voor zijn zeer gerespecteerde workshop 'Getting a grip on Exploratory Testing' 
We hebben dit besproken en als er weer genoeg mensen geïnteresseerd zijn dan kunnen we dit jaar dit weer herhalen. Zijn workshops duren 2 dagen (volgens sommige te kort) en je oefent in de workshop actief met software om vaardigheden op te doen binnen gestructureerd Exploratory testing.

Ben je geïnteresseerd in een workshop (ik verwacht dat we het rond april/mei kunnen plannen), laat het dan weten. Als ik genoeg geïnteresseerden heb, dan kunnen we iets gaan plannen. mensen die zich (vrijblijvend) bij mij melden, krijgen extra korting.

Dus mail me en laat het weten, als er genoeg mensen meedoen dan regel ik het verder!

Meer informatie?

• Website James Lyndsay
• Blog van Pascal Dufour

Meer informatie over Chickenwings Test Consultancy op www.chickenwings.nl

Testing quotes websites

On Twitter I saw the next tweet:

Tim Western @Veretax
I wonder if anyone has collected some of the most famous (or infamous) quotes relating to software testing.

A while ago I searched the internet for testing Quotes to make a list of my own to use for tweeting or to put on my website, or whatever... But I never did do anything with it. But the tweet reminded me of this effort. I tweeted in reply some quotes from the list I made:

“Quality is free, but only to those who are willing to pay heavily for it.” – T. DeMarco and T. Lister

“Quality is never an accident; it is always the result of intelligent effort.” – John Ruskin

"A good model guides your thinking, a bad one warps it." - Brian Marick

"Quality is free, but only to those who are willing to pay heavily for it." - Lister, DeMarco:

"Testing a product is a learning process." - Brian Marick

“Actual tests are part of planning too. At least, they can be, if done consciously.” - Shmuel Gershon

"If you're gonna manage testers or any highly cognitive work, then you need to participate in the work.” - James Bach

“Exploratory Testing is not so much a thing that you do; it's far more a way that you think.“ - Michael Bolton

“Pay attention to zeros. If there is a zero, someone will divide by it.” - Cem Kaner

“If you don’t care about quality, you can meet any other requirement” - Gerald M. Weinberg

These are the short quotes that fit into a tweet. The list I made had much longer quotes. I got these quotes from Twitter but most of them from some websites. So here are the websites I checked, enjoy them!

• http://testing.gershon.info/quote-collection/
• http://gsehl.editme.com/TestingQuotes
• http://blog.utest.com/16-great-quotes-for-software-testers/2011/01/
• http://softwaretestingfundamentals.com/software-testing-quotes/
• http://hexawise.wordpress.com/2010/01/26/25-great-quotes-for-software-testers/

And an extra tip, if you like testing quotes, have a Twitter account and you don't follow Michael Bolton yet. He has become a master in creating 'testtweetquotes'. Check @michaelbolton


Meer informatie over Chickenwings Test Consultancy op www.chickenwings.nl

Nederlands Kampioen testen worden met Exploratory Testing

Ja, dat kan iedereen wel!

Voor degene die het nog niet wist, ik ben Nederlands Kampioen testen 2013 geworden. Immune-IT had een NK uitgezet voor dit jaar en iedereen mocht mee doen. Dat liet ik niet aan mij voorbij gaan en heb getracht dit zo professioneel mogelijk aan te pakken. Op mijn manier, met een Exploratory Testing aanpak.

Nederlands Kampioen testen worden met Exploratory Testing

Ja, dat kan iedereen wel?

Ik vraag mij het af als ik zo de geluiden hoor van andere testvakbroeders in het veld. Want Exploratory testing is toch ongestructureerd, informeel, zonder test technieken, puur op gevoel, testen zonder naar documentatie te kijken en veel rammen op het toetsenbord?

Misverstanden

En dat zijn de misverstanden die ik nog veel te vaak hoor en dat moet een keer afgelopen zijn. Exploratory testing is in ieder geval het tegengestelde van wat hierboven vermeldt staat, want dat noem ik eerder monkey testing, error guessing of idiot testing. Exploratory testing is in de definitie zoiets als: "Parallel onderzoek doen, testontwerp en test uitvoer." 

En meer wil ik er niet over kwijt: Huib Schoots heeft een prima artikel geschreven in de TestNetNieuws van dit najaar en hij is er vrij duidelijk over. Dus mocht je wat meer willen weten over wat Exploratory Testing nu écht is. Lees dan zijn artikel in de TestNetNieuws. (pagina 17, let op: de rest van het blad is ook interessant)

Mijn aanpak en het NK

En nu voor degene die het interesseert, mijn aanpak die ik heb gebruikt en hoe het verliep. Een paar zaken waren van tevoren in ieder geval duidelijk:

1. Een maand voor het NK zou een Functioneel ontwerp gestuurd worden
2. Aan de hand hiervan kon je eenmalig vragen stellen
3. De puntentelling ging aan de hand van het aantal bugs die je vond, waarbij bugs die je vond aan de hand van het ontwerp minder waard zijn dan 'onverwachte' bugs.

Het functioneel ontwerp in een mindmap

Eén van de zaken die ik ondertussen heb geleerd is om er voor te zorgen dat je zo goed mogelijk probeert er achter te komen hoe de software in elkaar zit. Het enige document wat je kreeg was een functioneel ontwerp. Voor mij is dan een goede manier om wat ik weet in een mindmap te zetten, gecombineerd met losse bestanden met ideeën samen in een folder. Aan de hand van deze mindmap heb ik mijn vragen geformuleerd en verstuurd. 

Dit is nog een redelijk ingeklapte mindmap. Hij is gemaakt in de software Freemind.
Als je het originele bestand wilt, mail mij dan even.

Vergelijkbare sites

Het is altijd goed om vergelijkbare software te bekijken, dus heb ik wat achtergrond onderzoek gedaan naar vergelijkbare websites om een idee te krijgen waar ik het best kon beginnen. Uiteindelijk kwam ik er achter dat deze site redelijk uniek was. Ik vond één site met vergelijkbare software, heb mij ingeschreven bij de site en wat rondgekeken. De user interface van die site week zo af dat ik daar niet verder in gegaan ben. Omdat de functionaliteit zelf wel goed vergelijkbaar was kreeg ik het idee dat het te testen pakket misschien wel uit dezelfde basis bestond als de website die ik had gevonden. Met dit idee heb ik een kort onderzoek gedaan naar de technische achtergrond van de gevonden site en gezocht naar mogelijke problemen die eventueel konden optreden. Alhoewel ik wel wat geleerd heb, kon ik in ieder geval niet de informatie vinden die ik eigenlijk wilde vinden. Met dit onderzoek ben ik dan ook gestopt.

Checklists

De vragenlijst met de antwoorden van alle deelnemers kwam terug en gaf antwoord op vele vragen. Bij veel vragen stond ook als antwoord: 'Onbekend' of 'niet gespecificeerd'. Deze antwoorden en de bijbehorende vragen kwamen in ieder geval zeker op mijn checklist. Naast mijn mindmap en de vragenlijst had ik ook nog een paar andere checklists klaargezet:

• General test techniques uit de Rapid Software Testing training
• thetesteye_softwarekwaliteitkenmerken1 (Nederlandse vertaling) om in dit geval aspecten van usability te controleren
• testheuristicscheatsheetv1 van Elisabeth Hendrickson om diverse invoer zaken e.d. te controleren

Charters

De avond voor het NK heb ik test ideeën opgeschreven, mijn charters om mee te beginnen. Een charter kan je volledig uitschrijven, waarbij je je doel noteert en welke middelen je gebruikt om dit doel te bereiken. Dit heb ik niet zover uitgewerkt, omdat ik de software nog niet gezien had. De charters waren dus verwerkt in mijn mindmap en de eerste zou zijn: "Eerste onderzoek website", waarachter ik een grote checklist had gezet om diverse punten in de software te controleren. De verdere uitwerking van de rest van de ideeën zou ik dan doen op basis van deze eerste charter. Dit is een principe van Exploratory Testing. Je werkt de opvolgende te onderzoeken onderdelen uit op basis van wat je hebt geleerd in de loop van het traject.

De eerste testdag

Om negen uur in de ochtend op zaterdag werd de site opengesteld. Ik had ondertussen twee PC's klaar staan. Eén PC voor het 'grote' testwerk, de andere voor checklists en tests ten behoeve van multi-user, browser controle en dat soort zaken. Om 9:00 begon in met mijn eerste charter, waarbij ik systematisch door de functionaliteit van de website heen liep. En ik vond bugs... Veel bugs...

Meer bugs dan ik had verwacht. Mijn aanname dat men een goed stuk software zou neerzetten waar je met écht speurwerk bugs zou moeten vinden was al snel gebroken en eigenlijk kon ik gelijk beginnen met het invoeren van bugs in het systeem wat daar voor was klaargezet. Dit ben ik dan ook gaan doen. Alles wat ik tegenkwam ben ik gaan loggen. Hierbij hield ik wél in de gaten dat ik nog steeds gestructureerd door de software heen ging met de checklist in mijn mind-map om er in ieder geval voor te zorgen dat ik niet teveel verdwaalde en onderdelen zou vergeten. Natuurlijk werd het in de loop de tijd steeds lastiger om nieuwe bugs te vinden, als je de duidelijke eenmaal had gevonden, maar op zich kon ik genoeg bugs vinden, waardoor het niet nodig was om de charters verder in detail uit te werken. 

Invoeren van bugs

Het invoeren van bugs was zeker net zoveel werk als het bijeen schrapen van deze bugs, maar ook daar moet je niet in de valkuil vallen dat je bugs dubbel gaat invoeren. Het gestructureerd doorlopen aan de hand van de mindmap zorgde er in ieder geval voor dat ik zaken niet dubbel bekeek en dat ik focus kon houden. Ook zorgde ik voor veel screenshots die de meldingen begeleidden, een plaatje zegt meer dan 1000 woorden...

Meer dan 80 screenshots had ik verzameld in de loop van de twee dagen. 

Overigens gewoon met MS-Paint bewerkt. 

Met die tool kan ik net zo snel werken als enig andere screenshot software.

De loop van de twee dagen

Mijn focus was in eerste instantie niet op het functioneel ontwerp, gezien daar de minste punten te verdienen waren, maar ik heb het ontwerp wel gebruikt als checklist naast de mindmap. Ook de vragenlijst heb ik gebruikt als checklist. De meeste bugs 'verschil met fo' had ik daarmee al wel te pakken, maar ik denk dat ik veel meer 'onverwachte' bugs had. Aan het einde van de dag had ik al veel gecontroleerd en nog veel punten openstaan voor de volgende dag. 

Einde eerste dag, met veel zaken op done, maar nog veel te doen.

• Gezien het hier niet om ging om als eerste een bug te vinden was dit geen probleem voor mij
• Tussendoor heb ik pauze genomen om geconcentreerd te blijven. Het was wel moeilijk om dat te doen, het voelt aan als verloren tijd, maar heeft mij uiteindelijk wel geholpen in mijn concentratie om even de deur uit te stappen.
• In de tussentijd had ik meer ideeën opgeschreven en een extra checklist gemaakt met 66 punten waar ik nog op wilde controleren. Die checklist was opgebouwd aan de hand van de eerder genoemde vragenlijst en opmerkingen die ik zelf tijdens het testen had toegevoegd.

En de tweede dag ging ik verder met bovenstaande proces, totdat het 16:00 uur werd. Nog een uur en het zou afgelopen zijn. Iemand gooide de server om door met tooling een aanval te doen hoorde ik achteraf. Hiermee was de database weggevallen, waardoor je ingevoerde zaken niet meer kon terugvinden. De user interface werkte nog wel, maar de software bewaarde geen informatie meer. Het laatste uur van deze tweede dag heb ik dus wel kunnen door testen en heb nog bevindingen gevonden op de user interface zelf.

Hoofdpijn en last van mijn arm

Beide dagen had ik aan het eind van de dag lichte hoofdpijn. Aan het einde van de eerste dag heb ik nog wel een analyse uitgevoerd en ideeën uitgewerkt voor de tweede dag. Aan het einde van de tweede dag was ik klaar voor wat ontspanning. Ik heb nog een paar dagen last gehad van mijn rechter-arm, maar met wat training en rustig aan doen is dat niet écht een probleem geworden. Donderdag 31 oktober kreeg ik te horen dat ik gewonnen had en ben met een iMac en een heuse titel naar huis gegaan met een zeer tevreden gevoel. Exploratory testing op een persoonlijke manier met een professionele aanpak levert wat op... En niet alleen in dit NK, maar ook in mijn dagelijks werk natuurlijk.

Meer informatie over Chickenwings Test Consultancy op www.chickenwings.nl

Nederlands kampioen software testen!

"Rob van Steenbergen is de eerste Nederlands kampioen softwaretesten geworden. Tijdens het TestNet najaarsevenement werden de prijzen van het door Immune-IT georganiseerd NK Software testing 2013 uitgereikt. Rob ging er met de eerste prijs vandoor, een iMac."

Lees het bericht op Testnieuws.nl







Meer informatie over Chickenwings Test Consultancy op www.chickenwings.nl

I am a finalist in the European Software testing awards.

Yes, that's right, I've been nominated for the European Software Testing Awards for the category 'The BCS Best Overall Project'.

This because I wrote to them about my side-project I've done in my spare time, the website and service to testers via testevents.com

This was my entry

Setting up a worldwide calendar for test conferences

This is an overview of a small and personal project, it’s maybe a different kind of ‘testing project’ as you would expect to see as an entry for TESTA. Not a project in which software is tested (although during creating of the website I did test all features), but still with the goal of delivering quality information about a specific subject. This is a contribution from me to the test community, which started off as a hobby and now is part of my daily work as a tester. An idea that started a few years ago, without realising I then would start seriously with a website. But also a project that has no ending and is evolution based in nature because there is no hurry, no stress, no limitations in time and very low to no budget.

And am I happy with this?

Of course it is great to be nominated and to be in such a kind of position as a one-man company. I really try to put something into my special project. But still I have some mixed feelings about it. It is great to put a logo like this on my blog and website, but otherwise... I don't like going to award ceremonies! I'd rather be at a great testing event evening or have dinner with some testers I know, talking about testing we did and do. 

Some things that made me suspicious

• It was strange to be called by the organisation more than once to ask me to enter for this award. They really tried to convince me to enter on more than one category.
• I had to pay to enter the awards
• I had a lot of calls to buy a 'table' for the awards or a place and they were really trying to sell that too: "If your name is called out and you are not there..."
• Award evenings can be fun as part of a test conference, this is really a stand-alone show, even with a well-known host from the British X-factor

So, some suspicious mind I guess? Maybe I misplaced their enthusiasm for 'trying to sell', I don't know yet. I guess such an award could help getting testing noticed more with companies and also the importance of it in the IT industry, because we still have a long way to go on that one.

Why did I enter?
Two reasons:

1. I'm very proud on my website testevents.com and what I did last year with the website. I know a lot of people use the website to their advance and I'm glad to help out.
2. Maybe it is a good and a cheap marketing / advertising opportunity. My budget is very limited, still I want more people in the testing world to at least know about the website.

Do I even want to win?

Yes of course, I only don't like a stand-alone award ceremony 'show' for which you have to suit up. And even that I could survive, because you can do a lot of networking on this evening. But the costs of not working for a few days, travelling and hotels is too much for this kind of event. -for me- 

Gratis boek: 101 tips voor testers

"Het exploratory testen - het testen als 'dummy'", las ik in de eerste tip en toen zat ik al met een 'ojee' gevoel... Want als de eerste tip van een boek waar ik ook aan meegeschreven heb Exploratory Testing beschrijft alsof het hersenloos op het toetsenbord klapperen is...

Exploratory Testing <> monkey testing
Dus beste testers lees zorgvuldig: Exploratory Testing (ET) is niet gelijk aan monkey testing, baby testing, schoen op toetsenbord testing, crazy dumb assed testing of hoe je het ook wilt noemen. Exploratory testing is het parallel onderzoek doen, uitvoeren van testen en testontwerpen maken. Als je met ET bezig bent, dan moet constant bewust zijn van wat je doet, analyse 'on the fly' uitvoeren, kritisch en scherp blijven denken, opletten op vooringenomenheid, blinde vlekken en andere valkuilen en doorlopend aantekeningen maken. Gedurende de test moet je dus volledig bij de les blijven. Een zwakte tijdens de test kan er voor zorgen dat je een bug mist. Noem het een techniek, een methode of een aanpak, maar vergelijk het niet met een kat die over het toetsenbord rent.

Een goede tip
Maar dat is wel weer genoeg daarover. Dit wil namelijk niet zeggen dat ik de tip niet goed vind, het is juist een prima tip: "Ik ga dan lukraak schermen invoeren en buttons aanklikken. Ik maak ook onlogische fouten. Het gebeurt zelfs dat de applicatie crasht, zonder een foutmelding te geven. Op zo'n moment denk ik altijd aan de gebruiker, die heel wat frustratie bespaard blijft.", aldus Kiki Rijniers.

Inderdaad, vergeet niet dit soort testen ook uit te voeren, geheel buiten elke rationele gedachte hoe software wel zou moeten werken. Geheel buiten een vooringenomen idee waar de software in mogelijke problemen zou kunnen komen, wat we met testgevallen en product risico analyses van te voren proberen te doen. Iets wat we misschien wel eens vergeten door alle 'formelere' aanpakken. Het is een manier om het onverwachte en ondenkbare ook te vinden.

Het boek
Op 10 oktober was de boekuitreiking van "101 tips voor testers". Het is een redelijk uniek boek doordat de tips geschreven zijn door tachtig verschillende auteurs. Ik heb zelf ook vier tips mogen bijdragen :-)

Het bedrijf Anderis staat achter dit boek, maar het lijkt over meer dan een reclame campagne te gaan, wat je misschien als eerste zou denken. Er zit een idee achter volgens de bedenkers: "Het boek Tips voor Testers is het eerste tastbare resultaat van TestCommunity.nu, hét nieuwe, openbare & onafhankelijke platform voor alle test experts in Nederland." Een goed idee? Ik denk het wel, Nederland kan nog wel meer hebben dan alleen Testnet. Ik ben vóór kennis delen, des te meer, des te beter. Dit boek is een goed begin van een nieuwe organisatie en een mooi symbool van dit kennis delen onder vakbroeders.

Ik bedoel maar, 80 auteurs in een boek, een mooi gebonden boek ook, en met echt goede tips.

Gratis bestellen!
OK, deze blog wordt alweer iets te lang, ik raad aan om dit boek snel te bestellen en het lekker zelf door te lezen. Bestel hem op http://testcommunity.nu/bestel-tips-voor-testers/

References for (Dutch) article about the future of test automation

References for the (Dutch) article I wrote for the TestNet News magazine online. You can find the article here: abcde

• Common Mistakes In Test Automation PDF (Mark Fewster) - http://www.automatedtestinginstitute.com/home/index.php?option=com_content&task=view&id=221&Itemid=76
• Software test automation: A real-world problem PDF (Cem Kaner) - http://www.kaner.com/pdfs/allegheny.pdf
• Diverse blogs van Michael Bolton - http://developsense.com/
• Cheap and free software test tools (Randall Rice) - http://riceconsulting.com/home/index.php/Software-Test-Automation/cheap-and-free-software-test-tools.html
• MindMap: Testing and Checking (Ministry of Testing) - http://www.ministryoftesting.com/2012/07/mindmaptesting-and-checking/
• Future of Test Automation Tools & Infrastructure (Anand Bagmar) - http://www.thoughtworks.com/articles/future-test-automation
• Test Automation - 10 (Sometimes Painful) Lessons Learned (Dominik Dary) - http://dary.de/2012/03/test-automation-10-sometimes-painful-lessons-learned/
• Simulating your way out of regression testing (Gojko Adzic) - http://gojko.net/2011/03/03/simulating-your-way-out-of-regression-testing/
• How many bugs do regression tests find (Brian Marick) - http://www.qanc.co.kr/4research_0402_download.htm?data_no=54&name=Brian%20Marick-How%20Many%20Bugs%20Do%20Regression%20Tests%20Find.pdf
• Presentatie van Emily Bach op Test automation Day (verder niet gepubliceerd)
• Boek: Bepaal je Koers! – Toekomst en trends in testen (Meerdere auteurs) - https://www.testnet.org/bibliotheek.html

A free test tool a day - Foxe XML editor

Foxe XML editor

I needed to create some test data for an application. The data in an XML file was to be imported in the application under test. I wanted an application that I could run without installing and showed me a physical overview. I found this simple XML editor and used it. And I like it.

What does it do?

It has a tree view and the XML and you can view the data and edit data in the XML. If something is wrong with the data, the tree view will display that. I use it at this moment  in combination with Excel, in which I create the data for testing a specific feature. So in fact I'm using the tools of tools also (MS Excel).

In Excel I create some test data in the first tab. The overview, group, block, chapter numbers on the top are used in the "screen" test data, just by using simple formulas as ="Chapter "&B6&", lesson "&B7.
On the second Tab in Excel I've got the XML with simple formulas as above filled in the XML that I first copied out of Foxe XML editor.

This looks like this at the moment.

I put the colors there for readability. And now I can copy & paste it into Foxe.

Very simple and effective to quickly create some test data. You don't have to be an XML expert to do this and this tool helps a bit by showing a tree view and possible problems in the XML.

How does it look?

• On the left there is a representation of the XML in a tree
• You are seeing green icons, one with red, one with a yellow dot. Apparently something is wrong with the red and yellow items.
• Just double click on a tree branch and on the right the section higlights for easy searching.

There are some tools, for example XHTML validation and you can even script with this tool, but I didn't research that yet. 

So, very good tool for the "I'm a new tester in XML", but also usable with script features for researching XML files for the more experienced. See their website www.firstobject.com for more info and a video introduction.

A free test tool a day - Perlclip

Perlclip
Even since I learned about this tool from Michael Bolton, I have it ready somewhere in a tools directory or I download it again from the James Bach website (www.satisfice.com)
Great for filling up fields with data and keep track of the number of characters you put in there for example (this is the simplest form for using it)

What does it do?
With this small tool you can create strings easily to test edit boxes or testdata files.

Counterstring 255 (I use this one the most) creates for example:
*3*5*7*9*12*15*18*21*24*27*30*33*36*39*42*45*48*51*54*57*60*63*66*69*72*75*78*81*84*87*90*93*96*99*103*107*111*115*119*123*127*131*135*139*143*147*151*155*159*163*167*171*175*179*183*187*191*195*199*203*207*211*215*219*223*227*231*235*239*243*247*251*255*

The star to the right of the number is the x character in a pattern, so you can check for length of fields, memo fields, import file data length that is really imported into a database...

That kind of stuff.

The readme file with the tools has great examples for what you can do with this great little, light fantastic tool. Another example: just download it and read the readme:

'$allchars' produces a string that includes all character codes from 1 to 255 (0 not included).

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ

A free test tool a day - Rapid Reporter

Rapid Reporter

This is a tool I use very often the last few years to help me logging my Exploratory testing sessions. I love this  tool because it is very simple and effective. And also because you don't have to install it. 

What does it do?

With this tool you enter one text lines in a small Window that is placed somewhere on your screen, you can drag it anywhere. The text you enter is placed in an Comma Separated Value file, so you can read what you tested after you've finished. It has a time clock for 90 minutes (default setting, I never changed this), so you can time box your exploratory session. And that's it. A test log is created on your disk, so you won't be bothered to switch to notepad, excel or something else you are using. 

If you never create test logs for your ET it is a great tool to start doing that, because of the easy way to do it. I use it to create checklists afterwards, us it as a reproducing report for bugs to give to developers, and for future reference. What did I do the last few days? In my current project I will use the logs as input for developers to create automated test scripts.

How does it look?

When it's started, it is a very small Window with a few buttons and one field to enter notes.

• There is a button for creating a screenshot on the left (for example, to capture the moment)
• There is also a button where you can enter specific notes for the complete test session you are doing
• There is a slider on the left where you can set transparency of the app, so it will not attract attention too much when your are concentrating on the software you are testing.
• The blue bar is a progress bar for the timer of 90 minutes and will fil the edit box. After 90 minutes you still can continue and it will not make you stop.
• With the arrow keys [up] and [down], you can select a specific log type. The picture says "Test:". With the arrow [up] key it goes to "notes", with the arrow [down] key it goes to "Check:"
• There is also "Bug" for example, this bug: option will show red in a HTML file you can create of the logfile.

How do I start?

Just go to the website where you can download the tool and read the instruction manual. It is very simple and easy to use it. http://testing.gershon.info/reporter/