Matrix The traceability concept is very important from the viewpoint of evidence. This is the document which maps requirements with test cases. By preparing Traceability matrix, we can ensure we have covered all the necessary functions of the application in our test cases.
What is the traceability matrix of Software Testing perspective?
* The Matrix concept of traceability is very important from the viewpoint of evidence. This is the document which maps requirements with test cases. By preparing Traceability matrix, we can ensure we have covered all the necessary functions of the application in our test cases. Some characteristics of the traceability matrix: This is a method of tracing each requirement from their point of origin, through each phase of product development and work for the product delivered
* Can handle through when the requirement arises, specified, built, tested, and delivered
* Is indicated for each product of the work of the obligation (s) for this product, the work meets
* Facilitates communication, helping to manage customer relationships and commitment to negotiation
Traceability Matrix is the answer to the following basic questions of any software project:
* How can we ensure, for each life cycle phase, which I had correctly accounted for all customer needs?
* How can I ensure that the final software product meets the customer needs? For example, I have a function that checks for invalid password I put in the password field of the application throws an error message "Invalid Password". We can only ensure that this requirement is included in the test case for the traceability matrix.
Some problems can be overcome by the traceability matrix-
To demonstrate to customers that the requested content has been developed
* Ensure that all requirements are correct and are included in the test plan and test cases
* Ensure that developers are not creating features that no one has requested
* The system is built may not have the functionality to meet customer needs and expectations and users. How to identify the missing parts?
* If there are changes in design specifications, there is no way to track changes
* If no mapping of test cases to requirements, can result in lack of a major flaw in the system
* The complete system can have "Extra", a feature that are not specified in the design specification, resulting in wastage of manpower, time and effort.
* If the component code is the highest priority needs of the client is not known, then the areas that need to be resolved first cannot be known which decreases the chances of transmission of a useful product as scheduled
* A seemingly simple request could involve changes in various parts of the system and whether the traceability process is not followed properly, the evaluation of the work that may be necessary to meet the demand cannot be properly assessed
Bit by bit action of making a demands traceability matrix-
Step 1: describe all requirements testable at the level of detail for different demands specs documents. These documents will vary from project to project. Typical requirements that you need to capture are:
Cases are used (all flows are captured)
Error Messages
Business rules
Functional Standards
SRS
FRS
Etc...
Demands e.g. access functionality, generate reports, update something, etc.
Step 2: Each project must be the creation of test cases to test the functionality as defined by the demands. In this case, you want to extend traceability to test cases. The following table example test cases are identified with a prefix TC_.
Put all the requirements in the top row of a spreadsheet. And using the right hand side of the sheet to record all test cases written for that particular requirement. In most cases, you will have multiple test cases that you've written to try one of the demands.
Step 3: Put crusade against each of the test cases for each requirement if this particular case, the test is to verify that the particular requirement in whole or in part. In the above table can be seen UC1.1 REQ1 is marked by three test cases. (TC1.1.1, TC1.1.3, TC1.1.5).
Another example of the traceability matrix in requirements documents (use case) are allocated back to the test cases.
Managing change through traceability matrix-
Will be much easier for you to track changes if you have a good traceability matrix in place. For example we know in advance REQ1 UC1.1 matrix traceability of test cases that I have to be modified to incorporate these changes. In the former case we must modify TC1.1.1, TC1.1.3 and TC1.1.5 only.
0 comments:
Post a Comment