When we think about quality assurance best practices, we should be dividing these thoughts into two buckets. Best practices for the individual tester, and QA best practices as part of the wholistic Software Development Lifecycle (SDLC).
We’ll dive into QA best practices as part of the SDLC today, and circle back to best practices for the software tester next week.
In our article Redefining Quality Assurance: LyonQA's Holistic Approach to Software Development we emphasize that “Quality Assurance should be part of your product development ethos.” What does this mean? It means that quality should be considered and integrated into each stage of the SDLC. This might not necessarily mean having QA present in every meeting, but at a minimum ensuring a defined source of truth that is regularly updated, or having a designated test environment.
Here are some key best practices to assure quality:
One regularly updated source of truth: All too often, we hear excuses and justification for why teams forego documentation. “We don’t have time for that,” “our team understands how things work, we don’t need to right now,” or, the more honest answer, “it’s not a priority.” We get it, we feel it. But, a regularly updated source of truth ensures clarity among all stakeholders — QA, Dev, Product, hell, even Sales — about expectations and the rationale behind changes. While it serves as a helpful reference during sprints, its true value is seen when onboarding new developers, feature updates, and pre-release testing. The time that may be lost today as you update your source of truth will be paid back many times over.
Agreed upon Definition of Done: The DoD establishes criteria that a feature must meet for the team to deem it complete and ready for customers. By defining the DoD ahead of time and sticking to it rigorously, teams cut down on frustrations at release around different definitions of done. When practiced correctly, the DoD is well documented in your “source of truth.” Providing clarity to all parties. This shared understanding helps enhance collaboration, communication, and morale.
Standardized processes: In standardizing processes, each party knows what to expect of themselves and each-other, and knows when to expect cross team collaboration. This can go as low level as expectations for a code review & communication on how a ticket is passed or failed, or maybe you just start with defining what meetings are for what and how often they occur.
Moving QA upstream (Shift Left QA strategy): Shifting QA upstream means integrating a QA perspective from the requirement gathering phase, onwards. This not only enables QA to write test scenarios early, catch gaps in design, but also fosters collaboration among teams. When QA is able to work closely with Dev and Product, all parties are kept in the loop ensuring alignment on acceptance criteria from the getgo. With this, there are fewer surprises, and issues can be anticipated and addressed properly and on time.
UAT and Regression Testing: When thinking about your QA needs, it’s easy to think that your product only needs User Acceptance Testing (UAT), or only needs regression testing. If that’s all your budget allows, we get that, time and financial constraints are real. UAT detects issues specific to newly developed features, while regression testing ensures overall system stability. We recommend pairing UAT testing with regular regression testing, ensuring new feature development is tested throughout the sprint, with a high priority regression run at the end of each sprint to ensure the new feature didn’t lead to bugs in the existing code. This paired approach minimizes last-minute rushes, inefficiencies, and decreased morale as all parties are rushing to complete work.
Designated QA/Test Environment: QA needs to test in a stable environment, separate from the Dev’s active environment. This ensures QA is working in an environment more closely resembling prod, and one in which changes are not occurring regularly. This stable testing environment is key in ensuring bugs logged are easily reproduced and investigated. The last thing anyone wants is for Devs to spend time tracking down a bug that would have been resolved by the time it made it past the Dev environment.
Notice how much of what we discussed isn't just about QA, but about fostering teamwork, communication, and efficiency?
To truly boost quality assurance, teams need to embed a quality-first mindset into everything they do. Simply running UAT and/or regressions aren't sufficient for top-notch products. It's about instilling an ethos of quality across every development facet, elevating the quality of your product and your teams.
Comments