Currently, our QA team writes test cases for every feature and bug fix. These take the form of spreadsheets - each row is a test case with name, steps, prerequisites, outcome of the test (pass, fail). The spreadsheets are attached to the feature ticket in Jira (our issue tracking system). QA team members review each other's test cases.

Problems with this:

  1. This is purely change oriented. To figure out how a feature is supposed to work right now, you have to go through the tickets related to the feature to piece together the complete picture. Same to assemble test cases to regression test the feature.
  2. Getting test cases reviewed involves passing spreadsheets to members of the QA team, keeping track of feedback, etc.

This has already been solved in the dev team using Git:

  1. Code changes are expressed in commits, which live in branches.
  2. There is one unified "live" version of the code base, and one "next release" version.
  3. To get feedback from other devs, a developer creates a Pull Request in Git. This supports discussion, etc. No passing files around, sending emails, etc.
  4. Git keeps track of all changes, etc.

I suggested to the QA team to write test cases in text files and storing them in Git. They are intrigued but also somewhat apprehensive about this.

Looking for

  1. Feedback from other QA teams re. this idea.
  2. Your experience re. what happened when you introduced a similar scheme in your QA team.
  3. Any QA oriented tools or services that allow you to store test cases per feature, to reviews, etc.

3 Answers 3


I would strongly recommend a test case management system. Since the teams are using Jira for issue and work management, I'd start by looking at tools that are or can be integrated with Jira - Zephyr, TestRail, XRay, or similar. These tools will allow you to link test cases to issues in Jira, search/filter test cases, manage review, store data about test executions (and these tools often have an API that can be used to store automated test execution data), keep an audit log of changes to test cases. They are designed to solve your problems of managing the work products created by QA teams and often in a way that is more closely integrated with the rest of the product development work.


I like the previous answer about using a Test Case Management System (TCMS). Why use a tool like Git for spreadsheets when that's not the main use case of Git? Also, a TCMS tends to be a short-term solution. I have found that TCMSs are mainly for QA to use and the devs will tend to not use them.

If you want to use Git or any other source control, why not start automating your tests? This is something the OP didn't mention is something they do in their practice.

The idea is to test like you normally do, and once all the bugs are fixed, come back and automate the tests. Since this is code, you'll store them in Git and follow the same procedure the devs do.

The benefits of this are that the test team:

  • can learn new skills
  • devs can review the tests, which they learn new skills on how testers think
  • devs can add tests
  • you can utilize the test automation in your CI/CD builds
  • you can reuse tests, which makes testing more efficient

The cons of this:

  • if you're not currently using test automation, it will take time to create
  • if you're not using CI/CD, then it'll take time and money to set up the pipelines
  • learning new skills will take time
  • this is an organizational change, so it'll take a mindset shift to be successful

If you're already using CI/CD, then test automation enhances the pipeline!

To overcome the time issue, it'll be best to bring on someone who has created test automation from scratch to help build this out. And, they can help teach the team how to utilize this and add tests to it. It's not a quick solution, but it is one that has long-term benefits!

Note: test automation doesn't need to replace the work that testers do. It's an enhancement to what they already do. I'm a firm believer that 100% test automation doesn't exist; that test automation doesn't find new bugs, only regression bugs; and adds efficiency to the testing process.


Your problem seems that your scenario descriptions and the product they describe have low cohesion: They are separated from each other and, inevitably, will move in different directions.

Traditional test management tools (and binary files like spreadsheets) tend to increase accidental complexity to improve this cohesion, requiring complex scripting and coordination of different parts.

I would suggest your team look into the concepts of Specification by Example (here and here) and Continous Delivery.

The idea is to move your software towards being driven by examples that can be checked continuously. In this way, any given version of your software is verified by a set of scenarios that accompany the software itself, in one single unit.

Dave Farley talks about this here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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