This situation can be best explained with a simple analogy from nature. The software development lifecycle is like a river with requirements at its source. If you can't clean the river at its source, you will have a dirty river flowing down the hill. A reactive rather than a proactive approach to clean the river will increase the costs and risks exponentially. The proactive way to overcome this situation is by integrating Requirements and Test Management activities and formulating a Requirements Driven Test Management Process. To build a RDTM Process the following critical success factors should be in place:

• Early Testing. The testing activities should start in parallel to requirements definition without waiting for coding. Finding and fixing the requirement defects will lead to early prevention of flaws in design and coding process. Applying Early Testing as a principle will also have a positive quality assurance impact on business analysis activities.
• Use Case vs. Test Cases. In most of the projects, use cases are used as test cases. But these test cases only contain positive cases lacking forced error (negative) test scenarios which help in identifying most of the defects. In good practice approaches test cases should be prepared as a combination of use case scenarios and negative scenarios. Negative test cases are best developed by using test design techniques like equivalence partitioning, decision tables, boundary value analysis etc.
• Independent Test Teams. Positioning testing as a nice to have rather than a must have, last minute, additional task for developers or BAs resulted in incomplete and ineffective testing of applications. In order to avoid this problem, independent test teams with test automation capabilities should be established in organizations. Nowadays, CIOs are investing in Centers of Excellence for Requirements Engineering and Test Engineering teams as separate disciplines.
• Requirements Traceability and Test Coverage. The traceability matrix is a helpful tool to ensure that requirements have been met and all changes are addressed. By using traceability matrices, requirements can be referenced beside relevant test cases and test coverage ratio can be monitored at each stage of the project. Requirements coverage should be also used as a Key Performance Indicator for test teams and should be evaluated as test exit criteria.
• Requirements vs. Test Automation Tools. Requirements Driven Test Management necessitates the integration of requirement management and test automation tools. In the selection of test automation tools, the requirements coverage monitoring abilities should be a selection criteria, in addition to standard test case and bug tracking functionalities.

Beyond all the critical success factors discussed above, most companies require a paradigm shift in their culture to put requirements driven test management into reality.

-Don't forget to leave your comments below

Emrah Yayici is the Managing Partner of Ba-Works Business Analysis Services. He is the president of IIBA Turkey Istanbul Chapter. He has worked as a consultant for Arthur Andersen and Accenture on various international technology and management consulting projects. He studied Industrial Engineering and Economics in Middle East Technical University. He has published many articles and participated as a speaker at various conferences on business analysis and software testing. He is a strong supporter of business analysis and software testing professions and supports this vision with active roles in global and local non profit organizations.