CSE 270: W07 Lab: Test Cases

Starting with a web application of your choice, generate a dozen test cases.

Select a Web Application

With your partner(s), select a web application. This web application should be substantially more complicated than the calculator used last week.

You may choose to use a web application that you built for another class, or perhaps something you worked on for a job. If you and your partner(s) do not have such a project, then you may select a web application that you periodically use.

One important note: Make sure that your partner(s) and your instructor has access to this web site. Something that sits behind a password or a firewall would not be a good choice for this assignment.

List Requirements

List four requirements that would be applicable for the web application you choose. If this web application is from a class assignment or from your employment, then you may have actual requirements to work with. Otherwise, you will need to generate requirements of your own. An example requirement would be the following:

The [Submit] button can be accessed through a mouse click or by hitting <Enter>.

Generate Test Cases

Using the reading as your guide, generate a dozen test cases to thoroughly test your selected requirements. These test cases must meet all the criteria for good test cases, and contain all the necessary information.

Note that a template and an example are not provided. You and your partner(s) will need to figure out what constitutes a good test case. Please consider sending a draft of a test case to your instructor for feedback.

Test Case Plan Format

This Test Case Plan will be one document containing 12 test cases. You will need a title page, a introduction page, followed by each of the test cases.

Each test case must consist of the following components:

  1. Test Name: Just like naming variable, function, class and variable names, a title should describe the test.
  2. Test ID: The ID uniquely identifies the test from the other tests. An id might include a relationship to the component or unit of the program and the version of the test.
  3. Purpose/Description: As with any documentation, you need to state the purpose or decription of the test.
  4. Verification Requirement: What is this test going to verify? The feature requirement, story, or quality statement that this test is meant to verify. As part of this assignment your requirement should be a non-functional requirement, based on a quality characteristic. If the test is verifing more than one, the requirements need to have a unique identification.
  5. Outcome: What is the expected outcome? What should the person conducting the test look for?
  6. Pre-Conditions: Before starting any set of test steps, there are typically setup instructions, pre-requisite or dependancy tests, i.e. initial system test case. Sometimes it is simple as stating any assumptions about the starting state of the system or application you are going to test on or with.
  7. Steps: The steps one must perform to carry out the test. These steps must be precise, so anyone can conduct the test the way you envision. Remember to use the Action/Result or Action/Verify pattern.
    1. Action Step: What is the testing going to do. It should provide a target and an action. There needs to be enought detail that grandma would know what to do.
    2. Results Step: After each step, there should be something that happened. You push a button, or click a link; the results is the effect of that action. In more detailed test cases, the plan would present two areas for results, expected and actual. The tester executes the action, checks the expected results, and if it is different they fill in the actual results. Since most test case stop when the actual results is different then the expect, for this exercise we are only worried about expected results.
    3. Pass/Fail or Verify Step: Verify Step is used to determine if the set of Action/Results steps have verified the requirement. Depending on the format of a test case plan, this is a simple indication of the Results passing or failing. The main thing to note is that Verify replaces Results and is tied to the requirement.

For example, here is a test written for Internships:

 

Submission

Your team will submit a single document for your test cases. The document needs to be in the PDF format. It must consist of the following components:

  1. Link: Provide a link to the web application to be tested.
  2. Requirements: A list of all the requirements that are to be tested.
  3. Test Cases: At least twelve complete and high-quality test cases.

Assessment

Your submission will be evaluated according to the following rubric:

  Exceptional
100%
Good
90%
Acceptable
70%
Developing
50%
Missing
0%
Selection
10%
The web application selection is an excellent choice Test cases can be generated from the web application The link to the web application does not work A link to the web application was not presented
Requirements
20%
It is easy to see how each requirement will be tested Four testable requirements were listed Four requirements are listed, but not all are testable At least one testable requirement is listed No testable requirements are listed
Test Cases
60%
There is no room for improvement in the twelve test cases Twelve well-defined test cases are present A few minor errors or missing information exists At least one well-formed test case exists No test cases are present that can be used to generate automation
Professionalism
10%
The report is professional, easy to read, and all the ideas are clearly communicated The writing style is "professional:" there are no grammar, spelling, or formatting errors There exists an instance of a spelling error, grammar error, overly verbose wording, poor formatting, or poor writing Multiple spelling, grammatical, formatting, or writing errors Gross spelling/grammar errors or other aspects of the writing that make the report difficult to read