3.3		The View Item Page	usage projects
6.1		Introduction to Sentry	usage testing
6.2		Test Cases	usage testing
6.3		Test Plans	usage testing
6.4		Test Runner (Executing Tests)	usage testing
6.5		Test Run History	usage testing

6 documents found.

Test Plans link together a number of Test Cases and form the basis for the execution of a Test Run. As with Test Cases, Test Plans are delivered as a Gemini Project Template and therefore their structure and workflow are as flexible as you could possibly wish them to be.

The standard Test Plan model is contained in the Project Template called “SENTRY”. It is recommended that if you wish to modify your Test Plans (or Test Cases), you duplicate this Template, creating a new one so that you always have the baseline as a point of reference.

Test Plan Apps

Test Plans contain 4 Sentry Apps: Test Runner, Plan Test Items, Test Cases and Test History. All are mandatory for testing to be fully functional.

Test Runner

The Test Runner is used to initiate new tests and stores incomplete tests and allows their continuance or re-execution.

Plan Test Items

Plan Test Items are Issues to be tested. They cannot be added in Test Plans, instead they are represented in the Test Plan as an amalgamation of all the ‘Items’ selected to be tested in all of its Test Cases.

Test Cases

This app shows the Test Cases assigned to this Test Plan and allows you to add or delete Test Cases from the Test Plan

Test History

This app provides a full audit trail and traceability (linkage of items in Gemini with tests, whether the items represent things to be tested or bugs/issues raised during testing).

The Default Sentry Project Template

The default Sentry Project Template (“SENTRY” in the Project List) has the following characteristics:

• The generic Gemini term ‘Item’ is replaced by ‘Tests’
• The default view is of the Grid, which will therefore show a list of Test Plans and Test Cases under the heading ‘Tests’
• Also included in the Template are the Planner, Activity, Timeline, Calendar, Documents and Reports but you can measily customize the menu to your requirements
• There are a number of Custom Fields defined that might wish to customize:
  • Affected User(s) – multi-select User Picker – you should select the User Groups that can be searched for users
  • Client/Project – drop-down list delivered as static – you might wish to use a SQL table lookup, at the very least you will need to change any data supplied
  • Expected Results – rich text – this is for a description of expected results against Test Cases
  • Pre-conditions - rich text – this is for a description of pre-conditions against Test Cases
  • Test Type – a drop-down list of various out-of-the-box Test Types (regression, boundary, validation etc.) – customize as appropriate for you

Usage Tips

Working with a list of Plans and Cases

Gemini will display any Test Plans and Test Cases you create in a list by default. To distinguish between Test Plans and Test Cases they are represented by different icons but you might wish to:

1. Sort by Type
2. Put Test Plans in the Sequence Zone

(See The Grid for more information on the default grid view and its features).

Setting up defaults

You might wish to set defaults for the data fields that you use for testing (Priority, Severity, Resource(s) etc.). To do this, navigate to your testing project and on the project menu select “Settings…Defaults”.

Recording issues in testing

You can raise a bug/issue/task when a test fails. Because of Gemini’s incredible flexibility you can raise whatever type of ‘item’ you like in any project that you have Create access to. This includes your own testing project. Just because Sentry does not come with additional Types does not mean that you are not free to add them. For example you could add the Type “Defect” to your Sentry-bases (or original) Template so that when you raise an issue in testing you can create the “Defect” in the same project.

You do not have to follow the example described above and can always select a different project and a Type (e.g. “Bug”) that exists within that project. For example if you wish to flag up a bug to the Software Development team and they work in a different project then provided you have rights to create items in their project(s) you can raise the bug found in testing directly.

Finally, regardless of where you raise an item, Gemini will let you move it to another project and/or another Type. You could, for example, create a “Defect” in your testing project and then, in a post-testing review, decide that it should be escalated/moved to another project/Type. When you move an item, Gemini respects the destination project/Type and prompts you for the appropriate data. Fields that are on the source but not on the destination will simply be hidden but the values will always remain.

Using AppNav Cards

If you wish to remember which Test Plan or Test case you are working on simply create an AppNav card to mark your work. You can share Test Plans and Test Cases using AppNav card sharing and you can see if other people make changes to Plans and Cases that you are interested in using the AppNav badge notifications and email subscription.