Writign Web Form Test Case

Question

I'm not a software tester, but have been tasked with writing manual User Acceptance test cases for some long customer signup forms for a web application.

Is the starting point that we assume all the form fields are 'there' for each type of form, and that the test cases begin with the checking of the form functionality e.g. input validation etc. Or, should I write a test case to check each form identifier is correct, each form field is present, each drop down is populated etc (I guess when a new build is produced its possible a form element/field could have a error - although unlikely).

If I am going to write a test case for lots of form elements can I use multiple assertions to save time e.g. "Check Identifiers: text1, text2, text3, etc are present and correct." Or should it be one test case for every element of the form. The forms are unlikely to change much over time.

I get the feeling that there are 2 types of test here - one that the form functions correctly, the other the component parts are actually displayed correctly by default.

Thank you.

Answer 1

You can write for this task two types of tests (as suggested by Min P. and Dobromir Manchev) and as how much detailed test cases should be, depends on fact who will perform your test.

I would personally prefer to check each case separately and it is easier to pinpoint issue and to eventually retest it.

Scenario 1:
Test 01 - Username field - Description - Expected
- You test location, dimension, color and something like that
Test 02 - Username wrong data - Description - Expected
- Check if this field accepts type of data that is not supported (long, short, special characters etc)
Test 03 - Username blank input - Description - Expected
- Check if field support empty submission
Test 04 - Username correct - Description - Expected
- Eventually what if data is correct and how it behaves
Test 05 - Email field - Description - Expected
- You test location, dimension, color and something like that
Test 06 - Email correct form - Description - Expected
- You check if field support only correct email form like name@mail.com and correctly handles name@mail, name@mail. etc.
Test 07 - ...

Scenario 2:
Test 01 - Username field - Description - Expected - Feedback
Test 02 - Email field - Description - Expected - Feedback
Test 03 - ...

As for the Description it is up to you to fill this field, either with short description in which you will describe what is the test case objective or with very thorough. In expected field you need to write what will exactly expect to be the outcome of that particular test. In scenario 1 it should be simple task (check this, result that) and in scenario 2 you will test generally if the field is correct in any way and expect proper feedback in order to fix the issue.

Second scenario is easier to write but flaw is that you expect precise information and feedback from someone else (which can always bring unsatisfying, insufficient or result that vary).

Hope this helps a little bit more.

Answer 2

It all depends on the requirements you are working with.

If you can be SURE that all the fields to test are there (or if this is not the point of your test because someone else is testing this), you shouldn't bother testing it.

If you are testing the whole thing, meaning that everything a) works and b) works as intended, then i suggest you split your tests in two - one part that simply checks the form, content etc of the page and it's elements and a part two that considers everything's there and tests if it functions correctly. Part two will then contain field verifications like "enter invalid email", "enter letters in a phone number field", "leave a mandatory field blank" etc.

For practical reasons i try to keep my tests as short as possible and as specific as possible. Here's a few reasons why:

• If you find a bug, your whole test case will be "failed", it's clearer later on to find what's working and what not if the test case doesn't test many functionalities that are not tightly connected. If you take your need for example, if you test the existence AND the functionality of your fields in one test and one step doesn't work your test will be "failed" but by glancing at your test campaign you won't be able to know which part has a bug without going deeper and examining the execution in detail.

• If you have to come back to re-test something after it's been fixed you won't have to go through dozens of steps before you are able to verify the correction.

• People tend to lose focus if they have to execute a very long test case, they might forget what's going on, etc.

Of course, this depends a lot on the task at hand, some things require much longer/complex test cases, others can be very simple.

Hope that helps

Answer 3

UAT, ime, should include the complete steps that the actual end user of the app would perform according to your scenarios, from start to finish, and also including expected and actual results in the tcs, e.g.

step 1. open browser/browser is launched, step 2. go to www.blah.com/blah.com is loaded, step 3. click on login field (if you need to get specific) and enter username/field is selected and username is entered.....all the way to the end path you need to test.

You should have performed your functional tests before running UAT cases so you don't necessarily have to validate each field in UAT tcs but make sure you or your team is smoke/functional testing before UAT.

I also agree with the previous poster regarding splitting up your test cases into specific parts which of course depends on what you're doing exactly. TC1_Navigate to Page TC2_Login TC3 Fill PersonalInfo(Or by form section) TC4_Fill IncomeInfo...blahblah.

For each tc after the first one, you can continue from the last tc's step, you don't have to start each test case after #1 from "open browser", and include all the tests together as one test set which will be comprised of the multiple testcases.