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.
- The title page consists of the name of your website, not the url, followed by "...Test Case Plan", and all members of your group.
- The Introduction Page will give a brief description of your project, location, and a list of tests found in this document and the expected outputs. You should mention any required dependancies, pre-requests or any thing else a tester might have to assume or setup to get the system or application ready to run your tests.
Each test case must consist of the following components:
- Test Name: Just like naming variable, function, class and variable names, a title should describe the test.
- 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.
- Purpose/Description: As with any documentation, you need to state the purpose or decription of the test.
- 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.
- Outcome: What is the expected outcome? What should the person conducting the test look for?
- 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.
- 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.
- 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.
- 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.
- 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:
- Test Title: Internship Registration Approval.
- Test ID: CSE-398-Internship_Approval-2022.02
- Purpose: How to register for the internship class
- Verification Requirement:
- Requirement Example: Students shall request approval for a job in order to register for CSE 398
- Story Example: As a student, I want my internship job to be approved so that I can register for CSE 398 Internship
- Pre-conditions:
- Web Browser with connection to byui.edu
- An identical request has not been made.
- Steps
- Action: Log into iPlan.byui.edu
- Results: Browser is open with a web page
- Action: Click on the Internship Approval panel link
- Results: The internship Approval page shows up
- Action: Click on the “Create an Internship Request” link
- Results: The internship Registration Information page appears
- …
- Action: Look over the form to see that you have to fill out all of the required fields, then press the Submit button.
- Verify: Form is submitted and shows up on the Internship Approval page
- …
- Action: In two days, check back to see if the request has been approved.
- Verify: When the time for registration occurs, it is possible to register for CSE 398
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:
- Link: Provide a link to the web application to be tested.
- Requirements: A list of all the requirements that are to be tested.
- 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 |