My Life as a Software Professional

I have twowell, three reallypassions in my professional life: test, configuration management, and process improvement.

I started my career as an all-around developera little requirements elicitation , a little analysis, a lot of coding and recoding, and some testmore than 20 years ago. During these first professional years , I always loved testing mostmaking my work run on the computer and enjoying the satisfaction of being told, in a factual and precise way, that something was wrong. This enabled me to carry out the correction and then finally enjoy the privilege of knowing that at least this error was a secret between me and the computer.

My experience grew, and my working teams grew. The problems grew. I wasn't always certain I had produced what I was supposed to and that I had tested everything. And sometimes an error would recur!

I got a job in which I was responsible for system and acceptance test in a company making software for the European Space Agency. For the first time in my then 12-year career, I heard the words configuration management . I had no clue as to what it was, but as I spent hours and hours trying to figure it out, discussing it with the person responsible for quality assurance and actually using parts of it in my daily work, I came to understand what a wonderful tool I had.

For the first time, I was able to trace my test cases to the requirements. I was able to tell, at any point, how many requirements I had covered in my test specification and how many were outstanding. I didn't have to encounter the frustration of having made test cases for requirements that weren't going to be implemented. Where I had forgotten the reason for a turn in the work, I was able to find a previous version of my test specification and see why I had changed it. I loved it!

The last seven years, I've worked as a consultant, spending a good deal of my time on testing assignments of many types in many companies. One of the things I've learned from these assignments is that there is often a difference between what a customer asks for and what he really wants, what he needs (what you want to give him), and what you're able to give him.

Test consultants are often presented with a system to test without the right conditions for performing a professional test. The requirements may be in any state from nonexistent to brilliantly documented, with a pronounced bias toward the former. If requirements are present, they are most often not up to date. This is partly a requirement specification problem and partly a configuration management problem.

Testing requires resources in terms of time and people to perform the test. These resources are often all too scarce . This is a project management problem.

When test consultants plan and perform a test, they need to establish an overview not only of what has to be tested but also how the test is progressing, what errors have been found, and what the state of error correction is. These are configuration management issues.

It's tempting for a consultant to try to deliver what the customer really needs. However, this approach has some limitations and drawbacks. The art is to strike the right balance between what's needed and what's feasible . One of the things to keep in mind as a consultant is to keep up the standards but keep it light. So I try to keep up the configuration management standards as I solve the test assignmenthoping my customer will get an idea of what configuration management is and maybe ask for some assistance in that direction too.

Another part of my time is spent assessing software-producing companies using the BOOTSTRAP maturity model and method. Like the related Capability Maturity Model (CMM), this model includes configuration management. As an assessor in more than 40 assessments, I have time and again seen the blank look in people's eyes when I ask how they perform configuration management. The eyes are rarely less blank if I elaborate and ask about tracing between work products, production of error reports , or other detailed configuration management disciplines.

On the other hand, people are more than willing to talk about problems they've experienced due to lack of control over what is being implemented and testedand whenand lack of control over what errors have occurred and which ones are being corrected and which are not.

Although configuration management is one of the basic disciplines for sound development (in CMM it is a key process area at level 2), many people go through a considerable part of their careers without any idea of what it is and how it can ease their everyday tasks , just as I did. So I keep emphasizing its importance and very often recommend it as one of the first disciplines a company should work on when embarking on structured process improvement.