Your QA Process Should Be Continuous, Not a Final Step
QA is an important part of any successful software project in which the application and its full functionality are put to the test. Through this process, behaviors are checked, bugs are squashed, and the overall quality is given a final sign-off by everyone involved.
But how can you maximize the value of this critical project component if you’re a small team without a dedicated QA staff?
At Envy Labs, we know a thing or two about being small and what it looks like to launch with limited QA resources. We’ve found that the best QA process requires an integrated approach in which all team members share the responsibility.
How Communication Breakdowns Result in QA Issues
Typical project processes follow a tried-and-true format. First, research and discovery, followed by design and development, before final handoff to the QA team for testing before launch. This approach of using dedicated QA specialists outside of the implementation disciplines works well for many reasons:
- They are able to provide superior reviews because they are experts in all things QA-related
- A dedicated QA team means having a fresh set of eyes and an unbiased outside opinion to help you build the best product
- Because they aren’t directly involved in the implementation, the threat of these team members being beholden to sunk cost fallacies (the act of continuing an fruitless endeavor simply because time or resources have been invested previously) is greatly reduced
However, the tradeoffs of utilizing these late-stage project specialists are also worth noting.
There are a number of handoffs that must occur before all is said and done because software projects are comprised of multiple overlapping disciplines. Whether it’s from strategy to implementation, or from design to development, each handoff introduces the potential for expectation gaps to occur.
These expectation gaps are often the result of communication breakdowns among team members at critical handoff points. Just think of it as a game of telephone, except in this case, you’re communicating a message that might have to do with the intended functionality of an important feature. Each handoff introduces the potential for the final message to be further misconstrued. As a result, gaps in communication manifest in the form of issues discovered during QA.
This is where the downside of employing a dedicated QA team lies. By adding another team, you introduce yet another handoff and with it, the potential for additional communication breakdown.
The Best QA is Continuous, Not a Final Step
Fortunately, there is a different approach to QA that yields excellent results and doesn’t require a dedicated team. An approach that aligns with our belief that QA isn’t just a final step, but instead, a continuous process that touches every project phase, from discovery to launch.
By taking this approach, all team members (clients included) play an important role, shifting responsibility from that of a dedicated team to the larger whole. Best of all, adopting integrated QA keeps costs low, team engagement high, and budgets and timelines on track.
So how does this play out in real life? For us, it’s a two-part system that’s seamlessly interwoven into every project phase:
- During Discovery: A documented and agreed-upon set of product features forms the basis for all work to come and details the criteria for final acceptance
- During Implementation: Structures are put in place that elevate QA from an afterthought to an integrated piece of the project puzzle
How Envy Labs Maximizes the Value of QA Without a Dedicated Team
An integrated QA process requires a streamlined approach. The following details the steps we take to achieve a successful outcome.
Documenting Features During Discovery
Getting the most value out of QA starts long before the final pre-launch review process ever begins. If your goal is to maximize QA’s value during your project (spoiler alert: it should be), then you should first put together a well-documented set of features prior to any work being done. This document is extremely important and both the project team members and the clients should agree on its contents.
Having a document like this is vital because it lays the groundwork for everything to follow. It serves as a reference point for everyone involved, helping project team members know exactly what features need to be implemented and how they should function. This effort often raises previously-unasked questions and highlights important-but-missing functionalities far before they become deadline-breaking surprises.
As an added benefit, having an agreed-upon set of features helps manage client expectations and protects against the dangers of scope creep, a common threat to custom software projects.
There are a number of ways to produce this document. It could be a written wiki that is updated consistently as the project progresses, GitHub Issues that bucket and define core features, or some mystery option number three. The most important thing is that you make its creation a top priority.
Furthermore, to ensure this document remains relevant over the course of the project, document features in a way that all project disciplines will be able to understand, act upon, and provide feedback on during implementation. When done well, this document will not only provide guidance for the implementation phase, but also the details surrounding what’s required for a feature to be considered complete. This acceptance criteria will be critical during pre-launch reviews.
Integrating QA During Implementation
The implementation phase offers the greatest opportunity for integrated QA. As the product begins to take shape through design and development, incorporating things like automated testing and staging environments plays a significant role. Having these structures in place from the jump facilitates early and often reviews in a real-world setting while also ensuring quality standards are consistently being met.
For example, Google’s Lighthouse is a great way to continuously check the overall quality of your product based on audit metrics like performance, accessibility, and SEO. Using Prettier standardizes code formatting, promoting styling consistency within the codebase. And implementing continuous integration services like CircleCI and TravisCI to run test suites guarantees every line of code committed meets functionality requirements.
The insight gained from persistent testing is valuable in that it reveals both the things that work well and those that need improvement long before launch. Yet perhaps the greatest value these tools offer is their ability to offload the work involved with these necessary yet potentially time-consuming tasks. As a result, team members are freed up to focus on the most important work at hand.
Throughout this phase, focusing on and releasing specific features at a normal cadence rather than working on everything at once unlocks the potential for more meaningful iteration. When you break down work into digestible chunks and release with greater frequency, you’re better able to make the small tweaks that equate to huge improvements down the line.
With this approach, QA becomes a largely collaborative process among team members, creating a system in which every participant shares the responsibility of producing a successful product. Each team member must ensure that all pieces are working together as expected, errors and inconsistencies are noted and addressed, and that quality standards are being met.
How To Review
A careful review of all views and features is essential. It is important to walk through flows in their entirety to ensure there are no gaps or dead ends in addition to checking for visual correctness and quality.
Throughout this process, keep a running list of anything and everything that needs to be addressed. Though it’s tempting to overlook minor things, any error, even those that seem insignificant, should be noted.
Here are some of the most important QA issues to look out for:
Does the product function as expected? Answer this baseline question through thorough testing and confirm via the acceptance criteria laid out during discovery. Take time to walk through major flows and reveal any areas where incorrect or incomplete functionality must be addressed. As an added bonus, this process may also unveil opportunities for functionality or ease-of-use improvements if timelines and budgets allow.
Oversights and Edge Cases
Assuming functionality has met the acceptance criteria detailed in the documentation, are there UX/UI shortcomings that should be addressed? This may include UI inconsistencies like missing empty and active states or confirmation and error messages. Perhaps there are fragile development patterns that could be revisited and improved upon?
Additionally, it is not uncommon to find that when you begin implementation, those pixel-perfect approved designs don’t look so perfect anymore. This becomes especially apparent as you replace placeholder data and copy with more accurate information. For example, what happens when the placeholder username John Smith is traded for something like Chimamanda Ngozi Adichie? This is just one example of the types of important questions that should be noted and addressed.
Excellent functionality should be a core focus of any software project. Yet this is only a piece of the puzzle in determining overall quality and end-user satisfaction. QA should never just stop short at “it works.” Instead, place just as much emphasis on ensuring internal quality standards are met. We include:
- Producing high-quality visual assets
- Adding polish and delight with thoughtful animations
- Making sure user flows are obvious, intuitive, and complete
Throughout the review process, noted QA issues should be translated into actionable tasks before they are addressed. For this purpose, we’ve found that GitHub Issues work best. Like most traditional ticketing systems, GitHub Issues provides a means for creating tickets using text and images. Beyond that, we also take advantage of many other features to ensure they are documented in a way that is easily understandable for all team members. For example:
- Labels are useful for categorizing and setting priority levels.
- Assignments ensure no issue goes unaddressed and that team members are always aware of where their responsibilities lie.
- Checklist formatting makes presenting and visually tracking the progress of punch list items a breeze.
Finally, once you have noted and properly documented all issues, the work begins to make all things right. Make it a point to keep the lines of communication as open as possible. Encourage team members to pair as needed, and combine their shared knowledge to resolve issues in an efficient manner. Many times, this also involves bringing clients onboard to exercise their anticipated flows, answer questions, and make last-minute decisions as needed.
Through integrated QA, automation, and ongoing collaborative review, you create a continuous QA environment in which all team members play an important role. Best of all, with this approach, staging can be transitioned to production without much fanfare, resulting in a stress-free launch.
Taking an integrated approach to QA is an excellent alternative to working with a dedicated QA team. Despite the tradeoffs that come with not employing QA specialists, using the methods discussed above enable you to reap many benefits even with a small team and limited resources.
Because software development projects never go exactly as planned, we communicate with the client about risks early and often.