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/

This is why I am a software tester.

Question: Why am I a software tester?
Answer: Because I want my customer not to be embarrassed by his software when it is placed in production.

I was asked to enter a contest. I had to fill in a register form, activate my account via an email link and then fill in the necessary information, pay and then go on with my life happily ever after.
This evening I ended with a WTF feeling and sending a mail: (names changed and somewhat rewritten to put it into context for you to read)

----------------------------------------------------------------------
Dear John,

I had some problems with the website.

• The project that I wanted to enter as an example did not really fit into any of your categories, so I just entered a most likely category, although I do not feel this is right.
• What are the payments methods? Couldn't find it on the site so I checked for payments methods while I was in the registration form. (I already filled in all my personal information)
• When I did that I was immediately logged out by the system and could not log in again. The system told me 'wrong password' (I am almost sure I've got the right password)
• I tried to enter your website again via the activation link in the e-mail, but got error this message:

*****************************
Oops! An Error Occurred
The server returned a "404 Not Found".
Something is broken. Please e-mail us at [email] and let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.
*****************************

• I did not give up and tried the link on the site to "reset your password"
• I received the mail with the password reset link.

When I clicked the link I cannot fill in the new password on you website, because the menu "Why enter" collapses over the edit boxes when I get near the edit box for a new password with my mouse pointer.

• So I cannot enter a new password.

See attached image for that...

• I tried copy/paste the "reset password" link into Internet Explorer, but there too I could not fill in a new password.
• Now I gave up

(Although I am certain I entered a good password to start with)

Edit Box is under the menu that appears when my mouse pointer is in that area?

Feedback: testmanagement en tooling workshop, TestNet voorjaarsbijeenkomst

Op het voorjaarsbijeenkomst van TestNet op 13 mei gaf ik een workshop over testmanagement en bevindingenbeheer met de opensource tools Mantis en Testlink. De workshop bestond uit twee delen van anderhalf uur. In het eerste deel zijn we ingegaan op "wat is testmanagement" en "waarom hebben we hiervoor tooling nodig". Mijn mening is dat deze vragen net zo belangrijk zijn als het gebruik van tools zelf.
In dit eerste deel waren drie grotere blokken van interactiviteit en input vanuit de deelnemers van de workshop. De zaken die hier uit kwamen wil ik met u delen via deze blog.

De Powerpoint presentatie en materiaal, mocht u geïnteresseerd zijn, kunt u vinden op mijn website - Link naar workshop Testlink en Mantis

Dus hierbij het 'ruwe' materiaal uit de workshop, dus zo overgenomen. Deze blog krijgt nog een vervolg over de workshop, de resultaten en mijn gedachten hierover.

• Met welke testmanagement tools bent u bekend?
• Uit welke onderdelen bestaat testmanagement
• Hoe kunnen testmanagement (en bevindingen) tooling ons helpen qua verbetering van ons vak, tijd besparen en geld besparen? 

Korte workshop van drie uur: Dit was een korte workshop van drie uur. Hierdoor zijn niet alle onderdelen volledig uitgewerkt in de workshop. Bij de langere versie van de workshop (volledige dag) wordt dieper op bepaalde zaken in gegaan, waardoor er meer begrip komt over deze onderdelen.

Met welke testmanagement tools zijn jullie bekend?

Mensen komen niet al te snel naar een testmanagement tool workshop als ze al bekend zijn met producten en tevreden zijn over deze producten. Toch was er al wel ervaring met diverse tools. Ook hadden diversen mensen al ervaring met Mantis of Testlink.

De tools die verder genoemd werden in de workshop waren:

• HP Quality center
• MS Excel
• Redmine
• Jira
• Bugzilla
• Testers suite
• Visual Studio
• TFS

Beperking van workshop van drie uur: een feature vergelijking met Testlink en Mantis is niet gedaan. Dit kan leiden tot beter begrip van de verschillen tussen Mantis, Testlink en commerciële pakketten en misschien wel tot het aanvragen van nieuwe features.

Testmanagement, wat is dat (wat zijn de onderdelen van)

Ik heb de deelnemers gevraagd om aan elkaar uit te leggen wat voor hun testmanagement betekent en daar korte tijd voor gegeven. Vervolgens zijn we op de onderdelen van testmanagement in gegaan.

• Evaluatie en debriefing mist nog wel eens (lessons learned)
• Tegenmaatregelen beheren*
• Risico analyse
• People management*
• Planning
• Strategie
• Estimation*
• Prioritering
• Overdracht*
• Communicatie en rapporteren
• Requirements
• Exit criteria bepalen
• Change management
• Reputatie*
• Testproces begeleiden*

Deze oefening gaat over het nadenken over testmanagement. Belangrijkste punt is in deze oefening dat testmanagement uit heel veel onderdelen bestaat en dat niet alles met tooling te ondersteunen is. De onderdelen met de asteriks* waren deel van de discussie of deze met tooling te ondersteunen zijn.

In een volledige workshop wordt later nog bekeken waar tools als Testlink of Mantis te gebruiken zijn als ondersteuning voor deze onderdelen.

Derde vraag: was een opdracht: Redenen om testmanagement tooling aan te schaffen: Waarom bespaart dit tijd, geld of verbetert dit mijn werk?

Dit onderdeel is het plakken van post-its bij drie onderdelen: vak, geld of tijd. Het gaat hierbij om de vraag waarom we deze tooling zouden gebruiken, waar ondersteunt het echt onze doelen? En bespaart dit dan tijd, geld of verbeteren we ons eigen werk (kwaliteit). Hier kwam veel response op (mag ook wel met 25 test professionals . Bij het aanschaffen van een tool is het goed om deze zaken op een rij te hebben en goed over de baten en de kosten na te denken. 

Helaas hadden we geen tijd om (een deel van) de geeltjes te bespreken. Nadenken en expliciet op papier neerzetten waarom je tooling wilt hebben is al een goede oefening, in de groep een discussie voeren op de genoemde zaken kan nog veel meer opleveren. 

Hierbij de lijst. Dit is niet gefilterd. Wat dubbele meldingen en overlap op de onderdelen tijd, geld en vakgebied. Hier kom ik later op terug in een opvolg blog.

Verbetering van mijn werk (kwaliteit)

• Overzicht behouden
• Onverdraaglijkheid
• Communicatie tussen testers en afdelingen verbeterd – Je weet waar je het over hebt
• Geheugen steun
• Beter overzicht van de voortgang
• Inzichtelijk voor alle geïnteresseerden (status, bevindingen, wie doet wat)
• Dubbel werk voorkomen
• Alle bevindingen bij elkaar (goed overzicht)
• Effectiever en efficiënter werken
• Minder tijd te besteden tijdens bevindingen overleg
• Geautomatiseerde rapportages (in verschillende vormen – Excel/charts…)
• Sneller bijsturen door inzicht
• Proces ondersteuning, feedback loop mogelijk maken
• Snelheid
• Tijdbesparing
• Doorlooptijd
• Inzicht en verantwoording
• Één centrale waarheid
• Inzicht in voortgang
• Verschaft inzicht
• Betere inzage risico afdekking
• Minder handmatig werk
• Testdekking (op basis van PRA) inzichtelijk
• Hebben en houden van overzicht
• Coverage
• Plannen / Aanpassen
• TPI (bijvoorbeeld bugtracking)
• Verkrijgen van testmetrics
• Traceability
• Vastleggen uitkomst PRA, hanteren als uitgangspunt
• Voorbereiding + uitvoer
• Voor iedereen inzichtelijk
• Werkverdeling
• Rapportages
• Overzicht en inzicht
• Traceability & transparantie
• Kleine kans op wanorde
• Taakverdeling
• Requirement traceability naar testscript uitvoering
• Risk based plannen en rapporteren
• Verhogen reproduceerbaarheid van bevindingen
• Eindgebruikers makkelijk betrekken bij testontwerp en uitvoering
• Complexiteit – hoe zou je zonder kunnen met huidige complexe systemen?
• Groeien als testteam

Bespaart tijd

• Workflow management
• Templates
• Rapportage en snelle feedback
• Eenduidige werkwijze
• Snel kunnen rapporteren over testvoortgang en testdekking
• Heel het testteam is op de hoogte van de bevindingen
• Ontwikkelaars kunnen sneller aan de slag met de bevindingen
• Overzicht
• Eenvoudige overdracht
• Overtypen van bevindingen en aanvullingen van leveranciers niet meer nodig
• Vastleggen van kennis
• Snel inzicht in (test) voortgang
• Workflow
• Status bevindingen in één keer juist (niet meer onnodig hertesten)
• Sneller inzage in voortgang – efficiënter werken
• Programmeurs testen mee
• Minder administratie
• Wie doet wat, voorkom dubbel werk
• Ondersteun planning
• Snelle metrics & rapportages
• Je kan georganiseerd werken
• Bevindingen eenduidig opvoeren
• Overzicht
• Bevindingen in één keer duidelijk voor leverancier: first time right opgelost (tijd en geld)
• Centrale / multi user bevindingen registratie
• Consistente rapportages
• Historisch inzicht (metrics)
• Beter slapen

Bespaart geld

• één waarheid
• Geen testmanager meer nodig
• Welke risico’s afgedekt – voorgang sneller inzage en hierdoor geen dubbel werk
• Vraag van projectmanager
• Voorkomen van dubbel werk
• Geen dubbelingen
• Opbouwen van een onderhoudsvriendelijke testset die goed herbruikbaar is (voor regressie)
• Rapportage over bevindingen open / gesloten
• Overzicht van known issues
• Overdraagbaarheid
• Tijdbesparing (dus geld)
• Efficiëntie
• Testware beheren
• Prioriteiten beheer
• Planning
• Bevindingen beheer
• Kans op fouten verminderen
• Checklist klaar voor testbasis
• Minder testers nodig
• Alle admin wordt geautomatiseerd, dus waarom test admin niet?
• Bevindingen status direct te zien (rondzingende bevindingen…)
• Geen rondzingende discussies
• Heldere taakverdeling
• Minder vergaderen / bevindingen overleg – uren beter besteden
• Bevindingen eerder oplossen en testen.

Het tweede deel van de workshop ging echt over Mantis en Testlink zelf, waarbij de keuze voor de deelnemers was: Zelf installeren, of gelijk naar de tools voor inhoudelijk overzicht?

Tot hier mijn overzicht van het 'ruwe' materiaal. Binnenkort meer.

Workshop: Discovering tools for testing we use daily

I will be doing two workshops on the Test Automation Day in June, Rotterdam

On the 13th of May I did a workshop at the TestNet Spring event in The Netherlands about test management with opensource tooling Testlink and Mantis. And I liked doing it, so now a new workshop at the Test Automation Day in Rotterdam

Name of the workshop: Discovering tools for testing we use daily
Date: 19th of June 2013, Rotterdam
The participants of this workshop will share information of the tools they use, categorize the tools and talk about their favorite tools.

1. Small presentation by moderator (background & explanation of workshop) 
2. Discussion about different kinds of tools (categorizing)
3. Papers on walls with categories (moderator with participants)
4. Participants will write down their tools per category (and own name for reference)
5. Explanation by participants of (some) tools
6. Maybe some demos if participants want to do so
7. If there are Laptops around even in groups checking out tools (but I guess this is totally dependent on the situation)

So it’s a relaxed workshop, with fun, but with high interactivity. The number of tools on the papers, the number of participants and how much they are willing to actively participate, influences the workshop, so that it fits the specific group at the moment.

I said "two workshops". The second one will be the next day, the 20th of June in the Testlab at the Test Automation Day.

This will be something like the first day, that will depend on the number of participants and your feedback.
Will I see you there?

Rob van Steenbergen

Update je kennis van testautomatisering dit jaar nog!

Automatiseren van testen, onderdeel van je leven als tester.
Vorige maand vroeg ik een collega: "Heb je ervaring met Quick Test Pro?" Het antwoord was een snelle: “Nee” en een blik alsof ik iets vies had gezegd. Aan een andere tester vroeg ik hetzelfde: “Nee, maar wel geïnteresseerd”. Van de week heb ik het weer eens gevraagd aan een collega en het antwoord was weer “nee”. Het is niet echt zeldzaam, testers zonder kennis van geautomatiseerd testen. Dit terwijl testautomatisering steeds belangrijker schijnt te worden. Zeker in de agile manier van werken wordt dit vaak als een belangrijk onderdeel van testen gezien. Hier ligt vaak de focus op het opbouwen van een regressie test set of bij het uitvoeren van unit testen.

Makkelijk is het niet, je moet weten wat voor tools er zijn. Vervolgens moet je nog in je dagelijks werk de kans krijgen om met een automatische testtool te kunnen “experimenteren”, of een cursus kunnen krijgen. Natuurlijk kan je ook in je eigen tijd bekend worden met zo’n tool, maar als je die dan vervolgens niet in de praktijk kan gaan gebruiken, dan voelt dat ook aan als verloren tijd.

Kosten van licenties kan beperkt worden door een tool te gaan gebruiken als “Selenium”.

Als je in één van de grotere bedrijven werkt met een dicht getimmerde omgeving, dus zelf niets mag installeren, dan vervalt deze optie ook. Daar zal je eerst een traject in moeten gaan om zo’n tool geïmplementeerd te krijgen. Zit je in een wat vrijere omgeving dan kom je misschien tijd te kort om hiermee aan de lag te gaan. Zeker om een programmeertaal te leren die je kan gebruiken bij zo’n tool. Want alleen met een Record en Playback functie red je het niet.

Wat voor aanpak?
En dan de aanpak. Wat ga je automatiseren, hoe onderhoud je de testscripts in de toekomst? Kijken naar een framework voor data-driven of keyword driven testen? Hoe ga je de scripts onder versiebeheer plaatsen en welke programmeertaal ga je gebruiken?

Dus er wordt wel eens gezegd dat je dan beter de programmeur kan laten werken met een test tool en de tester als de begeleider. In dit geval moet je nog steeds wat van testautomatisering weten en basiskennis hebben van programmeren om een beetje dezelfde taal te spreken.

Desondanks deze hobbels vind ik toch dat een professionele tester zeker wat moet weten met betrekking tot test automatisering over onderwerpen zoals:

• Welke verschillende soorten tools zijn beschikbaar?
• Wat zijn mogelijke aanpakken binnen test automatisering?
• Wat is geautomatiseerd unit testen?
• Wat zijn de belangrijkste problemen in test automatisering?
• Wanneer gaat automatisering fout en hoe kan je deze fouten voorkomen?
• Wanneer ga je automatiseren?

Bomen en het bos

Ik ben een tester en niet gewend om code te schrijven. Iets wat ik in een dag programmeer kan een professionele programmeur misschien wel in een half uur doen. En er zijn zoveel tools op dit moment verkrijgbaar dat je door de bomen het bos niet meer ziet. Wist je dat er een tool was die voor jou de combinatie van “Selenium” en “Fitnesse” kan maken? Xebium heet dat. Tja.
En als je dan voor jezelf denkt te weten hoe het werkt ligt de volgende uitzoek klus alweer klaar: Model based testing, testability in software, software test circuits in productie, fuzzy testing via automated tools, cloud testing tools, specifieke performance tools, usability test tools...


Hoe houdt je dat bij naast je normale werkzaamheden als tester (en mogelijk andere interesses:-)). Ik vind dit ook lastig, en dan heb ik nog redelijke ervaring en kennis van test automatisering en het gebruik van tools, want die ben ik in mijn carrière wel tegengekomen en heb ik de kans gehad om deze tools te gebruiken. Zoals Rational Robot, Selenium, Quick Test Pro en ook kleinere tools die ik dan gelukkig ook zelf heb mogen installeren.

Goed nieuws: twee testcongressen om je up-to-date te brengen dit jaar!
Dit jaar hebben wij testers in Nederland geluk, want omdat er veel aandacht voor is zijn er dit jaar twee testcongressen met workshops en presentaties over test automatisering. Ik raad iedere tester om hier naar toe te gaan:

• Het voorjaars evenement van TestNet heeft het thema: Testautomatisering & Tooling
• In juni is er de Test Automation Day 2013

Zie de banner voor een kortingscode (TAD13-TE100), voor korting, aangeboden door testevents.com

TestNet voorjaars evenement: Test Automatisering & tooling: silver bullets of testing?

Op beide evenementen geef ik zelf ook een workshop. Op TestNet geef ik een workshop over de testtools “Mantis” en “Testlink”. Geen automatische testuitvoer, maar bevindingenbeheer en testmanagement met freeware tooling. En op de Test Automation Day pré conference workshop dag geef ik een workshop over dagelijks gebruik van tools in testen.

Dus kom naar de evenementen en update je kennis!