Gemini Community Support Site

This Gemini community support site can be used to find solutions to product issues. You can log in using Open Id, Google Profile and even Facebook. Feel free to ask a question or browse FAQs and documentation. Product tour videos are also available along with how-to videos demonstrating key Gemini capabilities.

How to use Gemini: test resources for mixed teams


We've recently upgraded our Gemini to version 4 (from 3). As a part of this move to the new version I'm trying to establish a more "correct" use of all fields and features of Gemini. So far so good.

One problem remains however, which I can't seem to find a 'correct' solution to. The problem is as follows.

We have a team of about 5 developers, and 5 business users. Testing is currently divided about 50/50 between devs and business users. However, we do recognize a developer shouldn't test his own work, so each developer has to test a few issues done by others. Let's take a simplified/smaller example:

Dev A has done issue 1001 and 1002 Dev B has done issue 1003 and 1004 Dev A has to test issue 1003 1001, 1002, and 1004 are tested by business users

As an additional constraint to our use of Gemini we never take an issue "off" the person who developed it. So 1001 and 1002 always stay on resources=devA, and 1003/1004 on devB.

The problem that now arises: how do we indicate that 1003 should be tested by Dev A? Solutions we have considered so far all have a problem:

  • Add DevA as a resource to 1003. This has a few big disadvantages. First: the "My Work" list for DevA is now mixed between test work and dev work, meaning you can't easily see which items require action on your part ("Ready for test" requires work only if you're the tester, but not if you're the dev). Second, if an outsider looks at 1003 it's not clear who is the dev and who is the tester.

  • Use test plans. Disadvantage (but perhaps I misunderstood this feature) is that you can't quite make a test case saying "Test issue 1003" with a real link to 1003. You can only put it in the text of the test case. Another major disadvantage: you need to create one test case per issue.

  • End each title with text " (tester: xxxxx)" and have each dev make his own filter showing those issues (thus keeping his 'My Work' screen clean dev issues). Disadvantage: no hard resource assignment, and manual updating to keep track of this.

  • Next to the "Resources" property of an issue we could use the "Test resources" property. Disadvantage: this property doesn't exist :D

As you can tell, i'd prefer to have something according to the last bullet. Am I missing something? Or is our current setup (third bullet) the most practical solution?

Thanks in advance for any replies!

· 1
Replies (1)
not helpful

We suggest using test cases for this. You can associate each case with one or more items by adding items against it in the items tab. That way you have full trace of what is being tested and by whom.

Mark Wing
· 9108
Mark Wing