This new branch reflects an architectural change we decided to make last November.  We have moved the project to be purely Django.  This has simplified everything from deploying the product to developing new features and we’re really excited about it.

Along with the architectural change, we have added a bunch of improvements “while we’re at it.”  For a complete list, look in the “Done” section of our Pivotal Tracker page.  But to name a few:

• Re-work of the UI to make it cleaner and clearer
• Lists are now default ordered by creation date to make it easier to find your new items
• Test Cycles are now Product Versions (I’ll blog on this in a later post)
• Test Case versions are now directly mapped to the Product Version to make it clearer just what a Test Case version means.
• You can now create a test case with no steps, if you like
• Documentation! (as mentioned here in last blog post)
• Soft-deletes as well as Cascading deletes.  If you decide that you don’t want an old project (or anything else) in the system any longer, you can delete it and all the Versions, Cases, and Suites go with it.  If you deleted it by mistake, you can undelete it in the Admin.  Speaking of the Admin…
• Django Admin!  Now that we are pure Django, you can access the admin by the URL: <yourdomain>/admin/.  Not surprisingly, only users with admin privileges can use it. 

Upgrading from 0.7.X

If you have been using the 0.7.X branch version of Case Conductor, one thing that may be obvious is that the move to pure Django means a big shift in the database schema.  This was a fairly unavoidable change to bring the schema into the Django best-practices and conventions.  So installation of 0.8.X will need to be a new installation, with a new database.  And then you’ll need to migrate your 0.7.X data.

Here’s how:

1. Upgrade your existing installation to the 0.7.1 branch.  This will add a new management command to extract suites and cases for your existing data:

   cd <your github repo>
   git pull
   git checkout 0.7.1

2. For each product you want to migrate, extract the suites and cases to a .json file:

   ./manage.py export_cases "My Product" > myproduct_tests.json

3. The 0.8.X data structure is different enough that you will need to recreate your Products, Product Versions, Environments and Users in the new UI.
4. Import your “myproduct_tests.json” file into the new 0.8.X branch.  The command is called “import” and the parameters are <product> <prouct version> <file.json>:

   ./manage.py import "My Product" 1.0 myproduct_tests.json

If you run into any problems with your upgrade, please either comment here, or come visit us on irc at irc.mozilla.org #caseconductor.

Thanks,

-Cam

One day after having one such discussion, Carl Meyer, (our lead developer) decided that perhaps these design decisions would be best preserved in documentation.  What a concept!

There is a great little site out there for hosting documentation called Read The Docs.  Setup is incredibly simple.  Just follow the instructions here: readthedocs.org.  When you tell it your repo location (github, mercurial, subversion or bazaar), any time you check in new docs, they are automatically built to the site and you’re done.

So, over the weekend, Carl followed the above instructions to get setup for RTD.  Then he gathered a bunch of our design decisions, composed them in reStructuredText format and checked them into our repo on github.  Awesome.

You can find our current Case Conductor docs here: Case Conductor.  It’s not complete, but it’s a work in progress and it reflects the decisions we’ve been making on how things work in Case Conductor.  So, now as we have these discussions and make decisions, we immortalize them in the documentation.  It’s so easy to write them in this format, that it becomes just as easy to take notes right in the docs as it would in Evernote or a Tracker story.

Sphinx and reStructureText are used as the formats for the documentation.  This ends up being a very simple combination. Even reference links are easy to define.

For example:

Test Cases and Suites
=====================

.. _test-cases:

Test Cases
———-

A **Test Case** is a named set of steps for testing a single feature or
characteristic of the system under test. Test cases are associated with a
:ref:`product <products>`, and can have one version per :ref:`product
version<product-versions>`. They can be organized via :ref:`suites
<test-suites>` and/or :ref:`tags<tags>`, and can have file
:ref:`attachments<attachments>`. Preconditions, assumptions, and other
preliminary information can be provided in the case’s *description*. A test
case can have any number of steps; each step has an *instruction* and an
*expected result*.

Becomes:

While some editors support formatting reST documents, we have actually found it easiest to just build the docs and view them in Firefox.

make html

That’s all it takes, and you can view your docs locally in all their grandeur.

