Author: Stan

I think the most impressive looking items on my resume are probably my stint as Director of Quality Assurance at two small companies. In reality, however, my current job as QA Architect at Borland is, by far, the best experience that I’ve had.
At the small companies, I was in charge of both architecting and implementing QA processes. At my current job, however, I am responsible for helping other groups within the company implement the processes that I devise. That’s a much more challenging and educational task than implementing my own processes, and it’s also, not coincidentally, why I sought a QA architect position at a larger company.

In common usage, I think the term ‘exploratory testing’ is often used to refer to ad hoc testing–it’s lipstick on a pig. But the big thinkers in quality assurance view ET as a structured testing process. Mike Kelly lists some of the skills necessary for performing exploratory testing. Mike also points to the newest version of James and Jonathan Bach’s Exploratory Testing Dynamics [PDF] document, which is very useful.

In a new post, Scott Barber reminds testers that there may often be valid business reasons for making decisions that may run counter to the tester’s view of what it takes to build quality software:

Most testers I meet simply have not been exposed to the virtually impossible business challenges regularly facing development projects that often lead to decisions that appear completely counter to a commitment to quality when taken out of context. The fact is that there are a huge number of factors influencing a software development project that, at any particular point in the project, may rightly take precedence over an individual tester’s assessment of quality. Given their lack of exposure, it’s no wonder testers seem to habitually take a “my team doesn’t listen to me” point of view.

When I conduct job interviews with QA engineers, I often test the candidate’s awareness of these factors by asking this question: “Can you name a time when you just had to put your foot down with regard to quality? For example, declared that the software can’t ship due to quality concerns, etc.?”
It’s a little bit of a trick question. The answer that I hope to hear is: No; it’s not my job to make those decisions; it’s my job to provide risk assessment data to decision makers who do have to make these tough decisions. Secondarily, if I’m doing my job correctly throughout the dev cycle, there should not be any surprises of this type. If a situation is building that might result in such a confrontation, then I haven’t done my job in monitoring the situation, trying to solve it, or at the very least keeping management in the loop on the building crisis, so that they can make appropriate contingency plans. There’s nothing management likes less than getting into a crisis situation with no warning.

Down under, Dean Cornish has been having a hard time finding qualified QA engineers, and in his recent blog post, he ponders why that is.
In his post, Dean throws out a lot of possible reasons for this problem, but the end of the post gets to the heart of the matter for him:

Off the top of my head I cannot recall a single university in this country that talks about a career in testing as an equally viable career choice in the same vein as development. Even though in the workplace, I’d argue that testers have an equally as important role as developers. This discrepancy contributes to our lack of growth in mature and capable candidates, leading us to see the same poor candidates going from shop to shop and always somehow getting through the front door.
It is as though testing has become the place for people who fail at being a dev, a system analyst or business analyst or if you can pull a visa and need something where the demand is so great that the quality of the screening is frequently wavered to get “warm bodies” through the door.

Maybe the situation is different in Australia than in Austin, but I’m not sure I see the same dearth of qualified candidates. And as for Dean’s concern about testing not being seen as “an equally viable career choice . . .as development”, as far as I can tell, that’s always been the case. If anything, this situation might be better than it used to be as the software industry has matured.
I’d love to hear others’ thoughts and experiences.