QA Is Like the QB of the Agile Design Process

With an agile design process, what we put into the customer’s hands is exactly what they wanted, and it works precisely the way it should. ELM couldn’t use an agile process without a Quality Assurance (QA) team calling the plays throughout the discovery, development, and delivery of the product.

QA Calling the Plays

Everybody knows if you can get input early, ultimately, you save money.—Beth Epperson, Quality Assurance Lead at ELM

Companies that use a linear, waterfall process finish a project or module and then hand it over to their QA team to review it and test it. Best case scenario, development goes back and make the changes that QA recommends. Worst case scenario, development has to scrap it and start over again. The waterfall process is a painful, fundamentally expensive process because it extends the development cycle and the delivery time. It’s like playing an entire game without a coach. But, after the game, the coach shows up and tells the team what they did wrong. Then, he sends them back out on the field to play the game over again, the right way.

ELM uses an agile design method, a proactive approach, as opposed to a linear flow process, which is more reactive. The idea is to take corrective action throughout the development cycle, rather than having to make changes to the end product. The agile method requires open and active communication between QA, the development team, and the customer. In this case, the coach, or customer, tells the team what to do, and the quarterback, or QA, calls those plays to the rest of the team. In an agile process, the entire team gets feedback during the game, so they can course correct before the game is over, or in the critical fourth quarter.

QA Advocates for the Customer

At ELM, QA collaborates with the customer through every phase of the project, from discovery, to development, and to final delivery. We are the advocate for the customer. QA creates a customer dossier with the customer’s branding and style guides. This allows us to be a better advocate for the customer, as we can identify things internally, sooner, so the customer never needs to make the same comments.

From the developers’ perspective, QA can sometimes be pesky, because we constantly remind them not to get off track from the customer’s requirements. But, we also make their jobs easier, as they don’t have to start over if they lose sight of the customer’s end goal. We essentially reign-in development or redirect them to where the customer wants to go.

Fostering Teamwork in an agile process.

At ELM, we use a visual collaboration tool called zipBoard and extend its use to our customers in order to foster open collaboration and feedback throughout the process. zipBoard allows real-time back-and-forth throughout the entire development process, rather than at checkpoints, like in a waterfall process. The customer is able to add their requests and record their feedback directly into the system. Development can find issues easily and fix them easily and QA can validate them more easily.

Before zipBoard, we didn’t have the ability to easily exchange information with our customers. From a visual perspective, customers were restricted in trying to articulate what they wanted or needed, because they would have to explain what their screen looked like and where they wanted to make changes. From a textual perspective, they handed a document or spreadsheet back to us with their changes written down. We struggled to keep track of the issues because we had to translate feedback from their environment to our development team’s environment. We were also challenged with keeping track of deferred changes that wouldn’t carry over from one phase to the next.

QA Validates Throughout the Process

Instead of handing over a finished product, we provide the customer with multiple alpha builds. We believe that the sooner they can visualize their deliverable, the more satisfied our team will be because the customer can provide input earlier rather than later. For example, they’ll do reviews, suggest changes, and do edits to each alpha build right through zipBoard. We might have two or three iterations for each phase. Sometimes that customer will want to add new functionality or whole sections as they view a module.

This is what QA uses as their validation process. During the development cycle, we have multiple time frames where we engage the customer for their input. This makes for a much stronger teaming relationship because we are able to respond quicker to their concerns, from their perspective. It also allows us to re-sync with the client if we see they are also going off course.

On the Fly Testing in an Agile Design Process

In the waterfall process, the designers create a module and the QA team writes a series of test plans and design a series of test cases to meet them. When the finished module gets handed off to QA, the QA team goes through every one of those test cases. It’s a cumbersome, inefficient process.

In an agile process, QA doesn’t have discrete test cases to follow for every project. What we do have are testing philosophies. We approach each project with a general perspective, keeping style and branding guides, content guides, storyboards, and of course industry standards (like the Chicago Manual of Style) in mind. By knowing what we need to look for, i.e. having that data in our heads, we can approach QA from a more holistic, fluid point of view. By following this holistic guideline approach, we are more consistent in what we do, and how we do it. We have the ability to look at entire projects with a broader perspective, instead of just a tunnel vision into a specific piece.

While the waterfall process still works well for some projects, in the design industry, the most effective and efficient process is an agile approach. But the agile design process is too difficult without a highly-involved team to keep development on track and advocate for the customer. That’s where QA comes in. In an agile process, QA makes sure that the customer gets the product they want and that it works the way it should. 

 Author: Beth Epperson; QA Lead

 Designer: Kim Cyprian; Jr. Designer