Boundary Value Analysis Example

Boundary Value Analysis:
Boundary value Analysis is the act of dividing the given input set by a relation into groups or classes which is treated the same by the module or which should produce the same result. Any data value within a class is equivalent in terms of testing, to any other value.

The steps for using boundary value testing are:

1. Identify the equivalence classes from the given requirements or scenario.
2. Identify the boundaries of each Equivalence Class.
3. Create a test case for each boundary value by choosing one point above the boundary, one point below the boundary and one point on the boundary.
4. From the results obtained for one member in an equivalence class extrapolate results for all values in that partition.

Examples:
Consider the same problem what we have seen in equivalence class partitioning.

Equivalence Class Testing Technique Examples

Equivalence class Testing:
Equivalence class or Equivalence Partition is the act of dividing the given input set by a relation into groups or classes which is treated the same by the module or which should produce the same result. Any data value within a class is equivalent in terms of testing, to any other value.

Equivalence partitioning is a software testing design technique that involves identifying a small set of representative input values that produce as many different output conditions as possible. One representative sample from each partition is picked up for testing since all the values produce equal and same output. This technique tries to define test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.

The step for using equivalence class testing are:

1. Identify the Equivalence class from the given requirements or scenario.
2. Create a test case for each equivalence class.
3. From the results obtained for one member in an equivalence class extrapolate results for all values in that partition.

Examples:
The electricity bill computed by the service provider has a fixed component as well as a running component. All customers are charged at a rate of $40 flat as a fixed component. In addition to this, they would be changed a running component and/ or a fine, depending upon their amount of consumption or usage.

The rules for this are given below:

• If the number of units consumed by the consumer is less than 10 units, then the running cost is not charged for the consumer.
• If the nimber of units is between 11 and 20, then the running cost is charged at $1 per unit.
• If the number of units is between 21 and 40, then the running cost is charged at $2 per unit.
• If the number of units exceeds 40, then the running cost is charged at $5 per unit.
• Use equivalence class partitioning to decide on the test cases to be designed.

Test Design Techniques Black box testing

What is Black box Testing ?
Black box testing is a strategy in which testing is based solely on the requirements and specifications. Here, testing the software is done based on output requirements and without any knowledge of the internal structure or coding in the program.

Process involved in Black box testing:
First, the requirements or specifications are analyzed and valid inputs are chosen based on the specification. Then we need to determine the expected outputs for those inputs. Now tests are constructed with the selected inputs to execute the test. After executing the tests actual outputs are compared with expected results.
Note: Test design techniques are used to design test cases so that an effective set of test cases can be prepared.

What are the Test design techniques for black box testing:
Following are the black box testing techniques.

• Equivalence class partitioning
• Boundary value Analysis
• Decision Tables
• State transition Diagrams
• Orthogonal Arrays
• All Pairs

Recommended:
Equivalence class testing technique examples
Boundary value analysis with examples
Decision Table Testing Example
state transition testing sample
How To do Testing with orthogonal Array 

Why Test cases must be designed ?

Need for Test Design:
Just like code is designed and developed, test cases also must be designed and then written. Since test design is required to derive at an optimal test suite which is of reasonable size and uncovers as many errors as possible. Also have to consider that randomly selecting or writing test cases does not provide effective testing.

Let's see an example of simple programming error.
If (X > Y) max = X;
Else max  = X;

Here, for the above program if we developed large test suite without design such as {(X=3, Y=2), (X=10, Y=1), (X=100, Y=0),(X=5,  Y=4) cannot going to detect any error. But if we have a design as that of small test suite {(X=3, Y=2), (X=5, Y=6)} can easily detect the error.

Requirements Traceability And Test Cases

What is Requirements Traceability ?
Functional or software requirement specification  is the document which describes stakeholder's requirements which should be traced with deliverables produced during the software development life cycle.

What are the objectives of Requirements Traceeability ?
The objectives of requirement traceability, in general, are to

• Ensure that the deliverables meet the requirement specification.
• Ensure that no requirements are missed and therefore  that all are delivered.
• Identify which deliverables implement which requirements.
• Identify any deliverables that cannot be tracked back to a requirement. This may be either due to undocumented requirements or to the unnecessary introduction of features that are not actually required by the stakeholders.

Requirements Traceability and Test cases:
Every requirement should be traced to the individual test cases. This is required to ensure that all the requirements have been covered in the test cases and also to identify what tests are necessary to verify a particular requirement has been implemented successfully.

How to write a test case from use case

Use Case to Test Case Conversion:
Let us see the process for generating test cases from a fully detailed use case. The first step is to for each use case, generate a full set of high level test scenarios. For each high level scenario, identify at least one positive or negative test case and the conditions that will make it "execute". Then for each test case, identify the data values with which to test. At last document the test case as a combination of stepps and expected results including the above identified data values.

Tester should consider following concepts under preparation of test case:

• Ensure each section in use case has one or many test cases.
• Ensure integrity between modules are maintained throughout the test cases.
• Need to ensure inter dependencies external to the system are taken care in test cases.

What is Test Case? Why Do We Need

What is a Test case?
IEEE Standard 610 (1990) defines a test case as follows:
A set of inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement."

A test is not only designed to reveal a defect but also to learn something from the defect.

Why Do We a Test Case?

• Test cases identify and communicate the conditions that will be implement in test.
• Necessary to very successful and acceptable implementation of the product requirements.
• Help finding the problems in the requirements or design of an application.
• To determine whether we meet the client expectations.
• Help managers make ship / no-ship decisions.

What would happen if there is no Test Case?
If there is no test case then we cannot test effectively and so poor quality  of the deliverables to the client. Other thing is no requirements coverage tracking and take more time for execution.