We all want a perfect outcome—some glowing result of months of hard work and late nights of hashing and rehashing details. And ideally, projects would launch with no mistakes, no developer typos, and no overlooked requirements.
But the world of software development will include unforeseen roadblocks, and a perfect outcome isn’t always possible—especially not at first. And yet, many clients expect that perfect outcome.
Picture this: your design team puts together a beautiful mock-up for a discerning client. By some stroke of luck, the client is instantly thrilled with the concept and is ready to move forward with development.
The only hitch is that your developers never got a chance to see the design. And when you show it to them, you’re horrified to discover that what you promised the client is actually impossible to actually deliver.
This leaves you having to break the bad news to an already skeptical client, who wants to know why the unicorn they were promised looks like a donkey. And unfortunately, this is an all-too-common situation, one that can prove detrimental not only to your client relationships, but also to your reputation within the company.
To avoid awkward situations like this, you need to maintain a QA mindset from ideation all the way to the finish line. Doing so will put in place the checks and balances you need to ensure you aren’t over-promising and under-delivering.
At Hathway, we infuse this mindset throughout every layer of our organization by consistently performing quality assurance reviews, asking probing questions, cultivating constructive doubt, playing the devil’s advocate, and analyzing every possible angle — all in pursuit of a better product for our clients.
A QA Mindset Will Set You Up for Success
Adopting a QA mindset early in a project’s lifespan allows you to find and fix problems before they become show-stopping, capital-P “Problems.”
Some companies follow a “waterfall process” with a straightforward workflow: get requirements, send to development, build software, send to QA for testing, then deliver. But at Hathway, we don’t view QA as a final stamp of approval on a product, nor as a necessary stage of bureaucracy between development and end users. Why? Because if QA only comes in at the end of the process, it’s often too late.
Like the development process itself, the QA process should be early and agile.
Think about it this way: if you’re out in the snow looking at white all day long, you go blind because you can’t see anything except white. Similarly, if a developer spends all day looking at code, she’s going to mistype a variable name or forget a use case, no matter how good she is.
Quality Assurance is the everyone’s responsibility — to identify risky situations and address them before the project deliverables or timeline goes awry. Anyone on the development team can ask, “What about security?” or “Does this website platform support this feature?” but it takes someone with a QA mindset to insert knowledge from other projects and uncover issues that others might overlook.
Six Ways to Infuse the QA Mindset With Your Product Development
- Defuse the tension with transparency. In agency work, the QA role can create among developers, designers, and even account managers — especially when a timeline is aggressive and QA comes in at the very end of a project. In that scenario, the QA role can easily become the enemy. After all, no one likes answering to the “quality cop.”To prevent this from happening, be as transparent as possible. Copy everyone on relevant emails and if you get push-back, say, “I’m asking questions because I care about the quality of the project and want us all to be on the same page.” People will understand that because they want to deliver a great product, too.If you notice someone has closed or negative body language during a team meeting, encourage them to voice any concerns. It is especially important to draw details out from taciturn developers, as they are in the code and will have the greatest understanding of any technical limitations.
- Cover your bases with technology. Use bug-tracking software, and give everyone access to it. Left unchecked, bugs can quickly become a hidden backlog, stealing time that would be better spent on completing features. At Hathway, we use JIRA by Atlassian to manage Stories, Tasks, and Bugs in one place so no one forgets about an important bug fix before moving on to build a new feature. We also keep lines of communication open with project channels in Slack, where we can reference previous conversations, send links, and share files quickly with all team members.
- Make collaborative estimates. One person’s effort estimate of a requirement might be vastly different from another — especially if the estimators have no frame of reference for how long the task will actually take. You don’t want someone who isn’t performing the task deciding on a timeline, and you certainly don’t want the client to hear those discussions.One estimation strategy Hathway employs before starting sprints is Planning Poker. In this exercise, everyone on the project team gathers around with a deck of special cards and bids on how much effort they expect a task or feature to take. One team member might think a task is easy and will take less than a day, but the person performing the task might say it will take two weeks. Getting multiple perspectives helps to assign workloads appropriately and uncover potential risks before committing to deadlines.
- Watch out for assumptions. Get everyone involved and talking in the early stages of a project so people don’t make assumptions another side can’t meet. If a designer thinks a feature is easy because another team built it on another website or app, the developer needs to be there to point out that certain features might not translate well to certain platforms. Draw upon your experience in previous projects, and apply that knowledge to the situation at hand. Ask yourself, “Does XYZ typically go wrong on projects built on platform ABC?”
- Check your gut. Stay alert for missing or poorly defined requirements. If the client says “security” is important, dig deeper to find out exactly what that means to them: password encryption, SSL-certification, or something else? For example, if someone uses an acronym you don’t know, Google it. It might be industry-specific jargon you don’t know, or the client might be using a term incorrectly. (Pro tip: “MVP” stands for “Minimum Viable Product” not “Maximum Value Product”).
- Involve QA from the outset. I always appreciate when an account manager asks me to check details on a project before it ever gets started. For instance, if a proposed contract says we plan to support a website on Internet Explorer 8, I can tell the account manager that Microsoft is ending support for that version in January 2016; therefore, we shouldn’t include that browser version in new contracts. Use this general rule to guide your thinking: If clients are going to see it, run it by QA first. You might be surprised at what QA finds.
Keep QA involved in your processes from beginning to end. The QA team members shouldn’t be the bad guys who keep sending back “already finished” work to developers, only to find out the requirements were unclear (or worse yet, non-existent). QA should be part of the team from the start, ensuring the client gets a great product and saving everyone from the frustrations of problems that would otherwise slip through the cracks.