Software Quality Assurance and Software Quality Control
Equivalence Class Partitioning & Boundary Value Analysis
When creating black-box test cases, the input data used is critical. Three successful techniques for managing the amount of input data required include:
Equivalence Partitioning
Equivalence partitioning is software testing related technique with the goal:
To reduce the number of test cases to a necessary minimum.
To select the right test cases to cover all possible scenarios.
Rather than undertaking exhaustive testing of each value of the larger class.
An equivalence class is a subset of data that is representative of a larger class.
It is sufficient to select one test case out of each partition to check the behavior of the program.
Let’s say for ex: The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
Boundary Analysis
A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
§ Low boundary +/- one ($9,999 and $10,001)
§ On the boundary ($10,000 and $15,000)
§ Upper boundary +/- one ($14,999 and $15,001)
Error Guessing
Test cases can be developed based upon the intuition and experience of the tester. For
example, in an example where one of the inputs is the date, a tester may try February
29, 2000.
Quality Assurance
|
Quality Control
| |
Definition
|
QA is about having an overall development and management process
that provides right environment for ensuring quality of final product.
|
QC is about checking at the end of some development process
(eg.- a design activity) that we have built quality in i.e. that we have
achieved the required quality with our methods.
|
Description
|
QA gives us added assurance that the whole producing or checking
process is properly planned and executed and thus maintaining high quality.
|
QC is like testing a module against requirement specification or
design document, measuring response time, throughput etc.
|
Equivalence Class Partitioning & Boundary Value Analysis
When creating black-box test cases, the input data used is critical. Three successful techniques for managing the amount of input data required include:
Equivalence Partitioning
Equivalence partitioning is software testing related technique with the goal:
To reduce the number of test cases to a necessary minimum.
To select the right test cases to cover all possible scenarios.
Rather than undertaking exhaustive testing of each value of the larger class.
An equivalence class is a subset of data that is representative of a larger class.
It is sufficient to select one test case out of each partition to check the behavior of the program.
Let’s say for ex: The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
Boundary Analysis
A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
§ Low boundary +/- one ($9,999 and $10,001)
§ On the boundary ($10,000 and $15,000)
§ Upper boundary +/- one ($14,999 and $15,001)
Error Guessing
Test cases can be developed based upon the intuition and experience of the tester. For
example, in an example where one of the inputs is the date, a tester may try February
29, 2000.
When to stop testing
When the test manager is confident that the application will perform as expected in the production environment. This confidence is derived by analysis conducted on:- Deadlines (release deadlines, testing deadlines, etc.) are met
- Test cases completed with certain percentage passed
- Test budget depleted
- Coverage of code/functionality/requirements reaches a specified point
- Meantime between failures
- Risks associated with continuing to test
- Percentage of coverage achieved
- Number of open defects and their severity
- Risk associated with move to production
No comments:
Post a Comment