Unit Testing versus Unit Checking

I attended a session about Replacing End-to-End-Testing at Agile20009 in Chicago some days ago. There were some lightning talks where attendees could spread their opinions and insights about testing.
One of these I have kept in mind. Here it is:
When we talk about testing, we mean some very different things that go by the same name, which leads to confusion. There is unit testing, end-to-end-testing, automated testing, manual testing, exploratory testing, click testing, etc. etc. etc. A few of them have something in common, but some of them have not.
It’s important to realize that you need completely different hard skills and mindsets depending on whether you are talking about automated unit testing or manual exploratory testing.
In most cases, for unit tests you’ll need a software developer familiar with testing – for exploratory testing a traditional Quality Assurance tester should be the person of your choice. These persons have diverse backgrounds, their focus on testing is not the same, neither are their experiences (and they may come up with different results from their tests!).
Despite this fact, in both cases we are talking about “testing”. We use the term “testing” generally for some activities which have very different goals and focuses, and need different skills – and require different sorts of people who do them. This could be one of the reasons why there is so much controversy about “the future of testing”.
So, my lightning talker (I am sorry, I don’t know his name – if one of you does, please drop me a line!) called for a renaming. He demanded that we think about the differences (mentioned above) and rename some testing activities simply as “checking”, and, of course, call the other ones “testing”.
He called it “checking” when only a “true” or “false” is possible, and which can be repeated as often as you want. His main focus was on automated testing. Later I wondered if manual checklists are not also part of the “checking-not-testing-section”.

From my point of view it might be useful to differentiate between checking and testing, especially in order to discuss the question of how “Agile Testing” should work, or if a QA department in agile environments is still necessary or not (or what their prospective main tasks might be).

Because I’m still thinking about it and working on the distinction, I would appreciate your feedback very much. Please leave a comment or send me an email with your thoughts and insights.

Powered by ScribeFire.

Joseph Pelrine: Self-organizing teams and Turning up the heat

Of of the most impressive sessions I had at the Agile2009 convention was Coaching self-organizing teams by Joseph Pelrine. He is a very good Agile coach with a great reputation and one of Europe’s leading experts on eXtreme Programming and Scrum, so it was a pleasure for me to join in.

During this three-and-a-half-hour tutorial (by the way: He started with Swiss chocolate for everyone – so he got us all after just 30 seconds! Simple but powerful tool… ;-)) he talked about different types of people and their different beliefs and how they influence the whole team. He showed the functioning of a team, comparing it with a swarm of birds. We had a wonderful exercise when Joseph Pelrine opened the doors of the room, and led us, “flying” as a swarm, through the hallway of the hotel. This small exercise – as well as the other ones – demonstrated to us in a very playful and natural manner the meaning of self-organization.

This is something I’ve always liked very much: Learning not only through intellectual knowledge, but also through direct experience. Even though it was an agile Conference, there were some other speakers who were not themselves very agile….

An important part of the session was dedicated to the question of how to handle teams and what would be necessary to make them self-organizing and working well. As Joseph Pelrine wrote in his abstract:
“Allowing a team to self-organize along the lines of ‘oh well, they’re all adults, they’ll figure it out’ is just as irresponsible as reverting to the command-and control school of management.” Full Ack from my side (if my humble opinion makes any difference in that case :O))!
So, he pointed out that it is always a matter of fine-tuning the dose. The image Joseph used came from cooking: If you want to cook well (=make a team working well) you have to put heat (=energy, change, etc.) into them. If you don’t, your meal (team) gets cold and solid (no evolution, no results, no enthusiasm). But if you put too much heat into it, you will burn (overstress, burn-out) it.

My opinion again: That’s an interesting insight which some managers and coaches don’t realize. Scrum and XP don’t mean “put as much change and pressure as possible onto your team”. It is always a question of the right dose, isn’t it? If you change too many things in a short period or if you want too much, you’ll burn them, guys!
It’s also interesting that, assuming the cooking theory is right, you need continuous change / energy from from outside. I wonder how this would apply to “doing agile” vs. “being agile” – but that’s another story (for a further blog article).

There was a surprising moment for me when we started representing the states of cooking when we, the participants, took up positions on a linear diagram outlined on the floor: We were representatives of different states of cooking on the scale, from “solid” to “burned”. I try to make it clear by a scribble:

cooking á la Pelrine

When we talked with others representing different states (e.g. “solid” and “burned”), I felt that it should be a circle, not a linear scale, because those from the “solid” state had similiar experiences as the people from the “burned” group. Despite the teams they represented being in completely different situations, the results of “burning” and “solid” seemed to be very alike (I earned another Swiss chocolate for this observation…).

I think this model is really good, because it’s simple, a good analogy and also matches my personal experiences.

If you are interested in learning more about the heat model, please have a look at Joseph Pelrine’s blog.

Powered by ScribeFire.