Monthly Archives: January 2010

Agile Testing, Testing

“So, what should I do tomorrow?”

5 Comments

Far too long I have skipped this write-up. The motivation for this entry comes mainly from Anne-Marie Charrett who hada dream about software testing. Rob Lambert then reminded me on this by stating that I shouldn’t judge people too quickly. So, what is this all about?

Reflecting over my personal education and development background, I got from university four years ago into software testing. Never having heard of anything about it, never actually confronted with test-driven development, knowing nothing more than the concept behind it. I was introduced to software testing just by getting to know the shell-script based test automation part that was done in my department. Over the course of one or two years, we found out that we got a problem.

So, I started to dig deeper, and came across Lessons Learned in Software Testing. The ideas blew my mind. As a result from that I got paralyzed, rather not knowing what to do about it. It took me nearly half a year to incorporate my knowledge back to action.

“So, what should I do tomorrow?” is a question I would have asked by that time. Today, I know more things, maybe, but still the problem behind it exists. New testers coming from the university, lacking knowledge of software testing due to lack of courses or interests at the university, get into our profession, and are faced with the impossible struggles, that you can’t automate everything, can’t test everything, can’t assure anything. More often than not, these testers don’t get proper job introductions, don’t get formal classroom training – or maybe just too late – and need to self-educate themselves a big deal.

So, instead of paralyzing these testers, there must be something better. Sure, there are a bunch of great books out there, but personally I started to hate most testing related books. They are neither brief, they don’t tell real-world stories, and translating the concepts and ideas into action is a hard thing. In addition it’s hard to find out which books to read while the thought-leader of the testing community keep on fighting about vi vs. emacs in testing.

There are indeed some rays of hope. Matt Heusser for example is working on a book titled “Testers at work”. Just the title makes me wallow in great hopes. “Beautiful Testing” edited by Adam Goucher is another one (though I still haven’t read it, yet). Instead of arguing one over another all the time, I think time has come to actually help new people getting into the field and master our craft. Interactions with developers, interactions with project managers, interactions with superiors and other testers are all circumstances a new tester will run into. Leading new testers astray here in the beginning is a very bad thing to do. How come a lot of sticky minds are fostered in our profession? Do they just end up as testers, since they can’t find another job as a developer maybe? I think time has come to change the picture of testers in our industry by actually doing something different and helping others do the same. Leading by example instead of arguing Windows vs. Linux.

What ideas about it do you have in mind?

Leadership, Retrospectives, Testing

On Feedback

Leave a comment

In a comment on my last blog entry, Thomas Ponnet reminded me of something I experienced during my years at the university while I was working in a local shop. By that time I was responsible for ordering beer and non-alcoholic soft-drinks, and getting them into the shelves. We had a weekly ordering cycle, and some of the better brands needed to be ordered in large amounts and refilled over the course of the week – i.e. directly before the weekend.

My direct superior switched jobs to another shop, and we got a new superior. The first thing our new boss changed, was the responsibility for all orders in the food department. Just the new boss and his substitute would make all the orders in the department. Groceries, meat, alcoholic and non-alcoholic drinks, etc. We were asked to simply fill the shelves, and keep the shop beautiful.

Now, think shortly over how this felt. Our self-responsibility was taken away. This resulted in a more senior student temp to quit. The new orders from his new boss were just too ridiculous to stay there any longer. I decided to stay, but I also got the exceptional status to still order goods myself. So, in order to demoralize a team completely, just take their self-responsibility and observe the degeneration. This holds for teams in your local shops as well as for software development teams.

Now, over time I observed the other areas, where I wasn’t mainly responsible, but helped to fill in the shelves from time to time. The food substitute ordered more and more goods. The problem was, that the substitute did no longer have the time to do the refills. Over time she was simply noting down the orders during her shifts. The problem was, that she started to make mistakes based on the time pressure I think she had to finish all these orders off in the time given to her. So, time pressure resulted in more human errors. Sounds natural, doesn’t it? This also holds for software development teams, doesn’t it?

