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.

"Now What Do I Do?"

I'm been thinking of taking this blog in a slightly different direction. The motivation for this change came from the question that is the title of this post.

A couple of years ago, a good friend of mine, a product manager, called me up on a Sunday night asking for help. His software startup company had been growing quickly, as had the number of bugs in its product. They needed to implement a formal testing process, put together a QE team, and build automated tests. And fast. Unfortunately, no one at the startup had ever done this before. My friend was brave enough to say, "hey, I know someone who could help." So - he was placed in charge of the task. I wrote up a couple of pages of ideas for him so that he could get started.

I've thought often of his question as other people have also asked me about how to set up a QE team from scratch. One of them was also at a startup, a couple of others were working on new projects at larger companies, while another had just been promoted, with no advance notice, to manage a non-existent QE team. What they all had in common is that they had to build a new team, find or develop tools, and define a testing process, all while they were also trying to meet an aggressive product release schedule. Sort of like building a bus while it roars down a highway.

Anyway, what I'm going to try to do in the next series of posts to this blog is to answer that question. I'm hoping that this series of posts will be a useful roadmap or reference guide. The scale of the posts will probably be longer than most blog posts, but I'm going to keep the combined total length of the posts shorter than a book. After all, if you're in a situation similar to one my friend found himself, you don't have a lot of time to read!