One of the other things I really like about this approach rather than a traditional Wiki is that your docs are with your code.  You don’t have to go to 2 different places and use an online text editor to update what you’ve done.  You can use TextMate, or Emacs, or whatever your editor of choice is, and check in the doc changes with the code changes.  Simple.

This branch has lots of new fixes in it. And this is the build we are going to be working with in-house through the end of the year.

You can see a list of the “done” items on our Pivotal Tracker page here: https://www.pivotaltracker.com/projects/280483

But a couple items worth noting are:

• You can now filter test cases by tags and author
• % complete for Test Runs is now accurate.  We removed it for Test Cycles because, in hind sight, I realized that Cycles are going to continue to grow over their life.  So % complete just doesn’t really work well for them.
• You can now use filtering when creating an Environment Profile
• Several other bug fixes

Going forward

We have decided to make a big architectural change.  We are going to take the remainder of 2011 and convert the whole application to pure Django.  This shouldn’t affect very much of the UI, but will make it lots easier to implement new features, and make the architecture easier to understand and work on in the open-source community.  Not to mention, this will make it easier to setup and run the application itself.

We’ll keep you posted on our progress on this front.  Please post a comment here or on http://groups.google.com/group/case-conductor

Thanks, Cam

To check out our latest updates, please checkout this latest branch: 0.6.X.  We’ll continue updating it to fix bugs as we go, of course.

If you don’t have the repo yet, you can get it with this command:

git clone git://github.com/mozilla/caseconductor-ui.git

If you already have the repo cloned, you can get this branch by typing this from within your repo:

git checkout -b 0.6.X origin/0.6.X

Have fun, and let me know how it goes!

-Cam

You may have seen some announcements about Case Conductor from uTest:

• http://www.marketwire.com/press-release/utest-and-mozilla-launch-beta-of-caseconductor-for-test-case-management-1577217.htm
• http://blog.utest.com/utest-and-mozilla-release-beta-version-of-caseconductor/2011/10/

While Case Conductor is an early beta and still rough around the edges, we’d love your feedback on a few of the features we’re working on:

1. Test case entry: we support both single and bulk test case entry.  Our bulk entry form takes a Gherkin-ish style of language (other formats to come).  Testers like to write tests in many different styles.  A form works great for many people.  Others prefer something more free-form.  Our goal here was to allow you to create lots of test cases in the text editor of your choice being able to cut-copy-paste to your heart’s content..  Then when you’re ready, you just enter them in bulk.  For now we only have one syntax we accept, but your input on more syntax styles (like Markdown) would help.
2. Filtering: when you’ve entered things like test cases, test runs, test cycles, etc, you can find what you’re looking for on specific pages by using our filtering.  See how you like it and let us know.
3. Managing environments: A testing compatibility matrix can be hard to keep track of.  And they can get HUGE.  These days, it sometimes just isn’t possible to test EVERY possible combination.  We have added the ability to provide all your environment parameters for your product, then you can pick and choose the ones you ACTUALLY want to test.  Narrowing this down allows your testers to focus on what are your core concerns.

We are really excited about the direction of the product and what it does (and will) have to offer.  Test case management systems have been too cumbersome in the past.  We want to change that.  In the coming weeks, we’ll continue to evolve the product.  I encourage you to play with it and give us feedback on what you like and what you don’t.

How do I get it?

You can fetch what you need from github here:  https://github.com/mozilla/caseconductor-ui/tree/0.5.X.  You’ll notice this is the 0.5.X branch. Feel free to check out the master branch, but there will be several features in partial completeness. This repo includes a pre-built version of the platform in “tcm.war” which is ready to be dropped into your JBoss installation.

The two README.rst files should give you all the info you need.  There are two separate parts, each with their own readme:

• Platform: https://github.com/mozilla/caseconductor-ui/tree/0.5.X/platform
• Django UI: https://github.com/mozilla/caseconductor-ui/tree/0.5.X

We’d love to hear your feedback!

Please feel free to post comments to this blog, and/or enter bugs and feature requests in Bugzilla with this link.

Thanks for your interest.  Talk to you soon.

-Cam