10

I'm trying to get my team to standardize on a tool to manage and keep track test cases. Currently we have a bunch of documents in Google docs or other formats such as Confluence and the main requirement for now is to get things tracked in one place.

I'm strongly considering GitHub (using Markdown to write the test cases) for now since I can start a repo which will have a easy to remember URL and test cases / test plans can get submitted / reviewed much like code.

I'm wondering if this is something others have tried or currently use. Are there better alternatives? My main requirement is just to have one place track/document test cases for the product tested. Integration with bug systems like JIRA or with CI is optional (but desirable)

Clarification: I'm talking about manual test cases / scenarios mostly for the purpose of documentation. i.e. a typical test case document might look something like

Login test:
1. Visit test environment
2. Type in valid username/password
3. Press login
Verify login succeeds
... etc.
Improve this question
6
  • 1
    And how technical is the audencie of your solution? Will they be able to grasp Git?
    – dzieciou
    Commented Mar 18, 2015 at 22:29
  • Your requirements are not clear...what do you mean by 'tracked in one place'? If you simply want all test cases located in one place, Google docs and confluence will work fine through a simple policy that is well communicated. Git gives you versioning which doesn't sound like a it is a requirement. What about metrics, do you need a system to tell you which test cases have been run and which haven't...how often test cases have passed or failed? If not, keep it simple...text files in a network share.
    – semaj
    Commented Mar 19, 2015 at 16:11
  • By tracked in one place I mean I can point a new hire or someone on the business team to one URL and they will be able to see all our test cases. Currently we actually put files as Google docs on Google drive but the downside is mainly around discoverability - you need to know the link to the docs to view them
    – dming
    Commented Mar 19, 2015 at 19:57
  • If you use Git you need to know the Git url ...
    – Maria Ines Parnisari
    Commented Mar 19, 2015 at 20:42
  • This is a very good question I ponder myself right now. So far tracking test cases in a Github repo sounds pretty good to me: 1) Test case history; 2) Markdown; 3) Test case review via Pull request process; Many benefits and it's CHEAP! Other test case management solutions are WAY too expensive - $10-$15/user/month. Not going to work for us...
    – Alex Kovshovik
    Commented Sep 19, 2018 at 16:06

4 Answers 4

Reset to default
4

My Advice: Store your documents in the easiest place to find and access. Your goal should be to make it as simple as possible for the team members who actively use said documents so they continue to do so. If I was in your position I'd be asking this same question to those team members.

Remember, if the service or tool needs to change later as more stakeholders want access then deal with that problem later. Find something that works now.

By tracked in one place I mean I can point a new hire or someone on the business team to one URL and they will be able to see all our test cases.

Almost no one will ever want to see your test cases or detailed documentation and that includes your team members. The goal of testing is to find information so your report to the team or project will be the most valuable and reference-able material. This comes from years of experience! lol. This is why modern / lean testing restricts the creation of documentation to the bare minimum.

Most of the "business users" I've worked with over the years wouldn't be comfortable navigating a GIT repo, let alone know how to access one. (You said GIT repo, not GitHub which has an easy URL and displays markdown text in a mostly readable way).

Currently we actually put files as Google docs on Google drive but the downside is mainly around discoverability - you need to know the link to the docs to view them.

I think you'll have the same problem with any tool / product. The downside to storing stuff on GDocs is someone might not have a Google Account, in which case you just need to make said files public.

If discoverability is your main problem then I'd suggest including the link in your daily / weekly / stand ups or test reports.

Improve this answer
7
  • Thanks for the input! I did mean GitHub with Markdown btw. I will clarify that
    – dming
    Commented Mar 20, 2015 at 20:07
  • Emphasis on this: "tracked in one place". DON'T put all your testplans for a bunch of unrelated projects into a single repo. In my experience projects die, and get replaced, and your v1 testplan needs to be updated for v2 and you do this but then learn v1 is going to stick around for another year so now your testplan has a lot of "conditional" text that even you won't understand in a year. Then your document area becomes a dumpster, and you are the only person who can find or understand things.
    – Scott Prive
    Commented Feb 28, 2019 at 11:38
  • Re-reading my comment above, I also wouldn't put the testplans in WITH the code project, since your activity just clouds their activity (think tagging differences). I'd create a new repo called "projectname_testplans". Be sure to plan ahead how you will evolve your docs as projects evolve. Branching is one way to do this, and leaves documentation easy to find. Possibly name your documentation branches using the same strings used by major project changes (v1, v2, special_customer_release, etc)
    – Scott Prive
    Commented Feb 28, 2019 at 11:43
  • 1
    It's also worth investigating Robot Framework, although it'll take some time to understand and begin using it, the manner in which it documents "tests as code" is quite consistent. There's also "mkdocs" if you find Markdown is too basic of a format. Anyways, "tracking in all one place" is a YES just don't group everything. And you may not need to track everything in one place if you've followed a pattern where people can find your docs using the same pattern they'd use to find the project code.
    – Scott Prive
    Commented Feb 28, 2019 at 11:47
  • ...though you may want some kind of auto-generated index. I can foresee some less-technical people reading GH markdown just fine, BUT forgetting to select the appropriate branch link in the browser, and therefore reading only the "default branch" (wrong) version of the docs..
    – Scott Prive
    Commented Feb 28, 2019 at 11:48
1

Git is not so good in managing binaries, and will not help you compare versions of non pure text documents, at least by default without adding a 3rd party diff tool to it.

Improve this answer
1
  • Yeah the test cases I'm talking about are just manual test scenarios, and would be written in text / with Markdown
    – dming
    Commented Mar 18, 2015 at 17:59
0

I don't know about test cases, but I use a GIT repo to save all my selenium test cases in (IDE and Webdriver using Python) in. As I update tests, I can push new versions, and GIT allows me to track changes easily and more importantly, why the change was made (I am a stickler for comments so the next person doesn't have to figure out why something was done a particular way). Has worked well for me.

Improve this answer
4
  • I do the same thing. This is what GIT was designed for = storing code.
    – Chris Kenst
    Commented Mar 20, 2015 at 19:33
  • Markdown documents are also great to store in Git: Github renders them nicely by default
    – Alex Kovshovik
    Commented Sep 19, 2018 at 16:07
  • I wouldn't phrase "GIT was designed for = storing code" as this easily implies it isn't designed to store documentation. GitHub is good for text-based documentation, including markup types..
    – Scott Prive
    Commented Feb 28, 2019 at 11:33
  • @ScottPrive yeah good point. I wish I could edit my statement.
    – Chris Kenst
    Commented Jun 4, 2020 at 16:42
0

@dming This is an excellent idea. Some other benefits, beyond what you have listed are:

  1. You can easily render them into HTML and PDFs
  2. You can have links to common steps for setup that you don't have to repeat in each test case via URLs to the location of the standard test which can be now organized in the same repo
  3. When you do a release, you can use github branch/tag so you have full reproducibility.
  4. It will be a logical step in moving towards automation of test scripts.
Improve this answer

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.