Overall, there is tremendous pressure we as QE leaders face to increase our go-to-market speed while not allowing for any degradation of quality. Our customers — whether internal or external — expect always-on rich applications that deliver superior total experience, and that expectation puts heightened demand on quality and automation teams to fulfill.
We need to think end-to-end velocity, or the speed at which our team — not an individual — delivers features to production. And to drive E2E velocity, we need a firm understanding of what gets in the way, as well as what enables us to generate faster momentum.
In years past, it used to be more challenging to arrive at true E2E because QE was more siloed. Development would throw code over the wall and then testing would begin; we were operating with legacy technologies that constrained our ability to automate; quality was bolted on, not built in; and a number of other factors.
But today, thanks to methodologies like Agile and Scrum, emerging technologies, automation solutions, and tighter business-technology alignment, we can drive E2E velocity at a greater speed without compromising quality and, in so doing, enable the business to compete more aggressively.
What Gets in the Way?
As we start to think about driving greater velocity, it’s important to first understand the warning signs that evidence when velocity starts to hit a roadblock.
There are always some usual suspects in that we will start to see issues with environments, data, and automation when velocity is at risk.
On test environments, for example, testing may be slowed down because of test environment instability, performance, or misconfiguration. Test environment management is trending due to the higher demand on environments to cover numerous testing phases and types. This flexibility is difficult under traditionally shared test environments but more achievable using cloud, containerization, and infrastructure as code.
On the test data side, test data setup may be tedious and manual or may not cover the required business scenarios. In some cases, a request for data to a third party or test data management (TDM) team is required which creates additional lead time. In addition, production data typically cannot be used directly for testing without data masking due to security and compliance requirements.
As far as automation, the issues have traditionally pointed to a lack of automated test scripts. In Agile delivery, test automation is a must. In addition to manual testing, manual processes can slow down not only test execution but test case design, creation, configuration, data, reporting, tool integration, processes, etc.
Warning signs are often seen when it comes to team velocity in terms of story points. Or you may notice your team is working overtime or dealing with a lot of unplanned work — all symptoms that there is an underlying cause that you need to uncover. Or you may see that your team is starting to cut corners and create technical debt.
All of these — and a number of other examples — are signs your velocity may be at risk.
What Shifts Us into High Gear?
One of the most powerful ways to strengthen E2E velocity is to embrace a Theory of Constraints approach. Rather than making too many assumptions about the bottlenecks or limiting factors impacting velocity, use a theory of constraints approach to subordinate your resources to find that constraint.
Here’s an easy way to think about the theory of constraints….
I recently went through airport security. The front process was optimized. They asked passengers to take everything out of their pockets and put certain items into bins and, as a result, people went through the scanner rather quickly. Where the bottleneck occurred was post-scanner when the security officials had to go through people’s bags and suddenly there was a traffic jam on the other side.
This small example demonstrates the theory of constraints, specifically that:
- You can’t just optimize one area as that won’t necessarily improve the whole team’s velocity
- Crowding and waiting are not good things; when these arise, the solution is to find that constraint — which in this case is the baggage check — and to get the whole team together to remove that constraint
In software development lifecycles, the Theory of Constraints works identically. To drive true E2E delivery, we need to identify constraints and subordinate our resources to improve and remove those constraints.
Related Reading: Are You Ready for QE 3.0?
The Theory of Constraints is one immediate way we as QE leaders can positively impact our teams, but I want to offer 3 more tips to augment your approach:
- Think Wider Responsibility: We need to make it our responsibility as QE leaders to identify and escalate issues expediently and we need to think more broadly as the issues may not be the usual suspects. Traditionally, we would identify defects and report them. But now we can go beyond testing and software defects and ensure high quality throughout the whole process. Things like collaboration with business users, requirements, estimating, and DevOps are now all part of our responsibility and, therefore, we need to think broader.
- Embrace Automation: This goes beyond just test automation. We need to embrace automation of the entire ecosystem. Today, we can automate so much more, from test management to data to traceability to reporting to deployments. The more automation the better and the more standardization of the process the easier to do automation.
- Optimize Processes: There are always better ways to optimize what we are testing and how we design those tests. When we think E2E velocity, we need to think optimization of our processes. For instance, rather than trying to test by executing 5,000 tests, there may be 500 tests that cover 99% of those cases. And because of the pressure on velocity, we want the best ROI in the shortest amount of time. As leaders, we need to always be thinking of how we can bring efficiency to the things we have traditionally done.
There is so much ability for us to drive speed and velocity in this era of QE, without sacrificing quality… more than we’ve ever had before. But the first, and most important place to start, is to think end-to-end and team-wide.
The causes of poor E2E velocity are many and multi-faceted. Click here to book time with Philip to explore how applying a Theory of Constraints methodology to first benchmark the “as-is” E2E pipeline and identify and quantify areas of product “stack-up” could move your QE department forward.
You May Also Like: