Equivalence Class Partitioning with example

What is "Equivalence Class Partitioning"?

We define "Equivalence Class Partitioning" as a method that can help you derive test cases. You identify classes of input or output conditions. The rule is that each member in the class causes the same kind of behavior of the system. In other words, the "Equivalence Class Partitioning" method creates sets of inputs or outputs that are handled in the same way by the application.

Another definition taken from Wikipedia:
"A technique in black box testing. It is designed to minimize the number of test cases by dividing tests in such a way that the system is expected to act the same way for all tests of each equivalence partition. Test inputs are selected from each class. Every possible input belongs to one and only one equivalence partition."

Why learn "Equivalence Class Partitioning"?

This method drastically reduces the number of test cases that are required to be tested because we don't have time, money or manpower to test everything. In addition, it can help you find many errors with the smallest number of test cases.
How to use "Equivalence Class Partitioning"?

There are 2 major steps we need to do in order to use equivalence class partitioning:

• Identify the equivalence classes of input or output. Take each input's or output's condition that is described in the specification and derive at least 2 classes for it:
  • One class that satisfies the condition – the valid class.
  • Second class that doesn't satisfy the condition – the invalid class.
• Design test cases based on the equivalence classes.

Example 1

In a computer store, the computer item can have a quantity between -500 to +500. What are the equivalence classes?

Answer: Valid class: -500 <= QTY <= +500
                Invalid class: QTY > +500
                Invalid class: QTY < -500

Example 2

In a computer store, the computer item type can be P2, P3, P4, and P5 (each type influences the price). What are the equivalence classes?

Answer: Valid class: type is P2
                Valid class: type is P3
                Valid class: type is P4
                Valid class: type is P5
                Invalid class: type isn’t P2, P3, P4 or P5

Practice

Bank account can be 500 to 1000 or 0 to 499 or 2000 (the field type is integer). What are the equivalence classes?

Try to solve it before reading the answer.

Practice 1 - answer

• Valid class: 0 <= account <= 499
• Valid class: 500 <= account <= 1000
• Valid class: 2000 <= account <= 2000
• Invalid class: account < 0
• Invalid class: 1000 < account < 2000
• Invalid class: account > 2000

Equivalence Class Vs Boundary Testing

Let us discuss about the difference between Equivalence class and boundary testing. For the discussion we will use the practice question:

Bank account can be integer in the following ranges: 500 to 1000 or 0 to 499 or 2000. What are the equivalence classes?

Answer:

• valid class: 0 <= account <= 499
• valid class: 500 <= account <= 1000
• valid class: 2000 <= account <= 2000
• invalid class: account < 0
• invalid class: 1000 < account < 2000
• invalid class: account > 2000

In equivalence class, you need to take one value from each class and test whether the value causes the system to act as the class' definition. It means that in this example, you need to create at least 6 test cases – one for each valid class and one for each invalid class.

How many test cases will be, if you use boundary testing?

The following table shows how much test cases will be using "Boundary Testing" method:

Test Case #	Value	Result
1	-1	Invalid
2	0	Valid
3	1	Valid
4	498	Valid
5	499	Valid
6	500	Valid
7	501	Valid
8	999	Valid
9	1000	Valid
10	1001	Invalid
11	1999	Invalid
12	2000	Valid
13	2001	Invalid

In boundary testing, you need to test each value in the boundary and you know the value, you don't need to choose it from any set. In this example you have 13 test cases.

Now, let us exam how to combine this 2 methods together.

The following table shows all the boundary testing values and their equivalence classes:

#	Boundary Value	Equivalence Class	Result
1	-1	account < 0	Invalid
2	0	0 <= account <= 499	Valid
3	1	0 <= account <= 499	Valid
4	498	0 <= account <= 499	Valid
5	499	0 <= account <= 499	Valid
6	500	500 <= account <= 1000	Valid
7	501	500 <= account <= 1000	Valid
8	999	500 <= account <= 1000	Valid
9	1000	500 <= account <= 1000	Valid
10	1001	1000 < account < 2000	Invalid
11	1999	1000 < account < 2000	Invalid
12	2000	2000 <= account <= 2000	Valid
13	2001	account > 2000	Invalid

Now, we can reduce some of the test cases that belong to the same equivalence class. We can delete lines 3 and 4 which belong to equivalence class "0 <= account <= 499". We also can delete lines 7 and 8 hich belong to "500 <= account <= 1000". The new table will be:

#	Boundary Value	Equivalence Class	Result
1	-1	account < 0	Invalid
2	0	0 <= account <= 499	Valid
5	499	0 <= account <= 499	Valid
6	500	500 <= account <= 1000	Valid
9	1000	500 <= account <= 1000	Valid
10	1001	1000 < account < 2000	Invalid
11	1999	1000 < account < 2000	Invalid
12	2000	2000 <= account <= 2000	Valid
13	2001	account > 2000	Invalid

You can even reduce more test cases although in my opinion, it is important to keep this table because it keeps a hard connection to the boundary testing. You can see in the table that I didn't reduce those test cases that are touch in the boundary itself of each range.

Let's reduce more test cases (just for the fun and for the practice (test case 5, 9 and 10):

#	Boundary Value	Equivalence Class	Result
1	-1	account < 0	Invalid
2	0	0 <= account <= 499	Valid
6	500	500 <= account <= 1000	Valid
11	1999	1000 < account < 2000	Invalid
12	2000	2000 <= account <= 2000	Valid
13	2001	account > 2000	Invalid

