Is it valid to have test plan backups?

Hey everyone!

I’m facing the following situation at company where I’m currently working:

The management team of the project which I’m allocated has not decided which test management tool we can use. I’ve been trying to convince them to allow us to get a Tuskr subscription to that end.
In the mean time, I thought of creating test scripts using Markdown and pushing them to a repository on GitHub.
However, although I believe that this repo content can be used as a backup of sorts for the test plans we’ve been creating for the project, I’m not sure if it’s a good practice. In the sense of just being a kind of a waste of work time in the long term.
Considering all these factors, I’d like to ask for opinions on the subject.

Thanks in advance!


Is there a reason simple markdown documents in GitHub can’t be your only source of truth? Why do you need another tool?

Part of why I ask is related to this recent LinkedIn post by Wayne Roseberry: Wayne Roseberry on LinkedIn: #softwaretesting #softwaredevelopment #ownyourcode #testcodeisrealcode | 10 comments


I really like the idea that all artifacts are source controlled. But any option Im aware of makes them less visible to other domains. i.e. I want tests, test articulations and test results to be visible to anyone. This is why I find things like spreadsheets or text blobs to be sub-optimal. I want the articulation of tests and the test progress to be easily visible to product owners, managers, testers, developers, etc when viewing the work item, story, etc in the planning application. being able to easily zoom in for detail or out for a general progress overview. This is much easier with well articulated automated tests of course. But for not yet automated manual cases, Im not aware of a solution that treats exploratory/manual cases as objects like that. Well not that wasnt a part of Azure DevOps which forced me into using it in a praticular “microsoft way” at any rate. and that isnt even truly source controlled, its a AzDo “thing” that is stored like any other data

1 Like


First question: regardless of the visibility, how many of those other people are going to actually look at the testing-related stuff? In my experience, not many.

If you want the testing work to be more correlated with work items, stories, etc.–and if you’re using Jira–I might suggest a plugin like Zephyr or XRay.


If your world often rolls back production code, then maybe the tool is not for you.

The world of separate test code in a codeless/low-code tool that does let you roll back has probably passed. The world only moves forwards on many platforms, and tool vendors know this and build around this promise. So why woudl they spend effort letting people go backwards if 99% of their customers in reality go forwards only.

Valid points as always.

My thought is that people dont look at that information because it isnt presented in a way that makes it valid to their role. I might only be partially right though. I might still have to interpret the information and tell others what it means and why its important.

1 Like