Marginal value analysis – Technique in black box testing

Tram Ho

We all know that black box testing involves confirming a system regardless of its internal design. We also discussed the pitfalls of Equivalent Partitioning. In this article, we will discuss another black box inspection technique called “Marginal Value Analysis” (PTGTB)

  • What is marginal value analysis (PTGTB)?
  • How to do the work (PTGTB)?
  • Marginal value analysis (PTGTB) with the technique of “equivalent zoning” (PVTD)
  • Pitfalls of boundary value analysis (PTGTB)

1. What is the marginal value analysis?

The basis of Marginal Value Analysis (PTGTB) is to check the boundaries at the partitions (rediscover the equivalent Partitioning Technique!). PT is an extension of PVTD. The minimum and maximum values ​​of a partition are the boundary values ​​of this technique.

We have found that it is more likely to find defects at the boundary of a partition (Example: A dev uses> 10 instead of> = 10 for a condition). The equivalent partition alone is not enough to catch such an error. Therefore, it is necessary to identify a new technique that can detect anomalies at the boundary of the generated partition.

Marginal value analysis is possible at all test levels and is mainly used for a range of numbers, dates and times.

2. How to do boundary value analysis?

We now have some ideas about boundary value analysis. So let’s begin to understand how to derive test conditions with this technique. We will refer to the same example of the Gym login age form.

The first step of (PTTBTB) is to create an equivalent Partition as shown below.

Now Focus on Valid partitions, ranging from 16-60. We have a 3-step approach to defining boundaries:

  • Determine the marginal value (GTB) in this region as 16 and 60 (1)
  • Take the marginal value (GTB) smaller than the GTB in (1) to be 15 and 59.
  • Take the marginal value (GTB) greater than the GTB at (1) to be 17 and 61.

If we combine it to get the following boundary values:

  • Valid: Age = 16, 17, 59, 60
  • Invalid: Age = 15, 61

This is a simple example to see that the valid boundary conditions are in the valid partition layer and the invalid boundary conditions belong to an invalid partition layer.

Do you know why we don’t use 16.1, 15.9, 59.9 and 60.1 as marginal increase and decrease values? Let me take another example to explain this. Assume that you are entering your weight on a website. Based on your weight and height, the website will tell you your Body Mass Index (BMI). You can enter values ​​from 30 to 150 kg in the weight number field. Weight input field only allows natural numbers, that is, positive integers!

In this case, if you would create boundaries using the same method – you would end with

  • Valid boundary conditions: Age = 30, 31, 149, 150
  • Invalid boundary conditions: Age = 29, 151

Now consider the same scenario, but the weight input field allows decimals up to 1 decimal place. In this case, the boundary conditions will come as follows:

  • Valid boundary conditions: Age = 30, 30.1, 149.9, 150
  • Invalid boundary conditions: Age = 29,9, 150,1

Do you see the difference? We take the minimum acceptable value on either side of the boundary. This is a separate test condition and should not be mixed with boundary values.

3. Analysis of boundary value with equivalent partition ###

Now that we have an understanding of Boundary Value Analysis, let’s combine it with the “Equivalent Partition” method of PVTD.

Returning to the first example, let Review the diagram.

The range is between 16 – 60 and Boundary Value analysis provides us with test conditions like 15, 16, 17, 59, 60, 61. If you have a close look, you don’t think we have Equivalent equivalence partitioning is covered by 17, 59 and invalid equivalence partitioning is composed of 15 and 61? After all Equivalence partitions say we should choose a number between 16-60 for valid partitions and less than 16 or more than 60 for invalid partitions. So, if the boundary value already covers the Equivalence partition, why do we need the partition as a separate technique? This is an unclear concept for most people, and not many articles have clearly explained it.

Theoretically, the boundary value actually covers the Equivalence partition, but we still need a partition. If we only apply the Bien value and fail, we will never know whether the boundary condition is corrupted or the entire partition fails.

To better understand, we will study one more example. To continue with our gym app, let’s say the developer wrote the following logic:

  • If (age <= 17), do not give gym membership card
  • If (age> 60), do not give gym membership card

If you look at the logic, you’ll realize that the logic must be an If (age <17), but the developer has added = a false signature. Do you also realize that the logic for the entire valid partition is missing? If (age> = 16 and age <= 60) Then allow gym members!

If we only use the boundary condition value 17, this will result in a failure of the test results. However, it will not tell you whether the boundary condition failed or the whole partition failed. Therefore, it is necessary to use the equivalent partition value, not the boundary value. In this case, if we use the value 20, it will not work. It will give a clear indication that the developer has missed out on the implementation of the entire partition.

Therefore, if we combine both the Values ​​and Equivalent Partitions, our test conditions will be:

  • Valid boundary conditions: Age = 16, 17, 59, 60
  • Invalid boundary conditions: Age = 15, 61
  • Valid equivalent partition: Age = 25
  • Invalid equivalent partition: Age = 5, 65

4. Pitfalls of PTGTB

After applying both boundary values ​​and Equivalence partitions, can we confidently say that we have covered the request? Unfortunately, it’s not that simple! The boundary value partition and the equivalent partition assume that the application will not allow you to enter any other characters or values. Characters like @ or negative values ​​or even alphabets will not be allowed. However, this assumption is not valid for all applications and it is essential to test these before we can say that field values ​​are fully operational.

In addition, we may have situations in which the input value depends on the decision of another value. For example: If the Gym form has a different Male and Female field, and the age limit will vary according to that option. The marginal value alone cannot handle such variations and this leads us to another black box technique called Decision Table Testing. We will discuss in detail in our next article. Please look forward to it!


Share the news now

Source : Viblo