Now, in this table, for each equivalence class, you choose one value that belongs to boundary testing.

Boundary Values Testing with example

What is “Boundary Values Testing”?
 
“Boundary Values Testing” is a method that tests the boundary whether it's an input, an output or a performance boundary. Our tests focus on the boundaries values and not on the entire range of data. We will use it when we have a field that can contain a range of values as an input, an output or as a requirement.

How to use “Boundary Values Testing”?
 
If you have a range: (a to b), you will test the following:

Test Case	Value	Expected Result
1	a-1	Invalid
2	a	Valid
3	a+1	Valid
4	b-1	Valid
5	b	Valid
6	b+1	Invalid

According to the ISTQB in "Boundary Values Testing" we only test the following:

Test Case	Value	Expected Result
1	a-1	Invalid
2	a	Valid
3	b	Valid
4	b+1	Invalid

Why ISTQB has less test cases, because we can say that if 'a' and 'a-1' are working well, then we can assume that 'a+1' is working well. The same claim will be about the upper bound. If 'b' and 'b+1' are working well, then we can assume that 'b-1' is working well.
Any option of implementing the "Boundary Values" method you will use is good. Instead of testing the entire range, you can tests 6 or 4 cases and still have confiedence that the software works well.
Here are some more rules from my experience that you can take in consideration:

• Always test 0 if it is inside the range and sometimes even if it's out of range because 0 has special effect on software (like dividing in 0).
• Always test the empty string if it is inside the range and sometimes even if it's out of range.
• Sometimes you can test a value that exists inside the range and not in the boundary just in case…(It allows you to sleep deeper at night…).

Now, let us practice the "Boundary Values Testing" method.
Practice 1
You are testing inventory software that contains a field of the quantity of items. The field can contain any value between 10 to 100 units.

• What is the max number of test cases you will need in order to test the field?
• What is the minimum number of test cases you will need in order to test the field, using boundary testing?

Try to solve it and then continue to read the answer.
Practice 1 - answer
The field contains a range of 10 to 100 (10-100).

• The max number of test cases you will need in order to test the field will be 93 test cases (9, 10, 11, 12…97, 98, 99, 100, 10) or 94 test cases if we include the value of 0.
• The minimum number of test cases you will need in order to test the field, using boundary testing will be 6 test cases (9, 10, 11, 99, 100, 101) or 7 test cases if we include 0.
• Note that we need to add more tests like alphabetic chars and special chars like %, *.

Practice 2
You have a password field that can contain up to 8 characters and must have at least 3 characters. What is the minimum number of test cases you will need in order to test the field? (Pay attention to the requirement that specifies the field's length and not what kind of chars it can get! In the real world we can't ignore it but in order to simplify the example we will ignore it).
Try to solve it and then continue to read the answer.

Practice 2 - answer
6 test cases: length 2, length 3, length 4, length 7, length 8, length 9 or 7 test cases Length 2, length 3, length 4, length 6, length 7, length 8, length 9. We can add a test case that test the empty string. 

Practice 3
You have a field that can contain up to 5 digits and can have 0 digits. The value of the field can be in the range of (-5148 to +3544) What is the minimum number of test cases you will need in order to test the field using "Boundary" testing?
Try to solve it and then continue to read the answer.

Practice 3 - answer

• For the length we have 5 test cases: 0 length, 1 length, 4 length, 5 length and 6 length.
• For the range we have 7 test cases: -5149, -5148, -5147, 0, +3543, +3544, +3545.
• Total of 12 tests cases.

we reduce the amount of test cases to be less then 12 (try to solve it and continue to read)?
Well, we can reduce it to 10 test cases by combine the value testing of the field with the length testing of the field.

Case #	Length	Value	Expected Result
1	0	None	Valid
2	1	0	Valid
3	4	3543	Valid
4	4	3544	Valid
5	4	3545	Invalid
6	5	-5149	Invalid
7	5	-5148	Valid
8	5	-5147	Valid
9	6	123456	Invalid
10	6	-45322	Invalid

This was an example of why you must use your head all the time, because sometimes you can combine methodologies with each other or combine them with your common sense and reduce the amount of testing or create smart tests that will reveal beautiful and important bugs.

Smoke , Sanity and difference between Sanity and regression testing.

Smoke Testing:-

1) Smoke testing basically known as the build verification testing.
2) Smoke testing is used to check the critical functionality working fine or not.
2) In smoke testing we check that the build is ready for the further testing or not.
3) Basically it is a tested by the developer, but in most of companies tester perform this task.
4) Smoke testing is used to avoid the time for the further testing.
5) If build pass the smoke test, then the build is ready for the further testing.

Example :- Supposes I have to test the  user dashboard, when I am logged in into the application blank page being displayed. So smoke test is fail and build should not be ready for the further testing.


 Sanity Testing:-

1) Sanity Testing is also a kind of build verification testing.
2) In sanity testing is performed to check that the bug have been fixed and no further issues are introduced due to these changes.
3) Sanity testing is perform by the testers.
4) Sanity testing is subset of Acceptance testing, it is also known as tester acceptance testing.

Difference Between Sanity and Regression Testing 

Sanity testing is basically the basic testing to accept the build for detailed testing.

Regression testing is testing the impact of changes after bug fix or after any change in the application or the environment.

Example:-  

Supposes I have edit profile page for the regression testing. But when I logged in into the application, blank page being displayed. Means no need to test the advanced testing because sanity is fail.