How to design test cases for phone number and email input fields?

Question

I'm trying to improve the design of test cases but I came across a different approach from some partners. For example, let's say there's a form to test, this form has 2 fields (phone and email) and a submit button.

My approach:

Positive flow:

• TC1: Submit with all valid fields

Negative functionality:

• TC2: submit with all valid fields but phone empty
• TC3: submit with all valid fields but phone with letters
• TC4: submit with all valid fields but phone with symbols
• TC5: submit with all valid fields but phone with unicode chars
• TC6: submit with all valid fields but phone with 1 number (boundary)
• TC7: submit with all valid fields but phone with 11 numbers (boundary) and so on
• TC8: submit with all valid fields but email with 2 @s
• TC9: submit with all valid fields but email without top level domain
• TC10: submit with all valid fields but email with 2 dots in domain name
• TC11: submit with all valid fields but email empty
• TC12: submit with all valid fields but email without domain and so on

My partner's approach:

Positive functionality:

• TC1: submit with all valid fields

Negative functionality:

• TC2: submit with all valid fields but phone is tested in every step
  (covering my previous test cases: empty, letters, chars, etc)
• TC3: submit with all valid fields but email is tested in every step (covering my previous test cases: empty, domain empty, etc)

What's your opinion about these approaches? Take into consideration that these test cases must be automated as well. What are the pros and cons?

Last but not least, another doubt, is it necessary to add styles verification in the steps?

For Example:

• Step: Verifiy the title is bold and aligned left
• Step: Hover the link - Expected Result: Link turns blue.

Thank you in advance.

Answer 1

I suggest you look to use* a test pyramid pattern with something like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more. The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy - payment works, sad (2 cases) - amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of 'check condition a,b,c,d, whatever else we can think of' or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers.

---

Update:

* Originally I said 'create a test pyramid'. This might be a bit too high level. What I meant was the the test pyramid principle should guide your actions and where to test. This should be adding (not 'creating') to the test pyramid approach.

Answer 2

I think your approach is generally better. It is better to have atomic test cases because long tests tend to get flaky: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html.

However, since this is is a form with only two fields, and I guess the scope of the form isn't very big (what I mean by this is you don't need to navigate to another page or do other DOM changes, once the form is opened), your partner's approach might be more pragmatic.

Answer 3

I would say that both, you and your partner, are equally correct. Even though I don't fully understand what is meant with "is tested in every step" in your partner's approach. I think you should pick the approach that is easiest for you to implement (automatize) and maintain. Both approaches seem like they could be automated. It also seems that you have pretty much all the use cases covered. Are you overanalyzing this?

If I read between the lines, I think you're asking that if you should add many steps to a single test case vs. one step (use case) per test case. This is a classic problem. One step per test case gives you better understanding where the defects are, but if there are many steps in total that means also plenty of test cases. You should really choose the approach that is best suited for you. For example in unit testing people tend to put only one use case (or assertion) per test case, but there's nothing really wrong if you don't do it that way. You should considered making these tests as easy and fast to execute as possible.

About styles verification: Do you feel that it is necessary? I would prioritize functionality above look and feel. You could verify styles by just looking at the application in question. Automating those tests can be quite a chore and hard to maintain. I would say that almost in every case it's not worth it.

In addition I would like to say, that validation logic could be easier to test with unit tests.

Answer 4

This is the general approach as you mentioned which someone has to follow to test some field. The high level scenario come in picture which you can cover with -

Phone Number Field

• Test all fields with blank input.

  Expectation : proper validation message (either text message in red color or highlight that textbox. its upto your form design )

• Input length validation (minimum and maximum required digit/characters required )

• Input character validation (weather allow numeric, alphabets, alphanumeric, special characters)
• Validation message (prompting user friendly message on wrong input dataset)
• Valid mobile number format (its up to your requirement specification weather mobile number allowed with country code)
• If is an Internationalize application then Phone number length vary as per country selection.
• Valid mobile number(number should be from valid operators)
• Negative values in phone number field
• If some authorization based on phone number which already exist in the system. then you must go with
  • phone number which is new/ doesn't exist in system
  • phone number which exist in the system
  • phone number which deactivated from the system

Also there are lots of cases for Email as well

• Email ids with different domain - you can find list of validation required for email over the internet
• Deactivated email in you system

And finally, see requirement document once and better to follow that one as what mentioned there and what really required. There may be some time constraint which has to follow.

Answer 5

I think you have to cover all scenarios using automation because you can handle every situation over there, Following are the situations you can easily handle.

If any field is empty and once you submit definitely there should be error message appears on UI, so you can handle this with selenium.

I suggest you handle all conditions using automation. Actually, there should be a probability that you can miss during manual testing.