QA in the Title but Not in the Work

How to elevate your game, thoughts from Robin Goldsmith

by Dan Cook

Does your job title include QA, but what you really do most of the time is straightforward testing? Does this bother you late at night, or while swimming laps in the pool? If so, it’s time to do something about it—like elevating your game to true quality assurance.

So says Go Pro Management’s Robin Goldsmith, an invited speaker at PNSQC 2016 and a participant in a recent webinar hosted by our own Phil Lew. Goldsmith’s favorite hobby horse is testers disguised as QA experts. He says such professionals aren’t doing themselves or their employers any favors by settling for less than a full, or “proactive,” software quality assurance process.

Goldsmith pioneered the proactive QA process and helped revise the IEEE standards for software quality assurance as part of the organization’s standard working group. He has quite a bit to say about the “weaknesses” among QA professionals he repeatedly runs into in his professional life.

“Very few people with the quality assurance title are actually doing quality assurance,” he said during the webinar. “Most of them are doing testing, and that’s not the same as QA. If that’s what you’re doing, you’re not getting the benefits of true quality assurance.”

The two main weaknesses he encounters in QA folks are an inability to perform logic analysis and difficulties with database content and construction, both of which he intends to explore in more detail at the conference.

Where he sees another significant process gap in the agile project arena.

“In my perception most of what I hear and see about agile over and over again is on the cultural acceptance of agile. ‘How can we get them do to it?’ What gets lost is developing the skills people need to do the work when they are in an agile project.

“That is prominent in two areas. One is in discovering requirements suitability, where I see a big gap between the user story and what ends up getting built. The other is the testing in agile, which tends to be very limited by user stories and the code that’s written. Both tend not to be sufficient. The testing of user stories is often very weak testing and people don’t realize it.”

The end result, he says, is product failure or underperformance. That’s why he’s eager to present to PNSQC’s membership in October. He wants more testers to live up to the billing of quality assurance, which will lead to better products and a better world.