Quality Assurance and Project Management

Mar 2 2009   9:59AM GMT

10 golden rules for Requirements Based Testing

Jaideep Khanduja Jaideep Khanduja Profile: Jaideep Khanduja

10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.

9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.

8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.

7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.

6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.

5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.

4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.

3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so at least the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).

2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.

1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.

4  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Prashanti
    Very good analysis of how the requirements and the related testing go in tandem.Validation of the requirements is an often neglected aspect and the companies pay the price later on. The methodical way in which the requirements and testing are related in this post makes me bring to your notice the test design and test data tools available at [A href="http://www.testersdesk.com"] The design tool box has the pairwise, n way,t way, subset combinations and boundary interactions generator which can be of great help in testing the requirements. For test data there is a different tool kit altogether. These tools as a whole can be used in testing to ensure high quality requirements Prashanti Product Consultant ValueMinds – Makers of [A href="http://www.testersdesk.com"]www.TestersDesk.com [/A]– The Online Tool Platform for Software Test Design and Test Data Generation.
    0 pointsBadges:
    report
  • jaideep
    Thanks Prashanti, Very true the requirements analysis is the bulkiest cause of software projects delays or failures. Just for system sake the requirements are taken or documented and project teams start working on those requirements. The whole system goes haywired if the requirements are not validated right in the start. I found the link, "testerdesk" quite interesting. I would definitely push my testers to hook on to it for the help in testing. And for sure the tool(s) based testing has always an edge over the manual testing but point of caution is if the tool is used wisely with full understanding of what I intend it to deliver it to me.
    30 pointsBadges:
    report
  • MosesRozario
    Very informative article. Thanks a ton!!!
    0 pointsBadges:
    report
  • Jaideep Khanduja
    Thanks Moses
    9,285 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: