Better Software - March 2008 - (Page 44)

tests in Excel or Word documents, you can create the same requirements structure in an Excel file. Once the requirements repository is created, we then use it as a frame of reference to establish traceability from the existing tests to related requirements. To perform this step, we take one regression test at a time and, based on our understanding of the test purpose, we make a decision about which software requirement this test is intended to validate. Then we link this requirement to the test. Depending on your test design, it is possible that a given test can be traced to more than one concern. We continue this activity until all regression tests are traced to their related requirements. After we have established traceability between regression tests and requirement, we can see exactly which concerns are covered and not covered by the regression test suite. ments from two perspectives: test coverage for each use case context and test coverage for each concern type (across all use cases). We measure test coverage for each use case context as follows: • Calculate the sum of all applicable concerns for a given use case context. This number represents 100 percent of concerns to be covered by tests. • Subtract from the sum the number of colored cells—i.e., concerns not covered by tests. • Calculate the ratio of covered concerns to the total number of concerns and present it as a percentage of requirements covered by tests. For example, the first use case context UC.1. Create Guest Reservation has a total of eight concerns. Two concerns, Data Dependency and Concurrency, are not covered by tests (see table 1); thus, the number of covered concerns is 8 - 2 = 6, which is 75 percent. We continue this calculation for all other use case contexts to derive the test coverage measurements. In doing so, we take into account all applicable concerns identified in the RCT. Hence, our test coverage measurements represent the coverage of the entire inventory of requirements. After we calculate coverage for individual use case contexts, we can derive the average number for the entire module, which is 37 percent for the 01. Front Desk module. To better analyze and communicate the assessment results, we can present them as a bar chart, as shown in figure 2, from which we can easily see which use cases are better covered by the existing tests and which ones are not covered at all and present test coverage gaps. In our example the gaps are: • UC.01.07. View, Update Folio Charges • UC.01.09. View, Cancel Message • UC.01.12. Manage Rooming List Test coverage from the perspective of concern types is calculated in the same way. As we can see in table 1, the Data Dependency and Concurrency concerns are not covered by tests. Finally, when we execute regression www.StickyMinds.com At this point, I need to clarify that assessment of test coverage is not the same as evaluation of test-design completeness for individual requirements. For example, you can create tests for all application features and achieve complete test coverage, yet some of the individual requirements still can lack necessary test cases. Hence, this RCT technique is primarily intended to support our analysis from three perspectives: 1. Identifying test coverage gaps 2. Providing testers with visibility into which requirements have more and which ones have less test coverage 3. Helping testers understand which types of concerns they commonly miss in test designs Based on the results of this analysis, testers can make better decisions about how to evolve their regression suite. From step 5 we already know which requirements are not covered by tests. We again use the RCT to measure test coverage and we mark the cells that represent not covered requirements with a different color (yellow, as in table 1). Then we can derive coverage measure44 BETTER SOFTWARE MARCH 2008 testing we always have limited time. This means that a test team should decide which of the software requirements are most important to validate and agree on the regression test scope. Commonly, validating core functionality is a minimal requirement for regression test coverage. In addition, testers might decide that some of the identified crosscutting concerns should be included in the regression test scope. Thus, when assessing test coverage, we can present the results as a range between covering only the core functionality and covering a complete inventory of requirements, including all crosscutting concerns. Then it will be up to the test team to decide how much regression test coverage is really necessary for their application. For the 01. Front Desk module, the RCT shows the range of the test coverage—37% ÷ 75%, where 37% is the coverage related to the entire inventory of requirements and 75% is the coverage of the core functionality only. When we have completed the assessment for all modules of the HMS application, the summary of results can be presented as shown in figure 3. A requirements composition table discussed in this article is a requirements analysis technique that proved to be effective on many projects where testers had little or no requirements. In this paper I illustrated how the RCT can be used for assessing regression test coverage. The other RCT benefits for testers include effective knowledge transfer when they start a new engagement, better functional test planning, more effective exploratory testing, etc. In addition, this technique can help developers better analyze and evolve software requirements on traditional, use-case driven, and agile projects. {end} Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. n Aspect-oriented software development http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.