The applications that you develop aren’t simply bits and bytes; they automate the most central processes that your business depends on. Application development teams are under pressure like never before – not only to develop new applications to meet business requirements but to address a mounting applications maintenance backlog and “IT debt.”
As Gartner pointed out in their recent report on IT Debt, there is now an extreme level of backlog of new requests coming from the business. In fact, Gartner has estimated that this debt has climbed to 500 billion dollars, and up to one trillion in a few years.
This pressure and this backlog has meant that applications are developed that don’t match the actual business needs of your clients. The complexity of business requirements, applications, and development environments increases the risk of poor quality outputs. This makes it difficult for you to:
Align with business goals
At the start of software development is an idea. But ideas are hard to translate into actions. So, the gap between what business users need and what development delivers can be wide. That is why the Software Engineering Institute estimates that 68% of software projects are unsuccessful – they simply don’t achieve what the business demanded.
One of the main indicators that the software delivery process is broken is rework. This rework is a problem not only because the software fails to meet business needs, but also because it steals resources from delivering more innovation.
When managers lack insight into the development and QA process, they cannot ensure that high-quality software is being delivered. This means that decisions about where to retest or invest in corrective action to fix defects can’t be made early and often.
How You Address the Challenge Means Huge Cost Savings -- or Expense
To address the challenge many organizations concentrate software testing at the end of development. That means that long after requirements have been set, test plans built, and development completed is when the code is finally tested. This leads to:
> Business quality issues because end-user requirements had changed over time and weren’t reflected in development or in test plans.
> Technical quality issues because development teams were under tight timelines, and defects naturally crept into the software.
> Poor communication means that changes in requirements weren’t reflected in the tests conducted and discovered defects were poorly monitored or linked back to the business priorities.
The result of this “correction cycle” is that errors are up to 100 times more expensive to fix. An effective best practice is to ensure that quality is “continuously” assured from the beginning of the development lifecycle. There are many ways in which a continuous approach to quality can be acted on. One key way is through enhanced requirements-driven testing wherein testing is tightly linked to the requirements defined for a project.
There are three key best practices that support enhanced requirements-driven testing:
1. Better requirements definition
It is notoriously difficult for business users to communicate needs to development teams. As a matter of fact, up to 70% of all production defects stem from this stage when requirements are poorly defined. Requirements come from numerous stakeholders that may be globally distributed and in a variety of formats. This is further complicated by the fact that users often don’t know what they want until they actually see it.
So, that leads to a wasteful cycle where development teams try to implement what they understood. This results in missing capabilities, unnecessary features, and – down the road – a lot of rework. And that rework quickly adds up, especially when issues are discovered late in the development process.