I Do Love Software Quality Assurance

I've always felt like I got lucky when I fell into the Software Quality Assurance career field. As I've written previously, I completed a Computer Science degree while in the USAF but realized quickly that I did not have the patience to be a programmer. I can read code and follow the logic used and have done so on projects using a variety of programming languages; I just find it difficult to build programs myself. I don't know if it's a deficiency in me or I just never had an instructor present things in a way that made the light go on for me. My best bet is to take a block of code (such as HTML), play with it, see what the results are, tweak some things then look again. It's not efficient but it allows me to do some things and learn as I go.

I started in Quality Assurance through a nationwide Defense Logistics Agency training program. The DoD was in the forefront of implementing Software Quality Assurance programs and I liked the idea of being a pioneer. The DoD programs concentrated on controlling the process in order to control the product. For most QA "commodities" (textiles or hardware development for example), during the Engineering development phase of a project, QA is pretty hand off since there are always modifications to processes up until production. For Software though, if you wait for the production phase, all the software has been developed already so there's nothing to monitor for the most part. Software is nebulous, ephemeral even, as you can't pick up the bits and bytes that go into a program while it is being developed. So you use the things like Requirements reviews, Design reviews, Code inspections, and so on during the code development to monitor the quality of the product.

I was placed at a Defense Contracts Administration Service, Plant Representation Office (DCASPRO) at a GTE facility. I had occasional battles with the various GTE folks on most every program they had but knew always, that the processes and procedures they used worked. They had empirical evidence. I was told a few years later when the idea of the Capability Maturity Model was hitting the literature that this particular facility was one of the handful of organizations worldwide deemed to be operating at a CMM Level 3. Probably my biggest surprise after I left DLA was just how many firms continued to fight the idea of robust SQA programs and processes. Which goes back to the lack of respect often accorded to Quality Assurance within a lot of organizations.

For years I resisted getting involved with the Testing side of QA. Waiting until the start of testing to "test the quality into the application" is wasteful, although it is not uncommon. Then I got tapped for a couple of testing intensive projects where I began to see all the ways testing could be brought into the picture far earlier than is normal. And I found out that testing is fun.

You see, as a tester, I get paid to break things, i.e., the software application. The easiest testing is when the requirements have been laid out nice and neat, assigned to development modules and the design of the application is available to use as part of the work flow of the application. Rare, but the easiest. Most often there is some mix of the requirements and design information available and you work with the information available to you. I and most all testers are going to be running test to make sure the application does what it is supposed to do, i.e., it meets the stated requirements. What I try to do is also make sure the application does not do what it is not supposed to do. So as I develop my test scenarios and test cases, I try to interject "faults" where I purposefully hit the wrong key or try to perform an action that is not supposed to be allowed at all levels of user. Variants on this allow me to see that the application is handling the error conditions correctly. I have found security holes you could drive a truck through by testing in this fashion, all because most of the folks (often someone with detailed functional knowledge of a job and its requirements but not a lot of QA or testing experience) tested just for the positive attributes of the application and not testing the negatives.

The most difficult testing is when there are no formal requirements specified or design documents. So what do I do? I try to blank the mind and just accept the "as written" application. Most custom applications can be learned just by plugging in information or clicking links to see what happens. It's really inefficient but it can be done.

So there you have it. A mix of process related QA to go with some heavy duty manual testing experience. Both parts of the QA world can be brought to bear on just about any effort, and have positive results. That's why both are individual components in the American Society for Quality (ASQ) Certified Software Quality Engineer (CSQE) certification process. I do not have a current CSQE, my last having expired a few years ago (and I've let my ASQ membership lapse as well), but I was one of the first CSQE in the world, having taken and passed the initial pilot test back in 1995. Due to the travel and moving I've done over the years, I was usually in no position to re-certify without testing so I've taken the CSQE test at least three times over the years, passing it successfully each time. I own about a third of the books and documents that comprise the Body of Knowledge for the CSQE plus have my own experiences to guide me when I take the exam.

Mr Boris Beizer was one of the early gurus for Software Quality Assurance and Testing. In one of his books, he listed the Ten Attributes Of a Good QA Worker. The only area where I'm potentially in conflict is the first one of being a "good programmer" but I don't think he and I are all that far apart, even there.

So remember to call your QA staff ahead of time. We might even be able to save you some time and money, if you're willing to listen. Or if you don't have an experienced QA staff, I know where you can hire someone to help you get started.