Today’s software development teams don’t just have to row in the same direction, they have to row as one.
But it’s not uncommon for developer and quality assurance (QA) teams to live on opposite sides of innovation and modernisation. While emerging development methodologies like Agile and DevOps tend to become predictors for trends in general business strategy, QA teams are often starved of innovation and siloed from the processes they affect.
While everyone who touches the software development life cycle (SDLC) wants to move fast and deliver quality, the tradeoffs between the two can cause tension which can be tricky to manage however. And while this can get the project to market fast enough and cover risk enough, it means that no-one is advocating for the success of the project as a whole.
In today’s world of continuous integration and continuous delivery (CI/CD) to meet high customer expectations, ‘enough’ isn’t really ‘enough.’ To implement Agile processes, DevOps methodologies, or simply better ways of working, enterprises must find ways to unify the efforts of Dev and QA as a singular product team. With a shared goal and process for collaboration, they can drive speed, quality, and revenue that gives the broader business a sharper edge in the market.
However, new mindsets always outpace new tools to facilitate them. Legacy tooling isn’t built to accommodate a collaborative model. While rudimentary solutions like spreadsheets and wikis can provide a neutral ground, they can’t provide a common ground. They can’t scale, and they end up creating more work, more frustrations, and more issues for both teams.
Working this way leads to no sense of success for the product as a whole and nobody is working together. Working with a shared goal and process for collaboration on the other hand can drive speed, quality, and revenue that gives your broader business a sharper edge in the market! Sounds good, right?
Here we delve into the symptoms of developer / quality assurance misalignment and discuss how teams can work as one for better products, faster.
Life beyond the spreadsheet
Test management is a tricky endeavour in its own right, especially if testing teams are siloed and use a multitude of tools and frameworks. Though at first glance it might seem easier to pop open a shared spreadsheet and start working immediately, spreadsheets don’t scale – they sprawl. Updating, maintaining, and trawling spreadsheets can become a full-time job, especially when compiling reports on project status. They actually detract from the very visibility, clarity, and communication they are supposed to enable.
A byproduct of good collaboration is less work for Dev and QA teams, not more. If safe, secure, and effective testing is important for your organisation, it might be time to consider a test management solution beyond the spreadsheet that can provide more scalability, traceability and security for your business.
Teamwork makes the dreamwork
Without a QA team, the responsibility of testing falls either to the Dev team or to an outsourced QA vendor. An outside QA vendor adds complexity and an entire set of priorities that have nothing to do with the success of your enterprise. When Dev is responsible for QA, it distracts them from their own work.
The goal of Dev/QA collaboration isn’t to enable both teams to do both jobs, but to do their individual jobs in a way that is conscious of the other. QA can create tests that more accurately validate the Dev’s code, while Dev can build quality measures directly into their workflows.
By creating project-specific teams that include both developers and testers, they become accustomed to working closely together, build an understanding of their individual roles and how they can benefit one another, and how they contribute to the success of the project and the businesses as a whole.
Fixing test planning
Formulating a test plan is a massive endeavor that can take weeks or months, but it’s something that can become useless almost instantly as iterative changes alter the nature of the project and therefore the trajectory of testing. Down the line, the test plan will be the mechanism by which teams are held accountable however, even though by then, the test plan will be severely divorced from reality
In an Agile, CI/CD environment, the test plan continues to exist as a living document after its initial approval. This requires Dev, QA, as well as other subject matter experts and stakeholders, to regularly review the test plan, adjust it, and agree on it. In order to execute to meet larger goals, teams must therefore find a better way to create and regularly review a shared plan.
Bringing stakeholders together from the outset
In yesterday’s Waterfall world, technical requirements delivered incredible specificity. Today, the end product is less certain from the outset. Technical requirements are a balancing act. They must be explicit enough to align teams to the end goal, but forgiving enough that iterative Agile fluctuations don’t derail the project completely.
Therefore, technical requirements tend to be lacking. If teams are siloed, vague requirements deteriorate even further as they pass from business analysts to product owners to Dev teams and, finally, to testing. This means that by the time the build gets to testing, the QA team doesn’t know why they are testing what they’re testing, so tests may not support the requirements or reach adequate risk coverage.
Similar to the test plan, technical requirements can’t be an afterthought, and they can’t fall out of view as soon as they are approved. They must be well-understood by all stakeholders and positioned as a central driver of the project. Teams must enable a central touchpoint that brings all stakeholders together at the onset of the project or sprint — including the QA team. When the QA team is brought into the conversation earlier, it can “shift-left” testing and create tests that more accurately validate the build’s intended value.
Using data to find common ground
Two inconvenient truths often stand in the way of Dev/QA alignment. QA can’t test everything and Dev can’t fix every bug.
So if we accept that a 100% bug-free release is impossible, the challenge becomes the prioritisation of which tests to run and which bugs to fix. But establishing go/no- go decisions requires data. Without that Dev and QA are forced to make their own assumptions about which aspects of the release are most important.
Both teams want to move faster, reduce risk, and ship a higher quality product. But when forced to assume, they may disagree on the tradeoffs in speed, risk, and quality that culminate in the final product. For Dev and QA to truly function as one, teams must not only align to the end goal, but to the priorities of the build that manifest that goal.
The ROI is clear
Fostering Dev/QA collaboration will only become more pivotal in a world leaning more and more heavily into DevOps. For all our technology, the problems we face are still remarkably human. Removing the QA bottleneck and enabling speed at an overall lower total cost of ownership comes down to two things:
- Reaching and maintaining alignment around the goals, priorities, and processes of a project.
- Doing more of what matters most rather than getting bogged down in spreadsheet sprawl, tool hopping to compile test results and other tedious manual processes.
This can deliver dividends. A clearer understanding of requirements and priorities can shorten testing cycles, while better informed go/no-go decisions can eliminate hypercare costs. Streamlined workflows let you do more with existing staff, and reduced total cost of ownership (TCO) around test management scales innovation without scaling costs. By minimising bugs and catching issues sooner, development costs are reduced.
When Dev and QA work as one, better products can be shipped faster, and with greater confidence. This sharpens an organisation’s edge in the market, leaving it poised to seize upon the next critical opportunity.
About the Author
Suhail Ansari is CTO at continuous automated software testing company Tricentis. Tricentis is a global leader in continuous testing and quality engineering. The Tricentis AI-powered, continuous testing platform provides a new and fundamentally different way to perform software testing. An approach that’s totally automated, fully codeless, and intelligently driven by AI. It addresses both agile development and complex enterprise apps, enabling enterprises to accelerate their digital transformation by dramatically increasing software release speed, reducing costs, and improving software quality. Widely credited for reinventing software testing for DevOps, cloud, and enterprise applications, Tricentis has been recognized as a leader by major industry analysts, including Forrester, Gartner, and IDC.
Featured image: ©Tomasz Zajda
