The decision to "shift left" is a cultural choice. By integrating testing into development, you are declaring that quality is a fundamental value—and not an expensive afterthought that causes deadlines to slide for weeks.
Just one problem: Developers and QA use different tools. This makes sense from a functional perspective, but when you enter the shift-left mindset, you need tools that support communication, support automation, and enable all team members to perform their work as efficiently as possible.
Thus the question: Can you shift-left quality without changing your tools?
What shift-left really means
First, let's define our terms. Bringing quality earlier onto your development schedule typically means that:
- QA is involved in initial planning discussions
- Testers oversee minimal viable product features to evaluate requirements, function, and architecture
- Performance testing and functional testing are built into the development process
- Security is a priority from the start
These are noble goals, but in many organizations, each team has its own tooling, its own ideas about what's important, and its own metrics. How do you communicate ideas about quality, performance, and security if everyone is using different tools?
Different tools = waterfall methodology
If you're in a large organization, the number of teams and tools can add up quickly. Different methods of measurement compound the problem, leading to communication breakdowns that make it impossible to achieve the seamless collaboration that's critical to shifting left.
In fact, differences in tooling can make a supposedly agile methodology turn into a waterfall methodology. If tooling problems force the interface between dev and QA to employ a formal handoff, you've ended up using a waterfall methodology, whether you meant to or not.
In contrast, when everyone is using uniform technology, it is easier to communicate the current status and agree on next steps. Uniform technologies are also important for automation. Keeping your project on scope requires minimizing manual busy work, such as what occurs if your teams are constantly having to sift and interpret results from other teams' tools.
Optimize for quality
So how do you get everyone to use the same technology? First, it's important to acknowledge that there's never going to be a perfect solution that fully satisfies your developers, testers, and other technology teams. The closest your company can come is picking a set of tools that causes the least amount of friction, confusion, and breakdowns in communication between project stakeholders.
Next, remember that all technology teams on a development project are working toward the same goals: They're translating abstract user requirements, problem statements, and user stories into a functional piece of software that will solve their organization's or client's problems. What's important is making sure the tools support these goals.
The right tools don't demand attention
You may ultimately decide to switch your company's tools toward the systems that development is using. Conversely, you may shift almost entirely toward what your QA team is using. Or you may come to a middle ground, with the addition of some new tools to meet functional requirements.
Regardless of where you land, what matters is arriving at a place where results are more important than tools. The ideal outcome is one where you're no longer having conversations about tools at all.
You'll certainly encounter some snags, but you'll no longer waste precious time and mental energy on trying to understand what other teams are using or how it affects their perception. You'll no longer struggle to create automation and communication between two wildly disparate pieces of software that perform virtually the same measurement. Your tools will exist, but they'll be means to an end, not the source of continual conversation.
Fewer tools = more freedom
Being deliberate about your tools allows you to build quality into your process. As Dan McKinley says, "Mindful choice of technology gives engineering minds real freedom." Your technology matters less than your ability to effectively gather requirements, develop a high-quality product, and complete functional testing within project scope.
Is having the same tools absolutely critical? No, but anything you can do to make tooling more coherent across your teams will help you focus on quality.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
