In this article, I discuss a practical approach to selecting specific representative values in test cases (especially low-level test cases), focusing on the use of unique numbers, particularly prime numbers other than 2. This approach is based on my personal experience and subjective views, so please understand that I am not claiming that this is always the correct approach. 

We’ll take a look at this approach in three steps: Avoiding the use of 2, using unique numbers, and using prime numbers. 

Avoid using 2 as a specific representative value in test cases

When I was working part-time as an instructor of a major cram school, there was a description in one of the textbooks that went like this: 

-

Example) Find the circumference of a circle with a radius of 2 cm.

Explanation) The circumference of a circle is calculated by the diameter multiplied by pi. 

Therefore,

2 × 2 × π = 4π

Answer) 4π cm

-

Such an explanation is obvious for those who already understand, but I think it can be confusing for those who do not. This is because it is unclear whether "2 × 2" means "radius × radius" or "twice the radius." Personally, I often thought, "Why would they write such a confusing example in a textbook from a major cram school?"

Using “2” in this way makes it difficult to distinguish cases where logic like “use double the value” is being applied. Therefore, I try to avoid using “2.” 

Of course, this does not mean that you should avoid using 2 in all cases. For example, if you frequently run a "3x points campaign" in the domain you are dealing with, it would be better to avoid using "3." In other words, I think it's better to avoid numbers that often carry special meanings.

Use unique numbers as specific representative values

Similarly, it is good practice to avoid using the same unique number frequently.

For example, let's say you specify "5 of product A, 5 of product B, and 5 of product C." Even though the expected total quantity is 15, if the actual total is “10,” it becomes unclear which product is causing the issue. 

Personally, I would specify "3 of product A, 5 of product B, and 7 of product C." As a result, if the total quantity is "12" instead of the expected "15," I can make the assumption that product A wasn't added. 

Use prime numbers as specific representative values in test cases

Prime numbers are often chosen as specific representative values in test cases.

The reason for this is that, for example, if you write "enter 10," it is unclear whether you simply wanted to enter 10 or whether you wanted to enter "twice the value of 5."

To prevent confusion about the intent behind the value, I try to choose prime numbers as much as possible. 

However, this only applies to representative values

The content discussed so far is about representative values in equivalence partitioning. In addition to these, I believe that boundary values in boundary value analysis should be set separately.

For example, as illustrated in the image below, regarding the input values for the month of a date, you may choose 1 or 12 as input values.

Original Image Source: Black Box Tests

1 and 12 are not representative values, but special values as boundary values.

On the other hand, what I have been talking about in this article is not boundary values but representative values in equivalence partitioning.

Regarding the input values for the month of a date,

• Boundary values for valid equivalence classes... 1, 12
• Boundary values for invalid equivalence classes... 0, 13
• Representative values for valid equivalence classes... 7

You may choose these values for example. 

(As a premise, I assume that no matter which month is chosen, the conditions are the same. For example, I assume that there is no need to consider things like "February has only 28 days (29 days in a leap year)...".)

Conclusion

In this article, I articulated my concerns regarding choosing specific representative values. 

After reading this article, you may have differing opinions and point to cases where my points are not applicable. Try to articulate when you wouldn’t choose this approach. There may be hidden conditions in those cases. If possible, I would be happy if you could share your thoughts.

Additional discussion: Exceptions to the rule

In the main article, I advocate for choosing prime numbers as much as possible, but we are not necessarily strict about using prime numbers.

For example, when considering tests related to bus fares using coins (not electronic money), we would not consider choosing "691 yen" considering it is a prime number, but we would choose "700 yen." There are three reasons for this.

1. It is difficult to determine whether the number 691 is a prime number.

It is easy to understand that 7 and 13 are prime numbers, but it is difficult to determine whether the number 691 is a prime number.

Choosing a number like 691 that is difficult to identify as a prime number renders the effort meaningless. When trying to use a prime number to exclude the consideration of it being a multiple of something, it should not be difficult to determine whether a number is a prime number or not.

2. The number 691 may be interpreted as a special number

If you explicitly specify 691 as a test case value, people may start to speculate, "Does this 691 have a special meaning, and was it chosen for a reason?"

3. The number "691" may not be suitable for the domain

For example, bus fares (not electronic money) are often set in increments of 10 yen. Therefore, I think it is not suitable to choose a number with a non-zero value in the one's place.

For these reasons, in this case, I think it is better not to use the value of 691 yen but to use the value "700 yen." By the way, in such cases, we often choose "700 yen" instead of "600 yen." This is because "700 yen = 7 (prime number) × 100 yen."

This article was translated from the original Japanese version with permission from the author.