Our new QA section
explains how to make
your Website work the
way you need it to!
Fonts.com
 

2008


Home Page
Feature Archive
A&I Column Archive
Production Tools
State Marketing Data
US Marketing Data
World Marketing
Classifieds
Service Directory
Quality Assurance
3D Printing

Subscribe to Advertising & Marketing Review!
Contact Ken Custer at 303-277-9840.


Writing Thorough Test Cases


By G.E. Morris

In the previous example of testing a simple registration form (see Writing Repeatable Test Cases), only a small set of the possible test cases were used. In reality, testing a two field registration form might require dozens of test cases.

The reason for the large number of test cases is that it's a good practice to include field validation criteria for each field. Simply put, you want requirements and limitations put only the type of data you want inputed. A requirement might be that you won't allow the form to be submitted if either the first or last name is left blank. In addition, you want to limit the first and last names to 50 characters each. You might also want to limit the special characters that can be entered. A question mark would be prohibited, but a hyphen would not. In the cases where requirements and limitations are not met, an error message should be displayed telling the user what is wrong and how to correct it.

Examples of field validation criteria are:

  • First and last name fields are required.
  • First and last name fields are limited to 50 characters each.
  • First and last name fields will not accept numbers.
  • First and last name fields will not accept the following characters: `~!@#$%^&*()_:";'{}[]+<>?,./

Consider the following example:

Registration Form

Enter your first and last names and click the Submit button.

First Name:

Last Name:


Here’s a set of test cases that include validation criteria:

  1. Launch an IE browser and go to the Registration Form.
  2. Verify the registration page opens.
  3. On the registration page, click the mouse in the First Name field.
  4. Leave the First Name and Last Name fields blank and click on the Submit button.
  5. Verify an error message appears saying you cannot leave the First Name and Last Name fields blank.
  6. Enter 50 chracters in both the First and Last Name fields.
  7. Verify the names are accepted.
  8. Enter more than 50 chracters in both the First and Last Name fields.
  9. Verify an error message appears saying you cannot enter more than 50 characters in the First Name and Last Name fields.
  10. Enter numbers in the First and Last Name fields.
  11. Verify an error message appears saying you cannot enter numbers in the First and Last Name fields.
  12. Enter the chracters "`~!@#$%^&*()_:";'{}[]+<>?,./" in the First and Last Name fields.
  13. Verify an error message appears saying you cannot enter "`~!@#$%^&*()_:";'{}[]+<>?,./" characters in the First and Last Name fields.
  14. Type “John” in the First Name field.
  15. Click the mouse in the Last Name field.
  16. Type in “Doe” in Last Name field.
  17. Click on the Submit button.
  18. Click on registration List in the left nav bar.
  19. Verify the Name “John Doe” is now present in the registration list.

Even the above set of test cases takes a few shortcuts by testing validation on both fields at once. A more correct way to do it would be to test the field validation independently.

For example, the blank name validation should be tested like this:

  1. Leave the First Name and Last Name fields blank and click on the Submit button.
  2. Verify an error message appears saying you cannot leave the First Name and Last Name fields blank.
  3. Enter a valid First Name and leave the Last Name field blank and click on the Submit button.
  4. Verify an error message appears saying you cannot leave the Last Name field blank.
  5. Enter a valid Last Name and leave the First Name field blank and click on the Submit button.
  6. Verify an error message appears saying you cannot leave the First Name field blank.
As you can see, this increases the number of test cases needed substantially, and even this set of test cases leaves certain issues untested.

For instance, the form should also be tested for resistance to what is known as HTML insertion attacks. If not handled properly, HTML code entered into a field will be displayed on the page when the submit button is clicked. I was working at WebMD when I first ran into this issue. Someone on the QA team discovered it and most of the QA team spent the rest of th eday trying insertion attacks at Websites like AOL, Yahoo! and MSN. Some of the major Websites did prove vulnerable, and strange messages showed up on their pages for a few days. Most code written now will handle insertion attacks, but it's always a good idea to verify that. Here's a test case for insertion attacks:

  1. Enter the text "<B>This is a test! </B>" in the First Name field and hit submit.
  2. Verify the text "This is a test!" does not appear on the registration page.
The final set of test cases could easily exceed forty steps. While this may seem like a lot of test cases for a two field Web page, cutting down on the test cases could mean both lost sales and lost credibility. The resulting cost could easily exceed the cost of proper testing. An experienced tester would have no problem quickly and efficiently writing all the appropriate test cases, and would be able to execute thme quickly and efficiently as well.


For more advertising and marketing help, news, resources and information visit our Home Page.


Back to top



QA and the Software Development Lifecycle

CMMI Levels

Writing Repeatable Test Cases

Writing Thorough Test Cases

Writing Product Requirement Documents

Basing Test Cases on Requirements Documents

Test Case Formats

Multipart Test Cases



Constant Contact -- FREE Email Marketing

null