What then happened, was striking me. We noticed all the errors the substitute made during noting down the orders. Since we took the new goods and put them in the shelves, we noticed there were blanks after we finished, and there were remains we needed to carry over to storage in the back – hopefully the remains would fit into the shelves in a week or so. But, instead, the substitute while noting down the orders for the next week, saw the blank place on the shelf. She then did the same mistake again, ordering just those goods, that were full and we had still some remains in the storage, instead of the product that was actually missing. Since she didn’t have the feedback from her orders, they got worse and worse, ever resulting in larger and larger piles in the storage. Over the course of a year the remains in the storage raised by a factor of four.

What I learned over the course of two to three years by then was, that people responsible for a job have to get the feedback of their actions. This holds for shop ordering teams in the same ways as for software development teams. Without the feedback on problems and errors, I cannot learn to avoid these errors the next time. I will be pretty oblivious to my courses of actions. In the software world, there are several things we may pile up. Maybe it’s a large test suite with unreasonable execution time, maybe we pile up Technical Debt, or maybe we pile up Design Debt, or, or, or…

This is why Agile development teams iterate and reflect. They get their feedback regularly and decide how to adapt to problems and new situations regularly. That feedback is crucial, don’t remove that feedback from your teams – and please leave them their responsibility.

Leadership, Testing

On Attitude

4 Comments

Last week I came across a tweet from James Bach on Twitter:

I break dreams about products, not products.

Since I am currently reading through Quality Software Management – Volume 4: Anticipating Change from Gerald M. Weinberg, I had the Satir Change Model in mind. Jerry cites Virginia Satir there:

It may look like a crisis, but it’s only the end of an illusion.

Adopting the citation from Weinberg, putting it into James Bach’s citation then became the following tweet:

Testers don’t break software, we end illusions about its usefulness.

Alistair Cockburn commented on this with the following:

I liked when a tester said, “My job is to see that once it gets past me, it doesn’t break for anyone else.”

This made me thoughtful. Finally, I realized that I need to put my phrase into context.

What I had in mind with testers ending illusions about software, is the fact, that testers do not put quality into the software just by their work. Tester interactions with the project manager, the business analysts and product owners, the developers and the customer probably end up in high quality software. Often, testers are the messengers of the bad news and might get the blame for their messages, but they shouldn’t. Testers just test the software they get handed and make evaluations about it. We collect the information and our reports maybe let developers fix bugs or make project managers delay product deliveries, but testers don’t create quality, we try to make it transparent. So, my statement is more against the management view on testing as it is prevalent in some organizations nowadays.

On the other hand, what Alistair is referring to is the attitude of a tester at work. Of course, I want to be proud of the job I did and sign for the testing I did. Taking it to the extreme that no one else will find a problem, when I’m finished with the product is a really good attitude. Most good testers I have met had just this attitude. When I have finished testing the product and the manager decides to ship it upon my report, it’s a moment of pride for the work I achieved.

But there is a problem with quality. Quality is time-effective. Software that is perceived to be of high quality, may be of poor quality tomorrow when a competitor delivers a new version of his product and puts my company out of business with it. As a tester, there is little I can do about that. I can communicate about the information I got while interacting with the software. I can communicate about the information that bug fixing seems to take longer and longer, which might indicate Technical Debt. But since I don’t have control over the business schedule, the developers and resources on the project, I cannot decide to do something about it. Instead, I make informations about quality transparent.

Of course, the right attitude for a tester is great, and as I learned the tester Alistair mentioned got promoted several times in the last two decades. But, testing attitude alone does not lead to quality software in itself. On the downside, there are decisions taken for testers and they receive the blame in the end, as Michael Bolton pointed out:

People give testers scripts with explicit steps and observations, then ask /the tester/ “Why didn’t you find that bug?!”

Now, that’s ridiculous!

Leadership, Methodologies, Retrospectives, Testing

Planned conferences in 2010

Leave a comment

