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.

Eliminate waste

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.

Control development

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.

Visual business scenarios are an effective means of communicating business process flows and concepts. Process visualization coupled with simulations helps reduce ambiguity and for most stakeholders, presents an instantaneous way to recognize sequencing issues, broken decision points, missing process steps, and opportunities for innovation – all of which are easily missed when you are limited only to a text based approach to describing business concepts and processes.

2.       Tests that align with requirements

Effort put into defining the paths that users can take within an application is a wise investment because this information is used to create test cases for each path.  With the ability to calculate the magnitude of requirements risk and complexity, QA staff can identify high risk areas in an application and in doing so help set testing priorities.  This in turn ensures that effort is effectively spent and not wasted on over or under engineered functionality.

Generating tests cases directly from requirements also means that QA staff becomes active participants in the development process from inception and not as an afterthought.  By doing this, you create an environment where test planning and effort estimation can become much more realistic.  And they become more accurate, because they have been validated early in the process.

3.       Managing the process

A best practice necessitates close connection between your testing and requirements tools.  That synchronization allows both business analysts and quality assurance personnel to be stay connected even as plans and priorities change.  New requirements can be used to generate new cases. Those test cases should be added to test plans along with traceability links to ensure that impact analyses can be effectively conducted. This lets managers spot where test coverage has been lost.

Changed requirements can be modified in accordance with new refinements to business logic.  And requirements that are de-scoped can be removed from the testing plan to keep it always current. This traceability also applies “end to end” to include linkages to changes, tasks, and even code. This ensures that even as requirements change, test plans are synchronized and risk points identified.

Development is about delivering applications that the business needs.  So, how do managers ensure that the software that they plan to release is indeed ready? Managers need visibility into application quality as it moves from inception to delivery.  Are defect rates declining below mandated thresholds? Managers must know the answers to these questions before giving a release the green light and in order to make the complex development process more predictable.

So, you should investigate a centralized quality management platform.  Managers can monitor via dashboards the readiness of an application.  They can track and trend risk exposure, defect rates, change volatility, and other management tasks.  You should also be able to integrate information and the ability to control diverse test assets from across tools, from across methodologies, and from across teams to ensure coverage.

Conclusion

Requirements-driven testing helps drive high quality software that the business needs.  To do so, however, necessitates an effective approach.  By visualizing and simulating requirements, you gain more accurate understanding of business needs.  By generating test cases directly from requirements you accelerate and increase the accuracy of the testing process.  And by linking test management to requirements you ensure control over go/no-go decisions.