The definition of test matrix alone speaks volume of its importance for the quality assurance task of a product.
Here is how I define a test matrix:
A test matrix is one of the most simple, useful, and powerful testing tools.
A test matrix is only a spreadsheet in which we simply put tests’ data such as test results in the form of a table. A test matrix is basically a checklist to ensure the successful completion of all major tasks. It helps in identifying specific defects and also contributes in refining our test strategies. In other words, it is basically a ratio between tests that are essential to run and number of items on which these tests have been performed.
The important thing to remember is that each sheet represents a collection of possible tests, and each intersection of the axes represents a single test from that collection.
Here are what go into test matrix sheets:
- Across the top, tested pages; down the side, test categories (link checks; content; basic structure of the pages, uniformity, HTML, CSS etc).
- Across the top, date of tests; down the side, specific tests.
- All browsers listed at the top with specific browser compatibility checks down the side.
Test matrixes are essential in the sense that they represent a complete test suite for a work product. In a test matrix, we generally record a product’s test case number with relation to its use case number. Then there is a test point, which refers to a specific feature, mentions its expected results, and then shows the actual results.
A defect log is maintained in which we log defects that are identified while testing a single matrix.
If a product defect is discovered after release, someone is going to want to know whether the test coverage was reasonable or not. The test matrix provides an excellent means of identifying specific tests that were performed (or not), and in the event of an investigation or legal action, can show that the test effort was thorough and reasonable.
There are different formats of making test point matrix, but I have designed my own table to record test points and their activities. Using it, I usually record following sets of data.
- Initiated By: This includes the name of the person who is recording this data
- Date: On which date this test is performed
- Resource: The resource who developed module that is under test
- Module: Name of the module on which this test is performed
- Sr.No: Serial Number
- Test Case Objective: The goal for a test case that we want to achieve after this activity
- Use Case ref.: The usecase number on which this test case is built
- Type: Nature of the test point
- Test Case ID: Test case reference from which this test point relates
- GUI Ref.: If there is any GUI reference. This is used when we test interfaces of an application
- DB Tables (Reference): The reference tables that can be effected during the test
- DB Tables (Input): The reference tables that take inputs during test
There are many QA professionals in our software industry who do not prepare such documents because they feel it is a time consuming job. But this is not merely data sheets filling. It has many other advantages. It can refine our QA process and also deals much with the quality of the work product. If we make it an essential part of our testing process, then it will help us a lot. Because in our field every single document has its own importance and it contributes whether directly or indirectly in the entire software development life cycle. There are many advantages like by using this approach we can identify all potential problems at the initial most stage. Also we can determine performance, reliability and correctness of our work product.
So in short, we should follow such practices because investing time in filling the sheets before the product hits the market will be far better than spending more time and money afterwards if there are problems.
To read more about services in QA and packages please visit our Quality Assurance page or click here.