Zeger van Hese‘s summary of the Agile Testing Days in 2009 reminded me to write about some of the conferences I plan to attend over the course of this year. And yes, Zeger is right, since it was my first conference presentation back in October, I was very nervous. Thanks again to Gojko Adzic and Mike Scott, who gave me great feedback the evening before during the Oktoberfest took place. On a second note, Zeger attended nearly all the presentations I was also in – despite the tutorial.

That said, I’m going to attend the Agile Testing Days from 4th to 7th of October again. The submissions are still open until end of January, but I think one of my proposals may be selected. Additionally, this year it’s going to be a four day conference. So, I plan to be fully blown afterwards.

Another great conference last year was the Software Craftsmanship Conference in London in early July. Thus far Jason Gorman has not decided upon the programme, but he’s working on the submissions. If I can make it by any means, I will attend again and maybe get one or the other book signed. I don’t plan to submit an own session.

A conference I haven’t visited last year is the XP2010 conference in Trondheim from 1st to 4th of June. I’m not sure whether to participate there. I will make this dependent on whether my submission will be taken.

Last, but not least, I plan for the XP Days Germany, though I haven’t seen any planning for the conference thus far. Last year the conference was great. Personally I had great exchanges with Alistair Cockburn on methodologies, the Agile manifesto, and a possible future for Crystal. That said, I hope to attend the conference and get to know another great keynote speaker there, hopefully.

Testing

Weekend Impressions

2 Comments

Here are some of my impressions of the first European Weekend Testing session – in brief. The participants included a bunch of great testers: Anne-Marie Charrett, Phil Kirkham, Jeroen De Cock, Zeger Van Hese, Thomas Ponnet, Maik Nogens, and later Jassi from Mumbai joined in, too. Ajay Balamurugadas from the Weekend Testing community was kind enough to guide Anna Baik and myself through the first session.

After introducing ourselves to the others, we got our mission and started the first hour with testing activities accompanied with many questions in the group chat we set up. We delivered our test results at the end of the first hour and jumped into the discussion about our individual course. I won’t dive into too much detail here. There were two points which were striking for me.

First, domain knowledge may be both, helpful and leading to inattentional blindness. The application we were testing had something to do with picture editing. Over the course of my university years we had learned a lot about manipulating pictures. This helped myself a lot. But, as I found out in the second hour (and a half), the other participants did not all have this background. That said, I had some knowledge of the domain of image editing and could go through the functions regarding manipulation of images rather quickly, where the others struggled to do so or simply couldn’t tell if the results are fine or not. On the other hand too much domain knowledge leads to inattention to undocumented features and what they do. Since the application lacked documentation of the functions available, the others could just guess the features were ok.

The second lesson is that we jumped into testing the application too quickly. Honestly we had a great mix of different testers. No one told us to jump into the application each tester on her own. Indeed, in retrospect taking the mission and dividing it into smaller pieces which then would be tested by two testers would have given the whole activity a great mix. Everyone would have been able to concentrate on their particular area of specialty. In combination we could have found a big deal of bugs in no time with this approach. What makes me sad about this, is the fact that I too often see this when at work. Testers take their task, jump in, and report problems back. Seldom they align their work with the work of others beneath them. That said, the first thing to teach a tester should be most probably the ability to work together with a colleague. I have big hopes that this would help our profession a big deal.

So, in conclusion, I am really looking forward for the European Weekend Testing Session 2 next week. It was a great pleasure and learning opportunity in a safe environment. Thanks to everyone who gave me this great time.

Agile Testing, Software Craft, Testing

The Craft of Software Testing

1 Comment

The inaugural issue of the Agile Record magazine includes an article from myself about some thoughts on the craft of software testing. In it I describe my understanding about the craft and how testers may reach a level of professionalism where they know what they’re doing. Deliberate practice is one thing in that equation.

Looking through the magazine, I spotted great articles. Dawn Cannan co-authored with Lisa Crispin an article on being the worst and why it pays off, David Evans has an article on testability and considerations on whether to invest in it or not, Lior Friedman has an article on the agile view on quality, Marc Bless has an article on Scrum forced on an organization, etc. Before listing up all the contents here, go to the Agile Record page, subscribe (it’s free), and get your personal copy.

