We want to maintain test case versioning only using GIT (or other DVCS tools).

What aspects of git could we take advantage of that would let us do this?

  • 1
    Do you have any extra/specific requirements of the versioning – ECiurleo Dec 15 '15 at 9:24
  • ONLY with GIT, but also any other tool? This is confusing a bit. What do you mean? You need to use git, but can use a tool ontop of git? – Niels van Reijmersdal Dec 15 '15 at 9:42

Many Test Case Management Systems offer some form of version control.

TestRail is one such tool and offers the functionality

TestRail automatically saves the history of your test cases and you can see the different changes of a test case via the History tab in the sidebar of the test case pages. TestRail doesn't currently allow you to execute tests against old test case versions though. If you would like to execute tests against different branches, we recommend duplicating the relevant test suites.

Using a tool like GIT will keep versions of the file the tests are in, but not of the individual tests themselves. This is fine if you want to keep it as an archive but maybe less useful if you want it as a peer-reviewed/organic document.


Excel and Word documents are not optimal to store versioned in git. Best is to find a format for writing test-cases in plain text files. This will help the versioning with a code version control system like git. So that you can see a clear history and helpful diffs.

I would have a look at using Gherkin to write and describe the test cases. Then in the future you can even try to automate them with Cucumber.

Example Gherkin acceptance test:

Feature: Refund item

  Scenario: Jeff returns a faulty microwave
    Given Jeff has bought a microwave for $100
    And he has a receipt
    When he returns the microwave
    Then Jeff should be refunded $100

The Cucumber book suggests you structure the features as a manual with the use of Chapters. This way it could also function as documentation.


With git you could use:

  • branches for different versions. You have to manually keep them in sync
  • forks for different versions. When used for versioning it makes maintenance unweildy
  • tags to mark release points. Lets you have a version history that doesn't change.
  • submodules. You could put a different version in modules but I really would advise not to.

Not the answer you're looking for? Browse other questions tagged or ask your own question.