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 – LearningQuality is not dead
Half a year ago James Bach began with a blog series about Quality is dead. I tried to get a handle on it some time ago, but there is still something striking about quality and the fact that I don’t support James’ Hypothesis.
Continue reading Quality is not deadCollective 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!
Key practices for Software Test Managers
Lately I was asked by my supervisor about a list of key practices for a software testing responsible person in our projects. I decided to expose this list for discussion. Please also keep in mind that I know that this list is very context-dependent for the company I work in.
Continue reading Key practices for Software Test Managers“The biggest defect is tolerating defects.”
The headline is a quotation of Mary Poppendieck from her keynote at the Agile Testing Days conference in 2009 in Berlin. Today while reading through Jerry Weinberg’s Quality Software Management Vol. 1 I understood why.
Continue reading “The biggest defect is tolerating defects.”Size/Complexity dynamic and Agile adoption failures
With the help of Jerry Weinbergs description of the size/complexity dynamic in Quality Software Management Vol. 1 – Systems Thinking, I think I found an abstraction to Cockburns reasoning on the failure of Agile adoption.
Continue reading Size/Complexity dynamic and Agile adoption failuresAgile Testing Days Berlin VI – Good at looking around
Agile Testing Days Website
Here is a random collection of things I noticed on the Agile Testing Days which I left out of the previous entries on it. Mostly these refer to people being good at looking around, like Alistair Cockburn pointed it out.
Agile Testing Days Berlin V – The final day
Agile Testing Days Website
On the final day of the Agile Testing Days my presentation was due. Since it was my first conference presentation ever, I was very stagefright about the course. Though, here is my write-up on the other presentations I visited.
Agile Testing Days Berlin IV – Testify and the Oktoberfest
Agile Testing Days Website
Tuesday after the lunch at the Agile Testing Days there were two Keynotes and in the evening an Oktoberfest celebration. Following is my write-up of the notes I took in that period.
From the Definition of Done to “Are we done, yet?”
In the dialog about my recent blog entry about the Definition of Done, I was able to refine my mental model about “Done”. Here is a write-up of it.
Continue reading From the Definition of Done to “Are we done, yet?”