Terms and Concepts
Glossary
Before you begin, here’s a quick run down on all the major terms used by Zephyr Squad Cloud. Please read this first, it will make navigating the user interface and using the application much easier.
Term | Description |
|---|---|
Test | A test case. This is a detailed step-by-step description of what should be done to test something. This can be as high level or detailed as possible, with links to requirements, lots of properties, execution history etc. In Jira, its a standard issue-type. |
Test Summary | High level summary and counts of all the tests that have been created in a particular project, grouped in various ways. Accessible in a Jira project via the navigation tab on the left. |
Cycle Summary | A grouping of executed or unexecuted tests (e.g. "Functionality", "Regression" etc.) More than one test cycle can exist for a Version. |
Execution | When a test is run and its result or status is recorded. |
Ad-hoc cycle | If no Test Cycles have been set up for a Version, then any test which gets executed is reported against an "ad-hoc" cycle. This is the default cycle. |
Unscheduled Version | If no Versions have been set up in Jira, then a test will belong to an "Unscheduled" version by default. |
Execution statuses | Pass, Fail, Blocked, WIP (Work In Progress), Unexecuted are default statuses. Custom statuses can be added. |
Version | The Version set up in Jira. Tests need to belong to Fix Version/s. The Affects Version/s is not used. |
Component | The Component/s set up in Jira for that particular project |
Label | User generated Labels |
Workflow | The Test issue-type has the default issue workflow |
Your Test Process
 |
There are many ways you could use the testing related functionality in Zephyr Squad, be it for project teams that have well established test processes or those just beginning to implement one. Here are some examples of test processes that you could follow while incorporating testing into your project. You can also come up with your own test process based on what suits your project team best.
Starting with a Simple Test Process allows you to create or clone an existing test, immediately execute it, file a bug and check out the metrics gadget to keep track of your testing. This is the simplest way of using this application and no prior planning is needed.
A Test Process with Basic Execution Planning essentially lets you group your test executions into Test Cycles so that you can keep track of what has been tested, what is passing/failing, how much is left etc. It involves very basic planning in setting up Test Cycle(s) in a Version and then making sure that every test execution is recorded against those Test Cycle(s).
The next level is a Test Process with Structured Execution Planning. This involves setting up Test Cycle(s) and also getting into a process of creating/modifying a large number of tests, adding them to the appropriate Test Cycle(s) for future execution and then executing them during the dedicated execution stages of your project.
A Structured Test Process, as the name implies, allows for distinct phases of organization, planning, execution and tracking of all your testing efforts.
During the organization phase, tests are imported, reused, modified, cloned or created. They are linked to requirements, stories, epics or other issue-types. They are organized by Versions, Components and Labels. During the planning phase, various Test Cycles are set up and tests that need to be executed are added to these cycles. This kind of grouping allows for easy progress tracking.
The execution phase is all business, with users methodically executing tests within the various Test Cycles, linking to existing bugs or filing new ones, tracking progress etc.
Tracking happens continually with metrics showing in the Test Metrics keeping track of the organized tests, Test Cycle summaries showing progress of the execution, execution metrics keeping track of the quality of the software and detailed reports in various formats available for consumption by a varied audience.