Six Keys to a Shift-Left Testing Quality Transformation
In the last 10 years I’ve worked with many clients that grasp the vision of what has become known as the Shift-Left Testing Quality Movement. Here, quality is engineered into a product from the start rather than tested at the end of the SDLC. While these clients understand the concept, they often lack knowledge of how to change their organization’s quality mindset to shift left effectively. Read the six keys to a successful shift-left testing quality strategy that has helped clients start the journey to quality success.
1. Build quality gates in your shift-left efforts
Creating quality gates is an easy way to start the shift-left movement. Most companies have some type of production quality gate that, in its simplest form, says “X% of all test cases must pass with less than Y critical priority defects.” You can push left from this production gate.
Next, you establish a build quality gate from development into the QA environment that says “If these smoke tests don’t pass, we will not accept the build.” This gate is critical if you are dealing with an immature development organization that knowingly throws bugs over the wall to the QA group.
This second gate is a major hurdle and tough to implement because of resistance from a dev organization that lacks a proper quality mindset. I always encourage QA managers to hold the line here because once that gate is established, they’ve made major inroads in shifting left.
2. Prioritize your scope
As easy as this may sound, I’ve worked with many companies that don’t prioritize their features or test cases. Establishing a priority scale for your test cases works wonders for executing plans and creating an objective standard for deployment quality. Start by asking yourself two questions:
What is the likelihood this data condition will occur in production?
What is the impact to daily business activities if this condition fails?
Next, you use a priority matrix to establish a business-priority-driven framework that guides all manual and automated efforts and helps you make well-informed quality decisions at release time.
3. Transform from quality assurance to quality engineering
This topic could be its own article, but I’ll just focus here on the quality engineer aspect of the QA to QE shift. A few key points:
Transform your QA team from bug finders to “quality advocates” - Elevate QA to a bigger role in the SDLC and quality engineering strategy, and build tighter collaboration via behavior-driven development (BDD).
Embrace the “three amigos” concept - The business, developers and quality engineer (QE) must work hand in hand during feature writing, development and testing. The QE ensures that a feature is written properly and that testing will satisfy acceptance criteria. He/she also works with developers to understand the technical approach, discuss acceptance criteria, testing approach, automation, and data strategies for that feature.
Build a culture where QE facilitates the overall quality strategy and becomes a collaborative quality gate throughout the delivery of a feature - This quality ownership throughout the process is vastly different from most QA mindsets where, too often, QA feels their role comes at the end of feature delivery, and they are told what to do and when.
4. Start automation strategies at the bottom
Most of the clients I work with who want to automate focus on the UI. At Applause, we believe that a proper automation strategy is built from foundational functional building blocks that start small and build up. You must have and maintain a focus on the desired end game; without this, most clients end up in an automation anti-pattern focused on end-to-end automated test cases that are constantly under maintenance and lead to little ROI. The agile test automation pyramid — unit tests/component tests; acceptance tests; GUI tests — outlines the ideal end game and has a high focus on automated unit and acceptance/API testing efforts, and less focus on automating large amounts of the UI.
5. Adopt an automation-first mentality
Automation is vital to any QE / shift-left strategy, and an automation-first mentality means you are planning on automation from day one. Most organizations I’ve previously worked with start from an “N-1 approach.” This means an automation team follows a sprint team and automates passed test cases after the current sprint is completed. However, with N-1 they are not set up for in-sprint automation and have started down a path that’s hard to change, soon finding themselves in N-5 or N-10 due to an automation bottleneck. To achieve the goal of in-sprint functional automation, it’s key to enable all team members to create and use automation and design test cases that are automation friendly. Some of the most advanced agile teams I’ve worked with couldn’t get to in-sprint functional automation for two main reasons:
Lack of collaboration between development and QE around automation hooks - Automation fails for four main reasons: QEs are not informed of automation hook changes; there is a functional defect; data is corrupted, or there are environmental issues. Generally, automation hooks or flow changes break automation executions and waste precious sprint time, forcing a manual execution and delaying automated efficiencies. Keeping developers and QEs in lockstep dramatically reduces wasted automation cycles and improves your automation progress.
Lack of a scalable automation solution - Finding a QE that has both functional knowledge and technical capabilities is difficult. Using an agile approach like BDD paired with a Gherkin automation framework enables you to scale automation across your organization and avoid relying on finding a large group of QEs with functional and technical abilities. This way, you can also retain your less technical, but highly functional, QE members and provide them with a means of creating automation in sprint such as codeless automation.
6. Create an ethos: quality is everyone’s responsibility
About five years ago, I witnessed a quality-first mindset at Amazon. The team had a profound focus on quality and not breaking the build. It was a way of life there. This experience was a poignant example of the fact that if you don’t start from the notion that quality is everyone’s responsibility, your overall shift left testing quality strategy will not achieve its full potential.
Immature quality organizations think that quality is QA’s job, or that QA certifies the quality of a release. Both beliefs put the onus of quality on the QA group even though their testing activities are usually relegated to the end of the release.
When you start with the notion that quality is everyone’s responsibility, you naturally start off on the right collaboration foot. This is a requisite for shifting left. To achieve the influence needed to do this, it’s critical to have a senior member of the engineering group as a quality evangelist to carry the message across all teams. It’s very difficult to shift left from a QA group perspective because the QA group typically lacks the necessary influence within the overall engineering group to drive that kind of change.
Access our on-demand webinar, Best Practices for a Repeatable Shift-left Commitment, for more guidance on changing your approach to quality, or see how Applause can help with In-Sprint Testing.
