Category Archives: Testing

Software Testing

Burning Issues of the Day

Michael Bolton put up a great presentation from a talk on his website. The most thoughtful quotation:

When a manager asks you to show him your test cases, ask him to show you his management cases.
When a manager asks you to show him your test scripts, ask him to show you his management scripts.
When a manager insists that every test should have an expected, predicted result, ask him if every management action should have an expected, predicted result.
When a manager insists that we lower the cost of testing by bringing in test automation, ask if we can lower the cost of management by bringing in management automation.
When a manager wants to evaluate testers based on “defect escape ratios”, ask if we can evaluate management by “bad management decision escape ratios”.

(Inspired by James Bach)

After going through this series, I was personally considering to put up some elaboration on each of the quotations on the roughly 40 slides here. Unfortunately my available time does not permit this. Maybe I will come up with a series in some weeks or months, but for the time being stick to the presentation. There is one statement on each slide, and Michael did a great job to combine them together from great thought-leaders – as I think. Read them. Now. Really.

Exploratory Testing – Learning

Over the course of the Agile Testing Days in Berlin I realized why Exploratory Testing works. Personally I found a model from my past, which explains Exploratory Testing based on face-detection systems. After some initial feedback I decided to break it in three different posts: Learning, Scanning and the Differences. I will start with the part on Learning.

Continue reading Exploratory Testing – Learning

Collective Quality Ownership

Elisabeth Hendrickson pointed out to me that she recently renamed her seventh practice of Agile testing to Collective Test Ownership. The name is the compartment of the XP practice Collective Code Ownership. Behind it is the value that everyone should be able to change everything if there is a claim to do so. There shall be no human singletons, which are the keepers of the holy grail of your product. This holds for the code that will be compiled and shipped as well as for the tests for that code. If a user story affects existing tests, the tests should be able to change – probably after discussing it with the product owner or using The Power of Three to decide about a failing acceptance-test.

However, I see another collective thing that Agile adresses very well: Collective Quality Ownership. What’s that? Collective Quality Ownership means that everyone has the responsibility to hold the line at the occurrence of a quality problem. Everybode on the team has the right and the responsibility to get to that problem, fix it, and get back to speed. XP practices like Continuous Integration and Collective Code Ownership are just some examples of it. In a waterfall environment where everyone is playing hot potatoe you will realize that there is a lack of Collective Quality thinking. If there is a problem, then someone to blame for this is identified and the hot potatoe is handed over to the next. In the end after months of passing the potatoe around, the problem is still there, and a lot of time has been wasted to pass the problem around, but not to address and fix it right here, right now.

Why do I think that this is important? Collective Quality Ownership is part of several parts in our development live. Each time a bug gets filed, ask yourself how much does this new bug contribute to fixing the problem? When testers hide in their cubicles, getting code thrown over the silo wall, throwing bugs back, then the problems are not addressed. Such a system is not optimized for fixing the problems, for solving the problems, but for identifying problems and for throwing them around. Time is spent in information hiding, time is spent for passing the next potatoe getting passed to own-self and too few time is actually spent at solving problems.

On the other hand Collective Quality Ownership calls out that everyone is responsible for delivering quality to their customer. What is quality? The famous quote from Jerry Weinberg here is

Quality means value to some person.

Quality may mean value to your customer, quality may mean value to your stakeholders within your company. If you see a problem that their very quality perception of the product may disturb, you have the right and the responsibility to fix it. Now, do it. Don’t pass the potatoe. It’s your responsibility. Don’t be blocked by the problem, don’t play the victim role here. If it’s an area which you’re not familiar with, you can always find someone to pair with you on it who is capable of it. In the end you may find out that you learned something and then be able to fix the problem yourself the next time. But you have to address the problem. Now. So, do it!