Let’s imagine it’s the year 2025 and we peek inside an average IT company to take a look at the software development teams working there: what are the chances that there will still be a person who is a tester in each of these teams? Some of you will say: “of course they’ll be gone, everybody will be a developer by then”, while some will hope that the role of the tester will still exist. What would that role look like, then?

If we go back to the current day and age, we can already see a trend that’s been going on in a lot of companies that will give us a peak in a not so pleasant future.Read more →

Today, I managed to find a diary hidden on one of the mbots we have at the office. I couldn’t see it in the user interface, but when I was doing some maintenance on the robot a simple ‘ls -la’ command in the terminal showed me this hidden content. It was so cute that I wouldn’t want to keep it from you! The robot is writing about a workshop my colleagues and I facilitated for ING. Stay tuned for a report about this day written by an actual human: my colleague Erik Zeedijk.

Kind regards,

The test professorRead more →

I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect.

Let me state the ‘bad news’ up front: you cannot fully avoid the confirmation bias. That’s actually a good thing, because if you could you wouldn’t be human. We jump to conclusions (with System 1) when our assumptions are likely to be correct[1] and a mistake is acceptable. For example, when you meet a new person you immediately judge him or her based on stereotypes, what type of clothes the other person wears, his/her posture, etcetera. This happens so quickly that you cannot stop it.

However, jumping to conclusions can be a bad thing when the situation is unfamiliar, the stakes are high and when there is no time to collect more information[2] . This screams ‘testing!!’ to me. We are often dealing with unfamiliar situations, the stakes are high and we usually face a deadline. How do we deal with this? Let’s explore what the confirmation bias has to do with testing.

Read more →

In the past three blog posts we have explored some aspects of being an Ultimate Tester: How we can add value, how our curiosity helps us to test the crazy stuff and how we can build quality in. We learn a lot about these things during work time (and hopefully during personal time as well), but as the Ultimate Tester we want to take this as a step further. What do we have beyond learning? Sharing knowledge!

In this post I urge you all to become a quality ambassador; to share more about the things you’ve learned. Help the testing community further by giving back what you know. Don’t say “but others know so much more than I do, what can I possibly add to it?”. You know more than you think and you can share knowledge in many ways. I will give you some options, ranging from very easy to needing a lot of effort. Read more →

One of the most important aspects of agile working is the fast pace. In an ideal world, you can deliver to production constantly. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. We no longer want to give feedback about the product with a manual regression testset that takes days or even weeks. That’s simply too much time to waste. Let’s stop that nonsense, we’re better than that.

Before you start automating your regression test on GUI level, hold on a second. Think about what you want to achieve first. What do you want to test on which layer of your application? There are a couple of helpful concepts to help guide you: the testing pyramid, testing scales (to help you map out components of your application and think about how how heavily you want to test those)  and the agile testing quadrants (to see what types of testing you have used and what you are still lacking). Always consider your context and where the risk is, do not write tests without asking yourself what value they provide.Read more →

In 2014 Bill Sempf posted this Tweet:

QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

— Bill Sempf (@sempf) September 23, 2014

His message caused a chain reaction of awesome responses from people thinking of all the edge cases in this scenario. Among the most hilarious responses were:

@sempf Orders a bier. Orders a cerveza. Orders a pivo. Orders a cerveja. Orders a pia. Orders a øl. Orders a ເບຍ. Orders a 啤酒.
— Aleksis Tulonen (@al3ksis) September 23, 2014

@amuletofyendor Waits for someone else to order, stands between them and the bartender, takes the drink (Man In The Middle Attack) @sempf

— James Hollingshead (@bladesjester) September 24, 2014

@sempf Bartender pours one beer and says “Works on my machine”

— Chris McMahon (@chris_mcmahon) September 23, 2014

 You can read the rest of the responses here.

This funny example illustrates perfectly how testers think. We think out of the box and don’t assume that some functionality will work because the developer said so and wrote some unit tests. Sure, automation in testing and scripting has its place and use (as we will discover in the next blog in this series), but it seldom proves that the application works as intended as a whole. Automated scripts are usually following a path without feeding the path new data every time. This can give a false sense of security, “we’ve covered this path”, when inputs matter more to find lingering errors. Read more →

Once upon a time, when project managers still thought that building software was a completely manageable and predictable activity, and testers were put in a seperate team to ensure independence, the result was shitty software and frustrated people. Even though the rise of the agile way of working has improved some aspects of software development, the journey will never end. We still have a lot of work to do. Creating good software starts with the people making it, the team. As an agile tester, a tester 3.0 if you will, you are a frontrunner of this paradigm change. 

No longer do you have to sit in a seperate team, crunching requirements to make test scripts that you then manually execute, pretending to be a human computer (how silly is that!). No longer do you have to fake your belief in a Master Test Plan that your test manager urges you to honour. No longer do you have to put your defects in a defect management tool, and then wait for a couple of releases for your findings to be solved.

It is time to take matters in your own hands. It is time to start creating value from the start.Read more →

Dear reader, welcome back to the Mapping Biases to Testing series. Today it is my pleasure to discuss the first bias in this series: the Anchoring Effect. Before we start mapping that to testing, I want to make sure that we have a clear understanding of what the anchoring effect is. 

“Anchoring is a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the “anchor”) when making decisions. During decision making, anchoring occurs when individuals use an initial piece of information to make subsequent judgments. Once an anchor is set, other judgments are made by adjusting away from that anchor, and there is a bias toward interpreting other information around the anchor. For example, the initial price offered for a used car sets the standard for the rest of the negotiations, so that prices lower than the initial price seem more reasonable even if they are still higher than what the car is really worth.”

I highlighted the important parts. Decision making is something we constantly have to do during testing, and it is important to realise which anchors might affect you. Also, to make this clear, I think ‘testing’ is not just the act of doing a test session, but thinking about everything that involves quality. You can apply a testing mindset to all that is needed to make software: the process, the specifications, the way the team works, etc. Read more →