How to start facilitating mobbing

Here lies some points on how I started out with mob-testing and mob-programming facilitation. I want to trigger you to try mobbing.

Quickly, what is this mobbing thing? A group of people working together using one computer. Imagine: anything that happens to the application, code is seen and understood by everyone, on the spot. With a setup in which people are divided into different roles: one has to execute (driver), one has the final word on what’s being done (navigator), while the rest are brainstorming (mob-members). Sounds interesting? Read more here: 1, 2 or watch a timelapse video.


With this post though, I assume you have at least heard about mobbing.

Take these points in no particular order. Use them at your own risk.

1. Participate in one

For me it all started by participating in mob-testing sessions (1, 2). No explanation beats a real-life, hands-on experience that puts something in your reality. You will no longer wonder if it’s possible. You will have it in front your eyes and feel it on your own skin. You will have even your unasked questions answered. Try to get into one!

2. Look up the more experienced

To experience a session live is not necessary to take action. A colleague of mine read some of the description of the setup and process (1) and organized a mob-programming session at the branch (from the things I’ve heard it was chaotic and confusing for most, but that’s besides my point – with followup sessions and reflection you will get rid of the teethers).

3. Ask the more experienced

To my best knowledge the leading figures of mobbing are Woody, Mareet and Llewellyn. After I looked some of their work up, I e-mailed Mareet and Llewellyn asking all sorts of questions. They answered in great length and were genuinely interested in my experience. I can not speak for them, but I think they will let you pick their mind, too.

4.  Get someone else to do it for you

We all have collegaues who do unknown things without a faint of a heart. You could ask them to go through some theory, watch a video and while you could participate, they could facilitate. For me public speaking and facilitation is\was a massive out-of-comfortzone experience, if it’s the same for you, this could be an idea.

5. Imagine what other people would ask – and try to answer it.

This is important for preparation, to be able to “sell it”. When you announce or just casually tell others about your idea, people will be not interested or attack it. They are really protective of their valuable work-hours (and that’s good). There is no other way around it, but be convincing enough. Be prepared with good answers and let your enthusiasm shine through. I found the timelapse video to be a good tool to help people picturing what’s going to happen.

In a few session I’ve seen some ups and downs of mobbing, but that’s for an other day (post). Try mobbing this month and tell us how it went!



You go confer now

I’m writing this to you, who never been to a testing conference, maybe followed some online, watched some videos or only heard about that they exist. I know that you either have to work for a good enough company that will send you to one or (most times with a significant amount) invest in yourself to go to one, I know, I do both.

With Testbach* Manchester ended I’m concluding my year conference-wise. I’ve been to 6 testing conferences this year, classic ‘1-talks-rest-listens’ type, hybrid ones, entirely open space events or those that were built solely on full day workshops/tutorials. Free ones and ones that cost my monthly salary.

I’m telling you, wherever you go, you will not learn as much as you expect to. To be less shallow: you will not learn as much hands-on, immediately applicable things as you expect to. Ever had the experience of skimming through a program/agenda (of a festival, semester, anything) where titles seemed to promise so much more then they could deliver? ‘All you wanted to know about mobile testing!’, ‘Exploratory testing embedded systems.’ And we are tempted to think that we will be told about it all.

Instead, let’s look up the meaning of the verb ‘confer‘ from which conference is stemmed from: ‘to discuss something important in order to make a decision‘. Good news, this is what you are going to do on a conference! If it’s an all-talk event, then you either have to do it in the breaks or ask the speaker. You will discuss something important with testers coming from a so different context that you don’t have words for. I’ve seen people bringing a local installation of the software they test, because they wanted to find someone who works with a similar one. You will go back to your team and never look at them, your application or your job as before. You will ask questions about your own company – where you might be working for years already – that you haven’t thought of before. You will see that what you know others might be oblivious to. You can teach them and you will even learn from it.

All these could be summed up shorter: enthusiasm. That’s the primary output of a conference. Plus the feeling of community and excellent contacts that you can ask later, people are happy to help.

Okay, I can contradict myself. I’ve learnt about identifying testing skills in Bucharest, the recipe for critical thinking in Copenhagen, that if you have branches you can not possibly continuously delivering in Cluj, firing up Postman in London, tried public speaking for the first time in Rijeka or seen how to intercept traffic of a website with ZAP in Manchester. So there were some immediately applicable things. But now you think I know much more about critical thinking and Postman than I really do.

I could put a big list of links here, but instead I’ll give you only two. Look at this list and choose a conference that you will go next year:
The other one is a post from the more competent than me Željko Filipin, where he lists why you should not go to a conference: I met him on a conference. Which he helps organizing.

*that, there, is a genuine typo that I didn’t correct.

Photo is from the great

