Test Case Design Techniques: Black-Box and White-Box

Today I’m going to share some of the test case design techniques called specification-based or black-box techniques that I used with my work. When a new feature is added, some of you might have a question: how many tests will be enough? How do I know that the test case covers all my logic?

You probably already know this technique. Once you finish the article, I would appreciate it if you share or comment on other techniques that you have used, and I hope this knowledge exchange helps improve our coding and our testing skills.

What is a Test Case Design?

Test case design refers to the way you write your set of test cases to verify if your code works well or identify any bugs and defects.

A good selection tests will helps improve the quality of code while reducing testing time and quantity of test cases

What is Specification-Based?

Specification-based testing techniques are also known as ‘black-box’ or input/output driven testing techniques because they view the software as a black box with inputs and outputs.

There are four specification-based or black-box techniques:

• Boundary value analysis
• Equivalence partitioning
• Decision table
• State transition testing

What is White Box Testing?

White-box testing, also known as clear-box testing, is a method of software testing that tests internal structures or working elements of an application. An internal perspective of the system, the tester chooses inputs to exercise paths through the code and determine the expected outputs. It can be applied at the unit, integration and system levels of the software testing process.

There are various techniques to white-box testing as well:

• Statement coverage
• Decision coverage
• Condition coverage
• Decision and condition coverage

In this article, I will demonstrate a couple of techniques which I often use to find test cases and show examples to explain each technique.

Boundary value analysis

The boundary value technique is applied to edge variable values of partition.

• Minimum: valid boundary value
• Below the minimum: invalid boundary value because it is at the edge of an invalid partition
• Above the minimum: valid
• Maximum: valid boundary value
• Below the maximum: valid
• Above the maximum: invalid boundary value because it is at the edge of an invalid partition

These are the six tests for boundary values.

Example 1: NameChecker

This program will validate the length of the input name between 1–10 characters.

• The below minimum boundary value is 0
• The minimum boundary value is 1
• The above minimum boundary value is 2
• The below maximum boundary value is 9
• The maximum boundary value is 10
• The above maximum boundary value is 11

From the graph above, I can draw the boundary test case like so.

These values are near the limit where the behavior of the system changes. The input 1 and 10 are values almost near the limit which output value is still valid. The input 0 is the minimum value breaking the lower boundary of which the output value is invalid, while the input 11 is the value breaking the upper boundary of which the output value is invalid. Therefore, this is one of the ways to identify boundary value test cases.

Equivalence Partitioning

The equivalence partitioning technique is applied to a nominal value or any value representing a nominal case.

In the case of NameChecker, a nominal value might be 3 or 4 or any value representing the equivalent class (from 3 to 8). This technique helps minimize the effort of providing different inputs by picking up just one group or class instead of selected every value in the group.

Decision Table

A decision table is a superset of statement coverage dealing with complex business rules or complicated logic. Whenever logical conditions or decision-making steps occur, this technique is to be used. It can display all possible combinations of conditions.

Example 1: NameChecker by Decision Table Technique.

You may now understand the overall logic of nameChecker, but for clarity I will explain what functional programming is.

These are all the possibilities for nameChecker test cases.

• If the length of name is less than 1, it’s invalid.
• If length of name is more than 10, it’s invalid.
• If the length of the name is between 1 and 10, it’s valid. Every line of the code should be covered.

Statement Coverage

The technique involves execution to ensure that each statement or line of code was executed at least once. if dead code occurs, It can be removed.

I will start by implementing the code per our test case using Go.

Let’s run code coverage.

• Select the package that you would like to execute
• Right click then select Go: Toggle Test Coverage In Current Package

The result will show the percentage of coverage statements.

You will see lines of code which were executed (green highlight). This helps you write the set of minimum test cases that cover your code. I often use these techniques when starting a new project or new function. If every line is highlighted in green, I can be sure that my code is ready for refactoring or other steps. If the line was highlighted in red, however, you might need to revisit the test case or the code.

Example 2: Graders

This program will calculate test scores, then return the grade. The scale may look like this:

• Grade A: more than or equal 80 points
• Grade B: 70–79 points
• Grade C: 60–69 points
• Grade D: 50–59 points
• Grade F: less than or equal 49 points

By the way, the scores can’t be less than 0.

Based on this data, graders have to decide how to calculate the test scores. I will define test cases using the decision table technique.

• If the score is more than or equal 80, then get an A
• If the score is more than or equal 70 but less than or equal 79, then get a B
• If the score is more than or equal 60 but less than or equal 69, then get a C
• If the score is more than or equal 50 but less than or equal 59, then get a D
• If the score is more than or equal 0 but less than or equal 49, then get a F

Otherwise, return as invalid score.

Now that I know six partition case, I’ll try to find the value of unit test with boundary value analysis.

Case: Grade A

Case: Grade B

Case: Grade C

Case: Grade D

Case: Grade F

Invalid Score

Now let’s write unit tests based on each boundary value test case. The code will look like this.

It’s time to run test coverage. The name of test case executed will show on the left panel and the statements coverage will display below.

These are my ideas when using black-box techniques to define a minimum unit test for developers. It can help guide you, save cost and your time, and benefits the code refactoring in the future.

I hope you enjoy this article and that I have answered some of your lingering questions. If you like it, please click the “clap” icon below for me 👏 Thanks for reading!

Source Code

GitHub - jirawan-chuapradit/test-case-design-black-box-white-box

References

Black Box Testing Techniques | 8 Useful Techniques in Black Box Testing

White-box testing - Wikipedia

Want to read more stories like this? Or catch up with the latest trends in the technology world? Be sure to check out our website for more at www.kbtg.tech