Estimated reading time: 6 minutes
As teams move towards multiple releases per day, the pressure to deliver intensifies. The constant need for new features is typically coupled with tight timelines to meet user demands and stay ahead of the competition.
Engineering leaders strive for innovation, rapid iterations, and data-driven decisions. In this fast-paced environment, QA might be perceived as slowing things down. However, it remains an essential function, especially for ensuring that speed doesn’t come at the expense of quality.
QA plays a crucial role in ensuring that software delivers on its intended purpose by validating that it truly solves the user problems it was conceived to address. This unbiased assessment of the product’s readiness is essential to the success of any software solution.
Gatekeeper or enabler?
QA is usually thought of as the last hurdle before launching a product. The problem is, this often leaves QA looking like the ones holding everything up when it’s time to release.
Statements like “the user story is stuck waiting on QA to finish, development was completed a long time back,” or “QA found a last-minute bug, postponing the release” reinforces the perception of QA as a gatekeeper in the release process.
This mindset underestimates QA’s role as a proactive enabler of quality throughout the entire development lifecycle.
Active QA participation throughout the entire software development lifecycle enables QA to be an ever-present advocate for quality.
Other than the obvious benefit of earlier detection of issues, this approach also offers several other advantages like:
- Collaboration and shared ownership: Close-knit discussions during requirement refinement build a unified understanding of problems and feature expectations, minimizing misinterpretations. Jointly reviewing user-reported issues and deciding on actions accelerates resolution and cultivates collective responsibility.
- Providing a quality lens: Consistently viewing progress through a quality prism elevates standards across all project phases.
- Feature impact visibility: QA’s involvement in user feedback sessions and business impact analysis provides direct insight into feature performance and value.
If QA is only involved once the feature is ready to be tested it’s likely already too late. This means the focus is limited to the code under test and overlooks other important aspects where QA can have a positive impact.
Building a quality-first mindset
As engineering teams increasingly focus on speed and quick iterations, it’s crucial to promote a culture that prioritizes quality. This shift in mindset needs the participation of everyone involved, including leadership, product managers, developers, and QA.
Creating cross-functional teams that include individuals with varied skills and viewpoints can be an effective setup. With the goal of owning the complete lifecycle of product and features, this fosters a sense of shared responsibility for the success of the deliverable. When everyone actively thinks about quality in the team, it lightens the load on QA, enabling it to concentrate on overarching quality objectives, – like streamlining processes, and the overall user experience – instead of just verifying finished tasks.
Additionally, team members should be encouraged to share their success or failure stories in retrospectives. Sometimes how a bug was found is more interesting than the bug itself. Or how an innocent looking change caused a major crash can trigger interesting discussions. Guilds can be helpful for this purpose.
Addressing the tensions between speed and quality
Despite best intentions, conflicts can often emerge between the need for quick releases and the necessity of thorough testing.
Prioritizing speed above everything else can expose teams to the risk of fostering a culture where shortcuts are taken, resulting in subpar user experiences and an accumulation of technical debt.
Some common traps to avoid:
• The “2 days to go” syndrome: Features only being test-ready two days before the release deadline.
• The “I am now working on something else” problem: Developers moving on to newer features and not having enough time to work on bugs/issues/open questions from previous work items.
• The “This doesn’t require testing” fallacy: Underestimating refactoring or innocent looking changes.
Implementing processes such as peer reviews and buddying can help mitigate these risks. Having developers, PMs and QAs collaborate closely throughout the development process minimizes late-stage rework and makes quality considerations an integral part of the process, thus reducing the risk of quality being an afterthought.
Additionally, defining a clear Definition of Done (DOD), delivering smaller and testable code chunks for quick feedback, and frequent product demos can help teams strike a practical balance, whilst allowing them to course-correct quickly when needed.
Furthermore, teams can utilize automated testing to improve efficiency. This can help manage repetitive tasks, allowing QA professionals to dedicate more time to focus on exploratory testing and tackle more intricate scenarios. For example, including automated functional and non-functional test stages in your CI/CD processes at the Pull Request (PR) level can help immensely in identifying regression issues faster.
The learning curve
As much as leadership and product teams need to adapt processes and change the way they perceive QA’s contributions, there is certainly learning and adaptation needed from QA’s side to help facilitate an environment where quality and business needs thrive together.
The following areas can be helpful for building both functional and technical expertise:
• Product: Understanding the problem being solved and the business outcome, learning about the system under test down to its little nuances, and knowing the users being served can help QA bring a lot of perspective to ideation and refinement sessions.
• Deployment: Knowledge of how and where the product/application is deployed can help QA understand nuances of the live environment which can be leveraged for test design.
• Logs: Ability to analyze logs can help QA to identify potential root causes of the issues either faced internally or reported by a user – thus helping and expediting the resolution process.
• Data sources: Knowledge of the various data sources and how to connect/read from them can help identify patterns in product usage and thus in test design.
• Business metrics: Ability to read and analyze business metrics can prepare QA to make data driven decisions either while prioritizing bugs or determining the impact of a feature.
• Automation: Test automation and automation in general can help leverage machines for repetitive tasks, allowing QA to focus on more complex issues.
These can help move at a faster pace, establish a better understanding of the system, make data driven decisions, and communicate better.
Additionally, developing a practical understanding of concepts like feature toggles and canary releases can be useful as these are effective strategies to campaign and vouch for especially to navigate the challenges of a fast-paced environment.
Final thoughts
The role of QA in software development will always be essential. However, what’s expected of a QA specialist has evolved from merely a gatekeeping function to a significant contributor throughout the development process.
The need for QAs to continuously upskill and be technically aware, while still bringing a probing and curious mindset cannot be understated. The onus is on both the organizations and QAs to promote a quality-first mindset and find a good balance between speed and quality.
Delivering products and features without compromising quality is not just an aspiration; it’s a cultural shift that requires commitment from everyone involved. When QA is integrated effectively, valued, respected, and prioritized, it becomes an enabler for speed and quality to coexist.
