Equivalence Partitioning for Name field

Question

Equivalence Partitioning for Name field:

Requirement says the Name field shall:

• Accept alpha numeric characters and special characters `!@#$%&*
• Minimum 4 characters
• Maximum 40 characters
• First character must be a letter.

Now my questions are:

• How many equivalence partitions can be there in such a case?
• How to consider various permutations and combinations in such a case?

Example:

• 3 basic partitions
• Partition 1: <4 character (invalid condition)
• Partition 2: >40 characters (invalid condition)
• Partition 3: between 4&40 (Valid condition)

Now under each of these partitions, again we have various combinations:

• Partition 4: only alphabets (Again two more such as lower case and upper case)
• Partition 5: Only numbers (invalid condition)
• Partition 6: Only special characters (Invalid Condition)
• Partition 7: Alphabets and numeric
• Partition 8: Alphabets and special characters and so on...

There there will be so many combinations and on what basis shall we decide?

Secondly: Assume that we have several fields in a form (Such as user registration). Again in such case there will be several permutations and combinations.

What would be the best technique for deciding test cases?

Answer 1

I would consider 3 parameters to decide on partitioning:

• Position
• Size
• and Input

---

With respect to Position, I would create 2 partitions:

1. Alphabetic character at 1st position, with rest as a valid condition (i.e size between 4 to 40, valid set of input).
2. Non-Alphabetic character at 1st position, with rest as a valid condition (i.e size between 4 to 40, valid set of input).

With respect to Size, I would create 3 partitions:

1. Size < 4, with rest as a valid condition (Alphabetic character at 1st position, rest as a valid set of input).
2. Size >=4<=40, with rest as a valid condition (Alphabetic character at 1st position, rest as a valid set of input).
3. Size >40, with rest as a valid condition (Alphabetic character at 1st position, rest as a valid set of input).

With respect to Input, I would create 2 partitions:

1. Valid input with rest as a valid condition (Alphabetic character at 1st position, size >=4<=40)
2. Invalid input (one of the character is illegal in input) with rest as a valid condition (Alphabetic character at 1st position, size >=4<=40)

Answer 2

The three basic partitions look good if you use an alphabetic character in the first position and valid characters everywhere else.

Next partition would be a valid length with valid characters but starting with a non-alphabetic character.

Last partition would be a valid length with an alphabetic character in the first position and at least one illegal character after that (not alphanumeric and not any of !@#$%&*).

Unless I'm totally confused that should be all.

Answer 3

First, you don't need to test conditions defined by partitions 4-8 on groups defined by partitions 1 and 2. These groups of input strings fail a requirement, and are therefore invalid. "Fail fast, fail often!"

Next, you have another "sink-or-swin" requirement that can cut your testing in half. Literally. Either the first character is a valid alphabetical character ("a"-"z" or "A"-"Z", inclusive) or not. Again, "Fail fast, fail often!"

Now you've got groups of input strings 4-40 chars long (inclusive), with a valid first char, is the time to test your partitioning scheme, which is a good one. You might, should actually, also include: input string made up of alphanumeric chars and invalid special chars, e.g. "-". ";" and so on.

As far as permutations goes, since you can't test all possible permutations, you should always test edge-cases and a random sampling of the "regular" cases. In your case I'd go with:

• Leave the input field empty and try to validate (this is a special case of invalid input, where the input is translated as Null, not just invalid) (invalid, of course!)
• 1/2/3 chars, randomly drawn from a pool of both valid and invalid chars (invalid!) (Why the insistence on both valid and invalid pools?)
• 4 chars, all alphabetical chars
• 4 chars, all numerical (invalid! Why?)
• 4 chars, all valid special chars (invalid! Why?)
• 4 chars, randomly drawn from pool of valid chars (you tell me, what's the expected result here? Think before you answer!)
• 4 chars, at least one, randomly positioned in the string, is an invalid special char (invalid, of course)
• 40 chars, randomly drawn from pool of valid chars (Again, tricky)
• 5-39 (inclusive) chars, randomly decided, chars randomly drawn from a pool of valid chars (Last of the tricky ones)

Lastly, if you can automate -- automate! Above I've listed 9 test cases categories. If you only run one test case from each "category" I can assure you you'll not have found bugs in the form validation mechanism. You need to run at least 5-6 test cases from each "category" to be fairly convinced that it's almost certainly bug-free. If you can't automate... buddy, I hate being in your shoes, you've got your work cut out for you. :)

Answer 4

I would test:

Negative tests

LT 4 chars

GT 40 chars

GT 3 chars with non-alpha in pos 1

Non allowable special character in pos 2 - 40 (1 test, not all positions)

Positive Tests

GT 3 chars with lower case alpha in pos 1

GT 3 chars with upper case alpha in pos 1

Mark Smith.