Software Craft, Testing

On the relevance of context

2 Comments

As software testers we use context to point out that not all practices may be used in any situation. This is one of the key principles of the context-driven school of testing. Robert Martin talks about particular practices in the professionals tool-belt that are used in a project based on the particular context of that project. Alistair Cockburn names the same concept Just-in-time methodology construction and defines a large amount of practices and principles to use in software development projects. For me there always seemed to be a pattern behind this concept and I decided to write it up for public discussion.

Lately, I read through the Quality Software Management series from Gerald M. Weinberg. In it, Weinberg discusses differences between the Routine organization and the Steering organization. The key difference between the two organizational cultures lies in following a prescribed way to handle a project and choosing among several techniques and practices based on the current situation. In a Routine organization there is one particular process defined and software projects shall follow this. Of course, project managers take care of following this one process. In the Steering culture there are many processes which may be followed. In a Steering culture the controller of the project chooses among several practices and knows when to adapt by taking the outputs of the previous project phases and feeding this knowledge in to the inputs of the next project phase. A controller of the project may consist of the designated project manager or the project team as a whole.

About two years back my wife amazed me with a similar lesson in a completely different area of life. For my birthday I got a jigsaw puzzle. My wife has over hundred puzzles in the house and she all finished them. When I got to know my wife, we spent several evenings together puzzling. During this period I had adapted a technique from her to get the puzzle started. By sorting out similar shapes and then combining them according to their particular shape-type, she was able to make steady progress with the jigsaws. Therefore I started by doing the same thing. Having finished the outer frame, I sorted the remaining pieces by their shape and started over.

After some hours puzzling, I realized that copying this strategy did not work out for my puzzle at hand. I did not make much progress and had become a bit fed up with it. After reflecting some minutes, I realized that I was stuck by the wrong strategy. The puzzle showed an image of penguins in an icy world. Therefore the pieces contained mostly black and white fragments of that picture. It was a lot easier to first partition the pieces according to the color rather than their shape. My wife applied the strategy by sorting out shapes with more colorful puzzle images, that helped her succeed there, but for the image at hand I had focused on the wrong strategy. After changing it I noticed that I could make much faster progress than before.

Of course, in the story above I had less experience with jigsaws than my wife had. Over the years she adapted several techniques for finishing up a jigsaw and based on the particular circumstances she choses among the several techniques she knows. When I started the jigsaw I had a vague understanding of one of her techniques and foolishly tried to apply it. Just by making myself aware of the situation when things did not turn out, I was able to try out a new approach to follow and add another technique to my repertoire. Similarly in software testing and software development we need to make ourselves aware of the particular situation in our project and reflect over the course of it. When we get aware about problems, we can help ourselves by choosing another technique or practice to follow for the next few weeks in order to improve the overall course. By continuously making ourselves aware of the situation and the context at hand, we can deal with changes circumstances and try out new things if we get lost.

Testing

New Years Gift to Europe

4 Comments

Regular readers of my blog might have noticed that I was referring to learning and practicing a lot lately. There is a bit more of it than just some random series of blog entries.

A while ago Michael Bolton and James Bach mentioned the Indian movement called Weekend Testing. When I started to dig deeper into it, I found that this community is doing a great job of honing the craft of software testing. Fiona Charles also mentioned them in a recent column on sticky minds.

In December I heard about the Weekend Testers going into other locations. They call these chapters. When I asked for interests to form a European chapter, I got in touch with Anna Baik. After some initial contact, we discussed how to grow Weekend Testing together with Ajay Balamurugadas and came to the conclusion that we’re going to roll this out as a New Years gift to European testers. We will run the first few sessions during January with support and mentoring from our more experienced colleagues from India and then observe how to continue the deliberate practice.

So, Happy New Year, Europe and stay tuned for more to come.