I spent the better part of last week at the Eurostar 2009 testing conference in Älvsjö, Sweden. I’ve never worked as a professional tester myself, but the topic of testing is gradually becoming more interesting now that more effective and humane approaches to testing are spreading widely.
My reason to go to the conference was to meet friends from AYE, to network and to scout the world of test. For almost seven years now, I’ve been using, teaching and introducing agile development with Scrum at all kinds of companies in Sweden, and while I’m no testing expert, I often meet testers who struggle with how to be of best value in their new cross-functional teams. I need to understand the realities of testing to be able to help my clients.
Before I got into consulting to project teams, I was a programmer. I remember one time when I tried to convince a contract tester at a client company to help us test the product we were developing. He was very hesitant, because he was a busy person. His services were in high demand, because he could find bugs everybody else missed. After some cajoling, he at least agreed to consider it, and said he might be able to help us if he found some spare time. He also added: – I will help you under one condition: I will execute no written test cases from you.
Turns out this sought after tester was actually a student working extra hours doing testing. Because he had no formal training in testing, he would exercise the product in many different ways, and apparently in many more ways than the employed testers would, since he found many more defects than they did. He used his intelligence and skill to test the product.
In the end, he never found the time to help my project, and we had to manage our own testing using a combination of automated unit tests and manual testing. While doing this, we found a possible bug in the software embedded in the hardware we interfaced with. We presented our theory to the responsible developer, who dismissed us by explaining that a bug in that code was impossible, because it had been tested and used for some time. Besides, wasn’t it quite unlikely that two Visual Basic programmers would find a bug in C++ software?
As luck would have it, a colleague from a previous project was still on site, and he was a true C++ ace, who I knew had learned how to avoid many of the vicious traps in that language. We asked him if he could help us, which he gladly did. Late one day, he checked out the code on his laptop to have a look at it. The next morning he came back and told us we had indeed found a defect, and he knew where it was. We asked him how he knew, since he couldn’t possibly have run the software from the comfort of his living room couch, where he told us he had found the bug. He told us he had simply read the code line by line until he found the defect.
With our C++ ally as backup, we went back to the programmer doing the embedded programming. Our ally simply proclaimed: – You have a bug, to which the embedded guy replied. – Oh, do we? Ok. They then worked together to fix it.
So what does all this have to do with agile? Well, agile is about being able to clearly understand our true progress, so that we can behave more effectively as we learn more about reality. Among many other things, this requires insight into the current status of the product under development. Testing can give us this information.
I’ve noticed that those who struggle most with testing in agile projects are those who either cannot see the need for testing, or who can’t let go of the traditional scripted way of testing software. They insist on doing no testing at all, or on creating detailed test scripts for manual execution, and this causes problems for them.
If you want to learn more about alternatives to scripted manual testing, you should check out the videos I’ve inlined below. The first one is an interview with “testing naturalist” (gotta love that) James Bach, the second is (a few years old but still excellent) Google Talk with Elisabeth Hendrickson.