The much maligned and terribly misunderstood profession of Software Quality Assurance
Over the past few years I've been starting to gain an appreciation for why Software Quality Assurance is difficult, why it is so different from software development, and the extent to which QA professionals are thwarted in doing their jobs well by misconceptions about their profession.
The first simple problem with QA is that, if things are going well, QA delivers no results. A column of PASS results for a 10,000 case test suite generates no bugs. It's a nice problem to have, but the result is managerially invisible, as well as being invisible to the software developers who are expecting clever tricky edge cases that they hadn't considered when writing the code.
Trouble is, clever tricky edge cases is not where you start with the basics of QA. The very first test cases you want to write are the ones that are always supposed to pass, because if indeed they ever fail, that's the first thing you want to know about. So if you're kicking off a new software project, you can realistically expect zero useful results from QA (at least from a developer's point of view) while they are establishing the baseline coverage.
The second problem is that so very few real QA professionals exist. In my experience, software QA is staffed to a remarkable extent with people who wish they were doing something else, like working as a park ranger, or driving monster trucks, or playing in a band. And yet here is a real, distinct discipline that requires skill, understanding, training and methodology - a valuable and quite challenging profession that deserves far greater recognition than it receives.
Bonnie says that I'm spending too much time blogging and not enough time with her, so this post will be continued at a later date - there is much more to say...
The first simple problem with QA is that, if things are going well, QA delivers no results. A column of PASS results for a 10,000 case test suite generates no bugs. It's a nice problem to have, but the result is managerially invisible, as well as being invisible to the software developers who are expecting clever tricky edge cases that they hadn't considered when writing the code.
Trouble is, clever tricky edge cases is not where you start with the basics of QA. The very first test cases you want to write are the ones that are always supposed to pass, because if indeed they ever fail, that's the first thing you want to know about. So if you're kicking off a new software project, you can realistically expect zero useful results from QA (at least from a developer's point of view) while they are establishing the baseline coverage.
The second problem is that so very few real QA professionals exist. In my experience, software QA is staffed to a remarkable extent with people who wish they were doing something else, like working as a park ranger, or driving monster trucks, or playing in a band. And yet here is a real, distinct discipline that requires skill, understanding, training and methodology - a valuable and quite challenging profession that deserves far greater recognition than it receives.
Bonnie says that I'm spending too much time blogging and not enough time with her, so this post will be continued at a later date - there is much more to say...