Custom Search

Thursday, April 23, 2009

What is Traceability Matrix from Software Testing perspective?


The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases.



What is Traceability Matrix from Software Testing perspective?


The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases. Some of the features of the traceability matrix:
It is a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product


Can indicate through identifiers where the requirement is originated, specified, created, tested, and delivered Will indicate for each work product the requirement(s) this work product satisfies


Facilitates communications, helping customer relationship management and commitment negotiation


Traceability matrix is the answer of the following basic questions of any Software Project:
How is it possible to ensure, for each phase of the lifecycle, that I have correctly accounted for all the customer’s needs?
How can I ensure that the final software product will meet the customer’s needs? For example I have a functionality which checks if I put invalid password in the password field the application throws an error message “Invalid password”. Now we can only make sure this requirement is captured in the test case by traceability matrix.


Some more challenges we can overcome by Traceability matrix:
Demonstrate to the customer that the requested contents have been developed
Ensure that all requirements are correct and included in the test plan and the test cases
Ensure that developers are not creating features that no one has requested
The system that is built may not have the necessary functionality to meet the customers and users needs and expectations. How to identify the missing parts?
If there are modifications in the design specifications, there is no means of tracking the changes
If there is no mapping of test cases to the requirements, it may result in missing a major defect in the system
The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.
If the code component that constitutes the customer’s high priority requirements is not known, then the areas that need to be worked first may not be known thereby decreasing the chances of shipping a useful product on schedule
A seemingly simple request might involve changes to several parts of the system and if proper Traceability process is not followed, the evaluation of the work that may be needed to satisfy the request may not be correctly evaluated


Step by step process of creating a Traceability Matrix from requirements:



step1: Identify all the testable requirements in granular level from various requirement specification documents. These documents vary from project to project. Typical requirements you need to capture are as follows:Used cases (all the flows are captured)Error MessagesBusiness rulesFunctional rulesSRSFRSSo on…
example requirements: login functionality, generate report, update something etc.



step2: In every project you must be creating test-cases to test the functionality as defined by the requirements. In this case you want to extend the traceability to those test-cases. In the example table below the test-cases are identified with a TC_ prefix.Put all those requirements in the top row of a spreadsheet. And use the right hand column of the spreadsheet to jot down all the test cases you have written for that particular requirement. In most of the cases you will have multiple test cases you have written to test one requirement. See the sample spreadsheet below:


Sample traceability matrix


step3: Put cross against each of the test case to each requirement if that particular test case is checking that particular requirement partially or completely. In the above table you can see REQ1 UC1.1 is checked by three test cases. (TC1.1.1, TC1.1.3, TC1.1.5).
Another example of traceability matrix where requirement documents (use case) are mapped back to the test cases.

Database Testing: Five Key Elements

Programs that interact with databases have common elements, and testing each requires a different approach. These elements include
1. Mapping application layer interactions
2. Mapping the data layer interactions
3. Functional interactions between the application and database
4. Embedded code
5. Database Migration


Mapping application layer interactions are often more easily handled through the normal segregation unit testing techniques; mapped objects can often be replaced by stubs. When testing larger subsystems, databases stubs may be useful, although the existence of integrated databases and in memory databases reduces the need for them.

Mapping the data layer interactions often benefit from using a real database of any kind. Differences in behavior between different types of target databases can be identified or verified prior to integration. Run of cases, this needs to be available to each developer. These days, a multi-processor desktop has more than enough power to run multiple virtual machines hosting "real" databases such as Oracle, Microsoft SQL Server or Sybase. For the consistency check of the base mapping layer, which is usually sufficient to use something like SQLite.
No development work should never be done against the production database. This is a recipe for disaster. Mistakes can easily destroy data production successfully withdraw amendments to the database from a known state, which has the potential of automation to the ruine. If a problem can not be replicated in the development or quality assurance, which suggests that something is wrong with the development and quality assurance resources.

Functional interactions between the application and the database are processed using real databases. As mentioned earlier, VM is useful for this. Indeed, I know that several organizations in which a reduced version of the entire production network runs on every PC developer. In the coming years, we can expect this kind of comprehensive simulation environment to become more frequent.

Embedded code refers to code that runs in the database. Triggers and stored procedures are most commonly used types of embedded code. The only way to test this code with a database directly.

Database migration must be tested against the target databases. Migration should be tested against both the patterns and realistic data sets.