The test matrix shows the interrelationship between functional events and tests. The completed test matrix defines the conditions that must be tested during the test process to verify the proper functioning of the application system. It does not represent the totality of testing because there may be types of tests that verify the structure of the system, such as verifying the correct use of program statements that are not included in the test matrix.
The left side of the matrix shows the functional events and the top identifies the tests that occur on those events. Within the matrix cells are the process that needs to be tested. During requirements, the process may be generalized and vague, but it must become more specific as the life cycle progresses.
The example illustrated in Figure is for the functional event of an employee getting a pay increase. The tests have been selected because each test:
In the figure example there are nine identified conditions that must be tested to determine whether or not employees’ pay increases are processed correctly by the application system.
Let’s examine the nine tests to illustrate the conditions that must be tested:
1 • Initiate Event Action
This action creates the functional event which will eventually give an employee a pay raise. Within the matrix is the process that needs to be evaluated. The process is for the supervisor to complete Form X. The information on the matrix must be condensed. If we were working with the application we would know, for example, that Form X was the organizational form for initiating a pay increase.
2 • Increase Approved Action
After the supervisor has completed the form it must be approved by management. The test condition indicates that management will initial Form X. Our test process or test condition would then be designed to verify that procedures are established so that this will happen. Note that this and the previous action are manual actions.
3 • Data Entry Action
The information on Form X is entered into the computer through a key entry process.The test condition is to verify that the keyed information is correct. Since this is in the early life cycle stages, we may not know all of the detailed information that will be keyed in or the verification process, but even in requirements we could substantiate that the requirements include a process to verify the accurate entry of data into the computer.
4 • Form Storage Action
Form X needs to be retained until it is no longer of value to the organization. The test condition states that the form should be stored for 90 days in the personnel department. Again, our test process would verify that this is reasonable and that the system process provides for this condition.
5 • Data Entry Validation Action
The verification that the information entered into the computer is correct. The test conditions outlined in the matrix state that the application system should validate that the pay increase amount is numeric, and that the increase is less than $100.
6 • Logical Validation Action
The test suggests that additional validation determination will be made beyond the data values. Three test conditions are outlined as: 1) a logical check that the employee exists, 2) the pay increase will be within the pay range the employee is authorized, and 3) that the pay increase is within plus or minus 15 percent of the amount the employee was earning prior to the increase.
7 • Updated Pay Record Action
The pay amount increase should be added to the employee’s pay rate so that the pay record will properly reflect the new amount. The test condition is to ensure that the changed pay rate amount in the storage area is performed correctly.
8 • Audit Trail Action
A record should be maintained on the increases provided the employee. The action shows that the increase in payroll should be maintained on a history file.
9 • Report Action
The results of computer processing should be sent back to the supervisor as a confirmation process. The test condition is to verify that the system provides for such a confirmation.
This testing matrix would be typical of one prepared during the requirements phase. The functional events, as well as the actions, will be used throughout the systems development life cycle.
However, the test conditions will become more specific as the life cycle progresses. For example, there is an action indicating that data will be entered into the computer. During requirements, how that will occur may not be known, so that the test condition must still be generalized as Figure Testing Matrix shows. However, as the system progresses through the life cycle, the testing matrix becomes more specific. Eventually, the testing matrix will be expanded to the point where test transactions can be prepared from the matrix information.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
The left side of the matrix shows the functional events and the top identifies the tests that occur on those events. Within the matrix cells are the process that needs to be tested. During requirements, the process may be generalized and vague, but it must become more specific as the life cycle progresses.
The example illustrated in Figure is for the functional event of an employee getting a pay increase. The tests have been selected because each test:
- Represents the actions that must be performed on this functional event in order for the employee to get a raise .
- Represents a task that is performed individually.
- Can be associated with the individual responsible to perform that action.
- Is broad enough to limit the actions to a reasonable number .
In the figure example there are nine identified conditions that must be tested to determine whether or not employees’ pay increases are processed correctly by the application system.
Let’s examine the nine tests to illustrate the conditions that must be tested:
1 • Initiate Event Action
This action creates the functional event which will eventually give an employee a pay raise. Within the matrix is the process that needs to be evaluated. The process is for the supervisor to complete Form X. The information on the matrix must be condensed. If we were working with the application we would know, for example, that Form X was the organizational form for initiating a pay increase.
2 • Increase Approved Action
After the supervisor has completed the form it must be approved by management. The test condition indicates that management will initial Form X. Our test process or test condition would then be designed to verify that procedures are established so that this will happen. Note that this and the previous action are manual actions.
3 • Data Entry Action
The information on Form X is entered into the computer through a key entry process.The test condition is to verify that the keyed information is correct. Since this is in the early life cycle stages, we may not know all of the detailed information that will be keyed in or the verification process, but even in requirements we could substantiate that the requirements include a process to verify the accurate entry of data into the computer.
4 • Form Storage Action
Form X needs to be retained until it is no longer of value to the organization. The test condition states that the form should be stored for 90 days in the personnel department. Again, our test process would verify that this is reasonable and that the system process provides for this condition.
5 • Data Entry Validation Action
The verification that the information entered into the computer is correct. The test conditions outlined in the matrix state that the application system should validate that the pay increase amount is numeric, and that the increase is less than $100.
6 • Logical Validation Action
The test suggests that additional validation determination will be made beyond the data values. Three test conditions are outlined as: 1) a logical check that the employee exists, 2) the pay increase will be within the pay range the employee is authorized, and 3) that the pay increase is within plus or minus 15 percent of the amount the employee was earning prior to the increase.
7 • Updated Pay Record Action
The pay amount increase should be added to the employee’s pay rate so that the pay record will properly reflect the new amount. The test condition is to ensure that the changed pay rate amount in the storage area is performed correctly.
8 • Audit Trail Action
A record should be maintained on the increases provided the employee. The action shows that the increase in payroll should be maintained on a history file.
9 • Report Action
The results of computer processing should be sent back to the supervisor as a confirmation process. The test condition is to verify that the system provides for such a confirmation.
This testing matrix would be typical of one prepared during the requirements phase. The functional events, as well as the actions, will be used throughout the systems development life cycle.
However, the test conditions will become more specific as the life cycle progresses. For example, there is an action indicating that data will be entered into the computer. During requirements, how that will occur may not be known, so that the test condition must still be generalized as Figure Testing Matrix shows. However, as the system progresses through the life cycle, the testing matrix becomes more specific. Eventually, the testing matrix will be expanded to the point where test transactions can be prepared from the matrix information.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
No comments:
Post a Comment