Now you see me and now you should still see me 

If you Google equivalence partitioning and edge case (and you know you did), you will probably see the same example over and over again. It’s a form field that takes a well defined numeric value.

Don’t get me wrong. This is a very good example. In fact, it is exactly what you’ll need if you know nothing about these techniques, and you need to understand the theory. Many people stop there. If they ever encounter this exact scenario they will properly write down the input values, according to the equivalence partitioning and edge case example. However, if the real world scenario wears a large pair of sunglasses, or maybe a wig, many people will fail to apply these helpful techniques. In real life, you have the simple cases and the complicated cases. The obvious GUI cases and the abstract cases.

Guess which ones I love…

Good QA techniques for beginners are good QA techniques for experts

QA techniques, as good techniques in all other fields, enable to apply the same logic to the simple and complicated cases. The added challenge of the complicated case is to define the issue you are looking at. This is a great life advice in general, but back to QA now. Let’s take a scenario that seems more complicated than the classic “single user input field”. Instead if a user input field, we now have an API call. Instead of a single field, we have an object that the API describes.

Consider the following call for an “Approve user” API:

{
“Email”: “John.Doe@example.com”,
“FirstName”: “John”,
“LastName”: “Doe”,
“Address”: “1st A street”,
“City”: “exampleville”,
“CellPhone”: null,
“BirthDate”: “1977-01-22”,
“SignedTermsAndConditions”: true,
“BaseGenericCreditScore”: 150,
“RequestedServiceId”: 7
}

Let’s throw some rules there as well:

A user can only be approved (for something….) if:

  • She is over 21 years old, and under 120 years old
  • Has a valid Email
  • Lives in one of the supported cities list OR provided a cell phone number
  • Promised her soul to the company by signing, without reading, the term and conditions
  • Add 100 to base credit score if the user is over 65 years old (Respect!)
  • Modified credit score should be equal or higher than the service requirement (let’s pretend that there is a list of services somewhere)
Break it down, then don’t break it down

The first thing you may say is “well, this is just a collection of fields that I already know attack using the QA techniques I already know”. Go ahead, say it, you’ll be right, even if it has two “alreadys” in it. Now think of this – the whole “user” object hinted of here, also has a few states – valid and invalid, according to the rules above. Once we know that all the specific validations works (the valid Email regex is correct, the developers know how to work with dates, etc.), it becomes easy to create the equivalence partitioning (valid, invalid, invalid due to corrupt or missing properties) and the edge cases (e.g. corrected credit score values matching the service requirements, just below etc.).

There will be may rules, there will be test cases, but we don’t need to blindly throw masses of users per test case. We now have a ready made group of users, just like we had a group of numeric values for that simple example numeric field.

Wait, isn’t that the same? Where is the advanced stuff?

Yes, it’s the same logic. The intelligent process was understanding the simple example. The advance feature – using this knowledge as a tool in real life. I find this to be true in most things.