·Size of Software: Software size means the amount of functionality of an application. The complete project estimation for testing depends on determining the size of the software. Many methods are available to compute the size software.
Widely used methods are:
o Function Point Analysis
o Use Case Estimation Methodology
· Requirement review: Software Requirement Specifications (SRS) should be obtained from the client before starting measurement of software testing process. This SRS should be:
o Complete: A complete requirements specification must precisely define all the real world situations that will be encountered and the capability's responses to them. It must not include situations that will not be encountered or unnecessary capability features.
o Consistent: A consistent specification is one where there is no conflict between individual requirement statements that define the behavior of essential capabilities and specified behavioral properties and constraints do not have an adverse impact on that behavior.
o Correct: For a requirements specification to be correct it must accurately and precisely identify the individual conditions and limitations of all situations that the desired capability will encounter and it must also define the capability's proper response to those situations.
o Structured: Related requirements should be grouped together and the document should be logically structured.
o Ranked: Requirement document should be ranked by the importance of the requirement.
o Testable: In order for a requirement specification to be testable it must be stated in such manners that pass/fail or quantitative assessment criteria can be derived from the specification itself and/or referenced information.
o Traceable: Each requirement stated within the SRS document must be uniquely identified to achieve trace ability. Uniqueness is facilitated by the use of a consistent and logical scheme for assigning identification to each specification statement within the requirements document.
o Unambiguous: A statement of a requirement is unambiguous if it can only be interpreted one way. This perhaps, is the most difficult attribute to achieve using natural language. The use of weak phrases or poor sentence structure will open the specification statement to misunderstandings.
o Validate: To validate a requirements specification all the project participants, managers, engineers and customer representatives, must be able to understand, analyze and accept or approve it.
o Verification: Requirements specification requires review and analysis by technical and operational experts in the domain addressed by the requirements. In order to be verifiable requirement specifications at one Practical Measurements for Software Testing level of abstraction must be consistent with those at another level of abstraction. Review efficiency can then be computed.
Review efficiency is a metric that provides an insight on quality of review and testing conducted.
Review efficiency = 100 * Total number of defects found by reviews / Total number of project defects
High values indicate an effective review process is implemented and defects are detected as soon as they are introduced.
· Effectiveness of testing requirements: Measuring the effectiveness of testing requirements involves;
o Specification of requirements & maintenance of Requirement Trace-ability Matrix (RTM): Specification of requirements must include;
· SRS Objective
· SRS Purpose
· Interfaces
· Functional Capabilities
· Performance Levels
· Data Structures/Elements Safety
· Reliability
· Security/Privacy
· Quality
· Constraints & limitations
Once the requirements have been specified and reviewed the next step is to update the RTM. The RTM is an extremely important document. In its simplest form, it provides a way to determine if all requirements are tested. However, the RTM can do much more. For example,
In this example, the RTM is used as a test planning tool to help determine how many tests are required, what types of tests are required, whether tests can be automated or manual, and if any existing tests can be re-used. Using the RTM in this way helps ensure that the resulting tests are most effective.
o Measuring the mapping of test cases to requirements: While we map the test cases to corresponding requirements, we must first determine the following:
· Number of requirements it tests
· Priority of requirement it tests
· Effort for its execution versus coverage of requirements
Here, the number of requirements it tests and the priority of the requirements can be obtained from the Software requirement specifications (SRS). We should see that every requirement has a set of test cases mapped to it.
