If you asked 10 random people what Software Quality Assurance was, if you got any answer at all, you’d likely get Testing. To be sure, testing is a large part of what Quality Assurance is. It assures that your microsite, app or upgrade does what it is supposed to do and works for enough users to make it worthwhile. Testing catches all kinds of bugs, design flaws, browser and OS specific problems and ensures that the product does what it was designed to do. What it doesn’t do, however, is catch problems before the product is built. These problems are endemic, system-wide and can be a bigger problem overall than bugs in the code. These problems require upgrades in the process of a software development lifecycle.
Let me start with a real-life example. I had a friend who was interviewing for a QA Manager position for an ad agency in Manhattan. After the requisite phone interviews he found himself at their office interviewing with a producer. After two minutes a tech lead and the tech director came in, then 2 more producers, then 3 developers. All told there were now 9 people interviewing him.
“We want to decrease testing time. How would you do that?” said the Producers.
“No, Automation is more important.” said the Tech Leads, interrupting. “Can you do that?”
“No, we need better methodologies and equipment.” said the developers. “What would you do?”
For about 3 minutes the sides argued with each other, cutting each other off, getting more testy at every turn, belittling the other’s problem. Finally, the tech Director turned to the QA interviewee and asked:
"Which of these things would you fix first?”
“None.” The QA manager said flatly. They looked shocked. “First I’d fix your process.”
“How would you do that?”
“Each of you gets a number.” He replied. “Go outside. Come in 1 at a time when I call your number. Then we can have a proper interview. We’ll take the rest from there.” He didn’t get the job, but that was a blessing in disguise.
That story illustrates the point of needing someone to control the process in the software development lifecycle. Here you had three disparate groups at each other’s throats, each doing something different but wanting the same outcome: their questions answered. But without process, not only did things not go well, they passively and actively worked to subvert the other team members’ goals. Lack of process is a thief that way: It steals time and anyone that has worked on a short cycle or fixed deadline for launch knows, there’s nothing more valuable than that.
In Steps QA
So how does QA work to improve process? Well, one way it doesn’t is to tell a developer, Tech lead or Producer how to do his job. They know their jobs. But what they don’t know is the other persons’ job. As a QA engineer, you are a natural jack of all trades and should have some understanding of what a developer, producer and Tech lead does. As the person at the end of the line you can also see holistically the whole tech process from the start to finish. With this knowledge you can fine tune it.
Choke points often come from how one group interacts with another. Producers often give a lot of information to the developer but not always the right information. Tech leads get so worried about the architecture of the thing they’re building that they forget to see it from an end user’s perspective. Developers get so harried with short time cycles that they forget to smoke test before handing off to QA. These are just some very basic examples (all three of which can be solved with checklists), but you’d be surprised how basic the problems in process often are. Not only are they basic, but most frequently they deal with transition periods in the life cycle. None of these are problems like bad development or lackluster production. These and most process problems happen when one group hands off to another. Roles are not clearly defined, steps are ad-hoc and missed. Quality is dropped for expediency and quite frankly, lack of responsibility. Often times the solutions are clear-cut and simple. So how come they don’t get implemented? QA often doesn’t know it’s their job to do it.
Most of us SQA guys didn’t go to college to get software QA training. Many fell into it and discovered an aptitude for it. The problem with this is we wind up heavy on the testing, light on the Quality Assurance. Mark my words, though, it is your responsibility to ensure and improve the process in your company. So how to start?
A Few Examples for Owning Process
- Ensure that there is a proper build cycle in place. You own the QA environment (if you don’t control what goes in and out of that environment, you should). You have the power to reject anything coming in so you have the ability to sculpt the build process. Kill willy-nilly fixes. Regressing a site 5 times for 5 small fixes is a colossal time waste. Do it once and be done with it. This makes a developer’s life easier too because they don’t have to open and edit the same .js file 5 times in one day.
- Get involved in meetings early and often. You don’t have to go to every meeting a producer has, but being on a kickoff meeting gets that project in your head. Also, let’s be honest here, you can help steer creatives and producers away from ideas they don’t know are needlessly complex (I call these ‘the internet does not work that way’ problems).
- Create a ‘QA Kickoff document’. This is something for the producer to fill out at the start of the testing portion of the project. It should contain a general list of things like any copy decks, visual boards and timelines as well as support matrices, job numbers, responsible persons on the project, things of that nature. If the producer won’t fill it out, don’t test their project. If they can’t fill it out that thing is not ready to be tested anyway.
So those are just a few simple steps that hopefully mean half your problems are gone before you ever have to test your target. Just remember that it’s QA’s job to spot these problems, and fix them with delegated, repeatable steps. It’s ok, you’re not telling a developer how to code, she’s got that covered. You’re helping her after the fact when she hands it off to you. You’re not telling a producer how to produce, you’re helping him to communicate effectively and quickly when there have been changes in scope.
Make an argument to own that responsibility within your group and back it up with QA’s legendary ability to say ‘no’. You do that, and you’ll see after initial resistance, you’ll win them over to your side. Each successive project is another opportunity to streamline the process, to catch new and (hopefully) smaller kinks in the flow and to gain the holy grail of waterfall, agile or any life cycle: Repeatability.