Test Plan Instructions

This document describes the process for creating a QA test plan in Jira, and how to set up Test Cycles for use during QC and regression sweeps.

Create Test Tickets and Link Requirements

The first step in creating a test plan is to catalog what features need to be tested, and how they are expected to function.

The easiest way to obtain this information is consult the Product Owner’s user stories, as well as the design website at https://sites.google.com/a/vokalinteractive.com/

After inventorying what the site will be and what it will do, create Jira test tickets within the project for each major screen or component. It’s often helpful to create an individual ticket for each item listed in the Screens or UI Screens section of the design website. For app/sites that share a limited set of features across many screens, it may make more sense to create a ticket for each major feature.

When creating a test ticket, use a short and simple name. If matching tickets to screens listed on the design site, use the name of the section in the design site as the ticket name.

Examples:

• Screen: Login
• Screen: FAQ
• Feature: Calendar
• Screen: Admin > Login
• Feature: Admin > Events

In the description field, copy and paste relevant items from the User Stories, and links to the relevant design pages for easy access while writing test steps or editing the ticket in the future.

Finally, add an estimate for how long it will take to test the screen/feature in a single environment into the Story Points field in the Triage tab. It is recommended that tickets be broken apart to a degree that each estimate will be between 1 and 2 hours. Estimates can be edited later as the ticket changes.

It is not necessary to add granular test steps at this time.

Upon creating each ticket, it will have a Jira status of Drafting Ticket.

Assign Tickets and Add Test Steps

After the test coverage has been established, assign the tickets to the QAEs that will be writing the individual test steps. In most cases, this will be the same QAE that created the tickets, however it may sometimes be appropriate to request additional help when taking on extremely large test plans, or with an abbreviated timeline. Attempt to group similar features or screens together when distributing tickets to multiple QAEs to avoid duplication of effort.

Once all of the test tickets have been distributed to QAEs to write test steps, each QAE begins adding the information in the Test Details section of the ticket.

Each test case contains a Test Step, Test Data, and Expected Result.

Test Steps describe behaviors with predetermined results. Expected Results detail exactly what should occur when the action described in the test step is performed. Finally, the optional Test Data column lists any additional relevant information to be referenced during the testing process.

Examples of useful information to include in Test Data:

• The name of the current sub-screen/page that is relevant to the test case (if the test ticket is related to a single screen or page. For instance, if a series of 3 or 4 Forgot Password test cases appear on a Screen: Login test ticket).
• The name of the current modal or prompt that the test case pertains to.
• Examples of known settings/locations that apply to global test cases (for instance, if a test step is "View any month that contains an event," it can be helpful to list months that are known to contain events)
• General notes/tips on how to achieve the test step (for instance, if a developer is required to trigger an action, that would be noted here).

Whenever possible, use the first test case to establish the location of the tests. For example, the first test step of a "Screen: FAQ" test ticket should be navigating to the screen from a global location (like a navigation menu).

Additional test cases should flow from one to another whenever possible, with subsequent test steps beginning where the previous test case’s expected result ended. If it’s not possible to flow directly into a required test, establish the break in flow in the test step or with the Test Data (similar to establishing the starting location in the first test step).

In order to flow from one section to another more seamlessly, it is often helpful to take the "unhappy path" first, before progressing to the “happy path.” For example, when testing login functionality, guide the user through several validation error tests first, before flowing to forgot password functionality, then end with successful login tests.

Create Test Cycles in Jira

To generate test cycles, navigate to the project page in Jira, select Tests from the sidebar menu (wing icon), then select the Test Cycles tab.

Select the next version to be tested from the Select Versions drop-down menu then select +Create New Cycle.

For the name, enter "[version number] - [non-specific environment description -- IE: “Chrome"]”

For the environment, enter all environment details, including the OS, device (if application), and browser w/ version number (if applicable). IE "Mac OS X 10.10.4 - Chrome 43.0.2357.130" or “iOS 8.3 - iPhone 6 - Mobile Safari.”

To add tests to test cycles, selects the gear icon next to the title and select Add Tests. If several test cycles will share similar test tickets, it may be easier to create one test cycle, then clone it multiple times, changing the title and environment, rather than adding the same test tickets to multiple tickets several times.

After adding test tickets to test cycles, the cycles will appear in the Test Executions section of the test tickets, where they can be executed. Alternatively, tickets can be executed from the Test Cycles screen.