|
Glossary of Software QA/Testing
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Recovery/error testing
Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Disaster recovery testing
"Disaster recovery testing" is testing how well a system recovers from disasters, crashes, hardware failures, or other catastrophic problems.
Compatibility testing
Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.
Comparison testing
Comparison testing is testing that compares software weaknesses and strengths to those of competitors' products.
Acceptance testing
Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production.
The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.
Reliability testing
Reliability testing is designing reliability test cases, using accelerated reliability techniques - for example step-stress, test / analyze / fix, and continuously increasing stress testing techniques - AND testing units or systems to failure, in order to obtain raw failure time data for product life analysis.
The purpose of reliability testing is to determine product reliability, and to determine whether the software meets the customer's reliability requirements.
In the system test phase, or after the software is fully developed, one reliability testing technique we use is a test / analyze / fix technique, where we couple reliability testing with the removal of faults.
When we identify a failure, we send the software back to the developers, for repair. The developers build a new version of the software, and then we do another test iteration.
Then we track failure intensity - for example failures per transaction, or failures per hour - in order to guide our test process, and to determine the feasibility of the software release, and to determine whether the software meets the customer's reliability requirements.
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 