You'll Never Walk Alone

Before we start looking finding QE team members, building automated tools, and defining lightweight and repeatable processes, there's one point I want to make. You may be feeling a bit overwhelmed by the scale of the work you have to do in your new position. You may also be feeling a little lonely. But, fear not. You are not alone. You have a new constant companion. A companion that will be right beside you every step of the way. Who or what is this companion?

Risk.

That's right. Risk will always be with you. How you handle risk as it applies to the software under test will determine how successful your testing is. So, how do you handle risk? I think that there are (3) things you have to keep in mind:

1) There is no "Out" - A few years ago, a good friend mine called me to say that he was completely debt free. He had paid of his mortgage and his car. He said that he would "never again" be in debt. Then, his car needed major repairs. He bought a new car. Then, he and his wife decided that their kitchen was outdated. They remodeled. Then they had a baby. You probably get the point. Risk will always be there and you will always have to work to minimize its impact on your project. Something, whether new features, new requirements, new or old bugs, will put the project at risk. Speaking of bugs...

2) There are Always Bugs - Have you found all the bugs in that code? No? Well, don't worry. You never will. The simple fact is that there's no such thing as "bug-free" software. Why is this so? First, on the development side of the equation, you have to deal with changing technology, a complex and often flawed application design, the difficulties inherent in integrating new and existing systems, and so on. Human error is also a huge factor. Although modern application development tools can generate code, people must be involved at some point in the development process. And people make mistakes. On the testing side, you will always have to concentrate on finding the bugs that put your project most at risk. Most at risk today that is...

3) "What's at Risk?" The Better Question to Ask is, "What's at Risk NOW?" - No software project will even be static. To be successful, your project will have to respond to your customers' changing requirements and will have to adapt to and incorporate new technologies. There's a great line from JFK talking about political parties that I used in article to refer to software test planning. The line is that these parties aren't locked in amber, but flow like rivers through time. (Theodore Sorenson actually wrote many of his speeches, but JFK always claimed this line as his own.) It's like that for test plans too. You can try to anticipate everything in advance, but in the course of testing, you always learn something new and have to change the plan to incorporate new or changed tests based on the risks that the project is currently facing. These risks will change over the life of a project. Early in a project's development, the major risk may be that new features are simply buggy, or that integrations between major project subsystems are in conflict, or that the build process is so immature that unintended software changes are introduced. Later on in a project's development, the major risk may be that the original designers of a project have been replaced by new engineers who, in the course of fixing bugs, break the existing design.

So - how do you cope with all this?

First, don't expect that your job will ever be risk free. Your job is to manage that risk.

Second, don't expect that your software will every be bug-free. You have to manage your resources and testing to find the bugs that matter most.

Third, don't expect that you can relax because "all the risks" have been mitigated. In the time that it took you to read this blog post, a new risk was probably either exposed, inadvertently coded, or dreamed up down the hall in marketing. So, don't lock your thinking or your test planning in amber. Think of your project as a river. Maybe even the kind that people go white-water rafting it.