Features
Lab Management - If you run automation from your test case database, your going to need to know what machines are in your lab. This is where the real cost savings of an open test case database comes in. Most commercial products want to charge you per user, and per client that runs their own automation software. Besides the fact you always have to customize something on the automation part, you end up paying way too much for organizing something fairly simple. We allow you to define the machines in your lab, what os and version they are running, architecture they are running on, and define customized "states" for them. Want to write your own automation system to integrate with OpenTCDB? Great! so do we, we'll probably write several ourselves. The real issue here is one size definately doesn't fit all!
Notes - Sounds silly, but can be very useful. Instead of comments, which can encourage personal views that don't necessarily relate to the matter at hand, we allow for notes (think sticky notes) to be attached to features, test objectives, test cases, etc. Notes are to be factual information extensions to the description already provided.
User rights and Roles - Realizing that some people need to be on multiple projects, and that others shouldn't even see a project other than their own, we've designed a set of rights and roles that are assosiated to a user by project. So while one user may be a lead on project a, he's got only read-only access to project b. The rights system is very fine grained so that you can have testers with varying levels of ability in the tcdb. This promotes good practices for and mirrors the way test teams are usually run.
Action Items - Action Items are best described as a todo list. It doesn't necessarily mean testing, but everything else associated with the job. Need a tester to fix one of the machines in a lab? Assign an action item. This helps testers have a definitive list of things they should do, and leads/managers to keep track of what they have assigned.
Generalized non restrictive workflow (traditional and tag based) -
We aren't going to force you into our way of testing. Our goal is not to model the testing off of the database, but model the database off of the testing. The concept of features, test objectives, and test cases is somewhat universal. No special tricks. However, that's not the only way that you can organize test cases. We allow "tags" to be attached to test cases. Tags are defined by project administrators, and can help you organize in any number of ways. Test cases can have any number of tags, allowing it to be catagorized in more than one way.
This is in contrast to the way most test case databases organize test cases into filesystem like folders. With that kind of system you can only find the test cases, and organize them in one way. This may not seem very important with 20 test cases, but if you get into thousands of test cases, it can be a real problem.
My Assignments - When a tester logs into the tcdb, they are greeted immediately with the assignments that they are supposed to accomplish. No searching for what you need to do, your test lead has assigned you tasks (either action items, or work orders). This also allows test leads and managers to easily track the progress of the team(s). See the workflow section for more information about action items and work orders.
Tracking of features, and test objectives - Most test managers want to be able to see the coverage of certain features, especially features that have a high risk of problems for the release. OpenTCDB will track features per product, per version. Also test objectives can be associated with features. This allows testers to come up with ideas on how to test a feature, even when they don't have the process down for the individual test cases. This will allow the maximum amount of innovation amongst test teams.
Work orders - Work orders (we know the name is a bit stuffy) are a way for test leads/managers to define that they want testers to test something. Different from action items in that the progress on a work order is determined by the number of passes and failures reported. Each work order consists of a selection of test cases on a particular platform (os, version, architecture). Work orders can be templated so that after a new build, one click will assign the work as previously defined.