Knowledge Base

When testing, there are four required levels of hierarchy; these are from the top-level down.

• Test Plan: A high-level grouping of Test Cases
• Test Group: A breakdown/organization of Test Cases inside of a Plan
• Test Cycle: Could represent a build, release, or a unit of testing
• Test Run: An individual execution of a Test Case inside of a Cycle

Some business rules that apply here:

• Test Plans and Test Groups can have only one instance of a Test Case.
• Test Cycles must be created in order to execute Runs.
• Test Run results can be recorded only once per Case per Cycle.

Either a creator or a Test Runner license with create/edit permissions at the Project Level is needed to create Plans. Executing Runs requires a Creator or a Collaborator license with read permissions to the Project.

A Test Run is an item derived from a Test Case. This means that the core information, Name, and Description, are copied from the Case into the Run. However, no relationships are transferred, nor is a relationship created between the Case and Run. Please see this article for more details on this relationship.

Test Runs are derived from Test Cases; however, they do not inherit all core fields or custom fields. To see how to work around this, check out this article.

When you create a Test Cycle, you are choosing to execute tests based on related cases in Test Groups. The Cycle is like a snapshot of the Test Cases included in that Group or Groups. This means that the Test Runs included in the Cycle are essentially copies of the Cases as they existed when the Cycle was created.

It is not possible to add individual Test Cases to a Cycle; they must first be added to a Test Group (although there is nothing that will prevent you from creating groups of one.) Note that Cases can exist in just one Group per Test Plan.

The Run will remain in your Test Cycle unless you do one of two things:

• You can delete the individual test run from the cycle. Select the ID of the run in the Test Runs view. You'll be taken to the Single Item View of the Test Run and, from there, you can select Action > Delete.
• If the Run has not yet been executed, you can edit the Cycle and remove the entire Test Group from the Cycle.

The Test Case Status is a unique field calculated with the results of the Test Runs derived from that Case. It is not something a user can update because it considers a number of things, including the "priority" of individual test RUN statuses (which takes precedence when calculating the CASE status), whether Test Plans are archived, whether a setting in Admin "Include Unexecuted Test Runs in Status Calculations" is checked, etc. To learn more about how this status is calculated, check out this post.

As noted previously, the Status is a unique calculated field. You won't be able to add another value in this Status Pick List because it is tied directly to the functionality of the Test Center. As a workaround, we recommend adding a custom field or Pick List to the Item Type. Just note that, if you add a custom field to the Test Case Item Type, it will not be inherited by the Test Run.

It depends on the end results you need for reporting. The easiest thing to do is to structure individual Test Cycles for each browser; the catch with this method is that, because the Test Runs are tied to the same Test Case, the Case Status will not reflect individual browser results. Given this, it is common for software companies developing on multiple platforms or browsers to create a Case for each configuration. Reuse can come in very handy here! For more on the topic, check out the thread regarding variations on a Test Case.

If you have enough Test Groups in your Plan, Jama will start hiding the visible cases to ensure Groups remain visible. If you run into this message, check your Groups to see if there is a More... link visible.

If a Test Case has been edited since a Test Cycle was created, a pencil icon will appear next to the Test Run. You can then opt to "Make Test Runs Current," which will update the Name and Description fields in the selected Runs to match the Case. Note that the result of the test will be reset to Not Run.

Jama does not offer an integration with Selenium. However, we do have a REST API that allows you to update the status of Test Runs with relative ease.

The easiest way to import Test Cases is via Excel spreadsheets, as importing via API does not allow the creation of Test Steps. To see a walkthrough of this process, check out this article.

When you have completed a Test Plan but need to maintain it for your records, you can archive it. This means that Test Case statuses will no longer be affected by the result of the Test Runs in the Plan.

Because Test Plans are not items that live in the hierarchy, they cannot be sent to the Test Center. However, you can create a filter that pulls your particular cases from the Plan and then create a review based on that filter.

By default, the Name and Description fields of Cases can be visible within the Review Center. Find out how to add them.

An expert Jama consultant, Dennis Hodge, answered customer questions during an "Ask Jama" session, and that can be viewed via this link. Additionally, the User Guide will walk you through creating a Test Plan