1 / 23

Requirements Mapping

Requirements Mapping. Introduction. We have now looked in detail at both test requirements and test cases It’s obvious to testers that there is a very close relationship between requirements and testcases Maybe it’s too obvious to us……

dgrass
Download Presentation

Requirements Mapping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Mapping Amadori Course: Delivering Effective Test Management

  2. Introduction • We have now looked in detail at both test requirements and test cases • It’s obvious to testers that there is a very close relationship between requirements and testcases • Maybe it’s too obvious to us…… • Not enough for us to implicitly link testcases to requirements • Also need to explicitly demonstrate to stakeholders the relationship between our tests and their requirements Amadori Course: Delivering Effective Test Management

  3. Types of Test Requirement • Test Requirements can fall into one of 3 classes in terms of testability • Not testable – we cannot write testcases against this requirement • Partially testable – we can write tests against parts of this requirement but questions remain unanswered in other areas • Testable – we can write testcases against the whole of this requirement • Note: measuring progress against partially testable requirements can often be problematic • Can sometimes be better to split such requirements into their testable and non testable elements Amadori Course: Delivering Effective Test Management

  4. How to deal with non testable requirements • Where possible non testable Test Requirements should be ring fenced • Testing activity can then move on to foucus on other areas where progress is possible Amadori Course: Delivering Effective Test Management

  5. How to deal with non testable requirements • To make sure that non testable requirements do not get forgotten about until just before Go-Live…. • Raise an issue against the requirement stating clearly • What is required for the requirement to become testable • Who you believe is the person who is best placed to provide what is missing • The potential impact to the project of not testing this area • The issue can then be tracked as any other issue would and prioritised appropriately by project management Amadori Course: Delivering Effective Test Management

  6. Orphans • When mapping test against requirements you may end up with orphan tests or orphan requirements • Orphan requirements (requirements linked to zero tests) • May show a gap in coverage which needs to be filled with additional testcases • May also show that this requirement is not testable for some reason as you can’t actually write a meaningful test against it • Orphan Tests (tests linked to zero requirements) • In theory if you can’t map a test back to a requirement you don’t need that test • The existence of such a test may however show that a requirement is missing here and could be an issue to raise with stakeholders Amadori Course: Delivering Effective Test Management

  7. Why Mapping is important • In larger projects mapping requirements against tests can be a lengthy and complex process. • That is a strong argument for doing it however (and not the reverse) • If the mapping process was simple, we would be unlikely to miss much if we didn’t do it. Gaps in coverage are much more likely as the scope and complexity of the delivery increases • It is the ONLY way we can truly verify whether our testing covers the whole of the delivery or not Amadori Course: Delivering Effective Test Management

  8. Common Issues • Biggest issues tend to arise where the relationship between requirements and tests is many to many • Difficult to easily reflect that some requirements in the set may have more significance than others • Equally it may not be necessary to run every single testcase to confirm one or more of the linked requirements • Testers need to be pragmatic in interpreting the results of a requirements mapping exercise and careful about the way they report its results to project managers and stakeholders Amadori Course: Delivering Effective Test Management

  9. Measuring Test Coverage • Remember – test execution metrics are not the whole story Amadori Course: Delivering Effective Test Management

  10. Question • For example • Application A has 100 requirements • 75 are testable, 25 are not • Of the 75 testable requirements only 60 have testcases written against them • Testing goes well however and of the 60 requirements with testcases against them 57 are fully executed with no errors. Testing has yet to commence against the other 3 • What % test coverage has been achieved? Amadori Course: Delivering Effective Test Management

  11. Amadori Course: Delivering Effective Test Management

  12. Amadori Course: Delivering Effective Test Management

  13. Amadori Course: Delivering Effective Test Management

  14. Amadori Course: Delivering Effective Test Management

  15. Exercise • Work out test coverage metrics given the following scenario • How does the situation change if we consider only business critical requirements? Amadori Course: Delivering Effective Test Management

  16. Answer Amadori Course: Delivering Effective Test Management

  17. The Traditional View Amadori Course: Delivering Effective Test Management

  18. An additional benefit from mapping • If you map requirements against testcases and a requirement changes • Very simple to work out which testcases need to be revisited and possibly revised • On the other hand if you haven’t mapped requirements against testcases • you may have to review every single one of your tests assessing they might or might not be affected by the change Amadori Course: Delivering Effective Test Management

  19. How to deal with changing requirements…. • Remember the “spec” we worked through earlier • Having extracted requirements and written testcases against this document you discover at the very last minute that there are one or two small changes to be made here…. Amadori Course: Delivering Effective Test Management

  20. These are the changes • A new class of customer needs to be included in the report, consisting of customers with an average balance of more than £2,000,000 • The report also needs to show the highest and lowest balance of any customer in that period and not the lowest and highest balance of each customer as we had assumed • Two new graphs are required • Showing how the highest, lowest and average balance in each class at reporting date • Showing the highest and lowest balances of customers in each class at any point in the reporting period Amadori Course: Delivering Effective Test Management

  21. Questions….. • How many new requirements are there ? • Do any of the tests written against the existing requirements need to change? • Are any of the old requirements no longer required? Amadori Course: Delivering Effective Test Management

  22. Questions….. • How many new requirements are there ? • Do any of the tests written against the existing requirements need to change? • Are any of the old requirements no longer required? Amadori Course: Delivering Effective Test Management

  23. Conclusion • Mapping requirements against testcases is essential if you are to derive maximum benefit from your requirements analysis and test scripting • The mapping process will not only assist you in planning for test execution before code is delivered • It will also you to respond quickly when requirements change Amadori Course: Delivering Effective Test Management

More Related