Ever noticed what do you do between finding and reporting a bug?

Reporting a bug right away, just after you found it might not be the most useful thing you can do. Quite a statement, huh? And you are probably not even doing that. What.. how? I’ll tell you through an example that happened to me a bit ago at work, then show you the more theoretical thought. Watch yourself doing this.

My team refactored a part of our application, now using javascript and there was a shopping cart involved.  I was curios how it will react to the biggest numbers can be typed in when I found a bug. Multiplying really big numbers got the cart frozen, it seemed. I pressed F12 to see what’s going on behind the scenes. It wasn’t only because of big numbers. It was a digit overflow, because of a precision error in javascript (which then of I quickly learned about: Aha! Then I thought: how else this could be a problem? This lead to me adding some pretty normal-looking number which then would cause the same problem, freezing down the cart. Called the developer over and didn’t even need to say much.

Why any of this matter? Because reporting a bug that surfaced after multiplying 999999999999.99 by 99 might make a developer or product manager say “Who would do such a thing?” or “Let’s put it on the backlog and we will deal with in 2038!” and might be rightfully so. But showing them that the same bug causing the same effect can be reached by multiplying 25.89 by 3 makes the bug get fixed in no time.

I used a mnemonic to help me to go from finding a bug to reporting, coined by Cem Kaner ( RIMGEA – later modified to RIMGEN by testing folklore. This is how I RIMGEN-ed this bug:
R is for Replicate: to reproduce the bug on demand. You don’t want to use words like “sometimes” or “looks like” in your report. Before anything I got confident with the bug, that it’s not only my hallucination and the shopping cart got really frozen in case of the biggest numbers that input field for the price can take in.
I is for Isolate: to bring down the number of steps to the minimum. You want to clearly see what is causing the bug. This is where I found out that it’s not only the big numbers, but the javascript precision error. After this it was too easy to show the bug.
M is for Maximize: to show how harmful a bug can be. Probably biggest part of the story I just told you. I went for freaking people out with a frozen shopping cart and a confused and frustrated user.
G is for Generalize: to bring the thing back after maximizing, finding all the places and ways that it can be a problem. Never liked the term “corner case”. But if you use it: this is de-cornering your corner case. This time this has happened naturally as no one asked if this applies to other shopping carts in other shops. No one dared.
E is for Externalize: to make it seen, heard by telling every important person about it. Probably the one that applies to in-house testers the least, although it happened to me before that my findings got buried, either I missed identifying those important people or failed to inform them because of the way I was reporting. It would have been hard this time, though.
A or N for And use Neutral tone: being dispassionate and not forming an opinion helps avoiding blame-culture and finger-pointing. A bug report is a piece of information without any emotion or judgement. What you think or expect of a behavior is not exactly the most relevant part of the product development. It takes some time to really live by it, but very liberating after you have this insight.


I made these photos. It shows, doesn’t it? But the photos are taken about postcards, sketched and made by Altom ( Levi (

Original sighting of the RIMGEA mnemonic: (Lecture 6) and other posts on it’s usage


Event that made London look friendly: London Tester Gathering Workshop ’16

I’m still pretty new to the scene of software testing conferences, only went to my first ones this year. I was so curious already, that I paid everything for myself just to go to the first #EuroTestConf and the #CopenhagenContext. Amazingly, my next conference was through winning a competition by Tony Bruce (

By going to London I was in for a different kind of conferring. London Tester Gathering Workshop ( is organized by Tony and his friends at Skills Matter and solely built upon hands-on workshops and discussions with practical exercises . Sounds great, huh? Not only sounds.

Continue reading “Event that made London look friendly: London Tester Gathering Workshop ’16”

Testers preventing problems?


This post is a reminder for Michael Bolton and a trigger for more conversation about testers preventing problems. I do look forward for a full post by Michael as he is writing clever things in his reply to the tweet you see above on the picture and linked here.

I chipped in:

I agree that there is no manual vs automated testing dichotomy and that all testing is exploratory. These notions make me say that exploring (a.k.a.: testing) an idea that someone at the company has is worth doing and can be called testing already. A crucial question can make grandiose ideas disappear. I would say I tested the idea and now it’s gone for the better. I’m testing already when I read a written spec.

If testing is “the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.”, which it is, according to the RST vocabulary one question remains: can I look at someone’s idea as a product?

Test Automation is a buzzword!

Recently in a Skype group chat some questions came up when we talked about a Meetup which will have the title: “Agile testing”. If Agile is only a development context where a tester sits, does agile testing even exist? Is there still place for manual testing or only automated tests can remain? Do we need tester role?

Here is how I answered in a somewhat edited version:

It’s possible that Agile testing doesn’t exist. Automation popped up quickly in the questions. Only automation cannot really be a solution, because if you watch yourself carefully when you are writing your automation you will see that you are “manually” exploring the application beforehand and during it! You try things out, think about how could you call this or that service, how will your automation tell if this or that is correct or not. Testing is gaining information. You learn about the product. Only then codify some of your knowledge into algorithms so it can run quickly, many times and uninterrupted, looking for change. If something changed, it goes red and you come along to see what has happened. Red doesn’t mean a bug, green doesn’t mean there is no bug, I’m sure everyone experiences this in their daily work. What do you think?

I guess, it’s possible that everyone tests in a team, so there is no dedicated tester position (but testing is still there). Many agile practices (pairing, TDD) are emphasizing to prevent bugs, before they are introduced. The possibility of quick rollbacks and releasing often and in a staged manner are examples of quick feedback and high degree of communication and coordination, practices that Agile embraces. With these you are putting testing somewhere else. Dogfooding – when a company tries their product out by actually using it – is an example of this. There is testing, it just happens in some other form.

I owe the title to Alex from Altom, such an eye-opener. It is just a buzzword! Vendors and marketers talk like this! “100% of our regression testing is automated!” Ha! Execution of specific and scripted actions is what people usually mean by “test automation”. That is part of testing. But testing is more. Talking to others, reading or understanding explicit and unspoken requirements. Assessing risk, coming up with interesting test ideas. Mediate between colleagues. “Test automation” evaluates results the way you told it to! You evaluate with more complexity, you can add those evaluations to your next ideas. You can re-asses, re-think. You can change tool anytime, decide to focus on something for a while then go for a coffee with someone from support. Automation is very important and useful, because it can run reliably, repeatedly and tirelessly. But it’s not curious and doesn’t suspect anything. It’s a buzzword! So good to say it.

Here is a video with Alex, talking about his story changing his mindset and sharing all that in his country, Romania:
And here is the company they funded:

So what did I take away?

I will arrive back to my job with a lot of enthusiasm and self-confidence.

Hearing about others’ daily work makes you realize that the things you know are not obvious for others. And your learning will probably never end, so we should get used to it.

After Richard’s talk, because of a Jerry Weinberg quote I talked to someone how often the things we remind each other are cliches. They sound common sense, duh-kind of thoughts. We still keep repeating them, because it’s easy not apply them.

If I suspect that an area has changed in the application but all the checks are green. That should worth a look.

Adina told me that she will think about how to put tacit knowledge into a check. I will think about it as well. Here is Harry Collins talking about how you need tacit knowledge to build a copy of a gravitational wave detector to test other researchers result:

Ale told me on her workshop that to keep a project log, and draw a map of your skills are good ideas. They certainly sound like that. I remember disagreeing with her at some point, but as a good debater I only remember my argument and not hers anymore, which I cannot decode anymore from my notes. My thought was that skills are the things you are able to do. Hers was something different. We have to talk about that.

There is no way I can list all the things I took away.

Continue reading “So what did I take away?”

What is going on in Romania??

Bucharest hosted the first European Testing Conference conference, Altom ( is from Cluj, Tabare de Testare is in 4 cities with monthly testing Meetups, also organizing a testing camp, the testing map is from there, there is the Romanian testing conference, next CITCON is going to be in Cluj.

Let’s not start an alphabetical list with countries form Europe where there is nothing visible/exciting going on, but it would go like Armenia, Austria, Azerbaijan…

Here, read an other short one about the European Testing Conference
Losing my testing conference virginity
Losing my workshop, lean coffee and open space virginity
The amazingly little (visible) testing universe
Was I an outsider?
The food was very okay
So what did I take away?

The food was very okay

I liked the second day’s lunch better. Maybe just because I didn’t have to stand in line, unlike on the first day.

Here, read an other short one about the European Testing Conference
Losing my testing conference virginity
Losing my workshop, lean coffee and open space virginity
The amazingly little (visible) testing universe
Was I an outsider?
What is going on in Romania??
So what did I take away?

Was I an outsider?

Even if you meet the strangest stories and most exotic backgrounds in testing, you can still fall back feeling like an outsider. Because no CS degree, others know better, others are more experienced, others’ workplace is a proper place (where there is no testing role anyway, so what are we even actually doing here). This is of course delusional which you quickly realize after you talk to some people who you bump into in the hallway.

I still felt a bit outsider as I think I was only one who paid for the conference & co. for himself. This shouldn’t make a big difference, I thought, but I felt like I have to take away so many things for this investment that it paralyzed me here and there. Also makes you wish that others would appreciate more that they can be there.

Here, read an other short one about the European Testing Conference
Losing my testing conference virginity
Losing my workshop, lean coffee and open space virginity
The amazingly little (visible) testing universe
The food was very okay
What is going on in Romania??
So what did I take away?