Tuesday, 26 January 2010 11:04

Requirements Driven Test Management

Written by
Rate this item
(3 votes)

According to the Standish Group's Chaos Report, 90% of IT projects are delivered late and 66% of them are not considered successful. Surveys show that more than 50% of the project failures can be attributed to problems stemming from Requirements Elicitation and Management and more than 20% are due to Ineffective Testing.

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.

Read 17736 times
Emrah Yayici

Emrah Yayici is the Author of the book: “Business Analyst’s Mentor Book: With Best Practice Business Analysis Techniques and Software Requirements Management Tips”.” In his book he explains best practices about business analysis, software testing, usability and user experience design with real-life examples from various industries. He also shares his consulting experience gained in multinational software development projects at BA-Works, Keytorc, UXservices, Arthur Andersen and Accenture companies.

Comments  

0 # Laxman Bista 2010-01-26 16:45
good article.
Reply | Reply with quote | Quote
0 # Rizwan Khurshid 2010-01-31 12:51
I really like the example you have given here and is very much true that if requirements are incomplete or inaccurate mostly likely your IT project will fail and/or will not fulfill the needs your customer was expecting. But I am suite concern that will people agree to implement the process of "Testing the requirements" and who will be the ideal candidate for doing this either stake holder or peer review? Given that every one is now trying to adopt agile methodologies and trying to cut the time spent on documentation and/or modeling.
Reply | Reply with quote | Quote
0 # John Talbot 2010-02-01 16:01
Thanks Emrah, I am a fan of Early testing, however it is described or done. I have found on a number of projects that the sooner one starts to produce test scenarios, whether from use cases or a statement of requirements, the sooner defects are found. At this stage they will be ambiguities in requirements or outright missing requirements. Within an agile context, the users would contribute to the test scenario construction and a defect found there would, if well managed, feed in to the backlog for an (objective) assessment of the defect.
Reply | Reply with quote | Quote
0 # Koray 2011-03-06 03:02
Very informative and helpful article for people who is seeking quality information about BA like me.
Reply | Reply with quote | Quote
+2 # Bill Echlin 2013-04-30 02:47
Early testing (when you don't have anthing physical to test) should involve peer reviews. The test team can make a huge difference when it comes to reviewing design specs, requirements and use cases. Not only does this review process help to teach the testers more about the product they are about to test but the testers can usually spot issues in design documents far better than anyone else (partly due to their impartiality and partly due to their experience). More about on the testers role in peer reviews here at test management.
Reply | Reply with quote | Quote
0 # Phillip 2014-02-21 13:04
Thank you for another wonderful post. The place else may just
anybody get that kind of info in such a perfect method of writing?
I have a presentation subsequent week, and I'm on the look for
such info.

Stop by my blog post: Become A Project Manager: http://gekikame.com/ntr/post-11326/
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250