Test management tool for Manual

Hi Everyone,

I am starting a job as a software tester, Quality assurance. I am the only tester at the moment and there are no process in place on quality assurance. The flow of task we currently have:

  1. Using pivotal tracker if there are new features the dev team would notifyy me to test it including procedures/work flow of the new feature
  2. Reported bugs from customers/ sales team are being verified by me (A triage)
  3. There are no test cases being created, most of the testing are just ad hoc or on the fly as soon as they try to release new feature on prod.

What i suggested:

  1. Add me into the loop of new features being developed so I could create a test case.
  • Suggested we start on excel but my manager would want me to find a test management tool that is cloud based or paid one. (I am eyeing on testpad since we are more on manual)
  1. Could you please suggest a process and a test management tool we could use?
  2. I would like to suggest to them a SCRUM type of flow, probalby after this next big release.
4 Likes

What I do since years:
Noting my tests for a ticket either in the ticket (at the description or comment) or at linked Confluence page (or another sharing system).
The initial (and also changing) design (including exclusions) as well as my results.
Depending how much a bug relates to feature, and what I have agreed on with the team, I report bugs as dedicated tickets or inside this one.
I have blog article in my mind to write about that …

Also I very seldom use the the typical test case structure (having steps, actions and expected results). This is more a manual to me, which I use only in cases of often repeated steps.
By that I do not use any test case management tool since years.

3 Likes

You can take a look at our test management tool Testmo if you like, and you can try it for a few weeks without commitment to see if it’s a good fit. Based on your description it could be a good option, as we specifically optimize for teams using manual test cases, and manual exploratory testing, and also support automation reporting if you want to use this in the future. Also feel free to private message me in case you got any questions.

2 Likes

Hi @jonah,

Thanks for sharing here and for posting your first post! :tada:

You’re not alone when it comes to being a solo tester. It can be tough yet this community is here to support you. Perhaps this article is of interest: Four Lessons I Learned As A Solo Tester | Ministry of Testing

If not on your radar, have a look at the following list of “test management” tools on the Ministry of Testing Tools Directory.

See you around the community soon.

1 Like

Hey @jonah,
regarding the tooling, it may be also worth having a look here:

2 Likes

Don’t want to overdo it Jonah, but welcome to the MOT community. And welcome also to the university of hard knocks that all software testers take lessons in. There is a first time for everything, only thing I can say is, don’t overstretch. Take your time choosing a tool, try more than one tool, and most of all, make it lightweight.

As the only tester, it’s too easy for teams to not think of you are a part of “their” machine, and include you in anything that might impact testing. Remind them that the longer they wait before giving you working binaries, the longer the release will take, and the more painful the release will become, no need for any written process documentation to try force devs to do a thing. Let them feel the pain in the right places.

It’s a common running problem that new product features get designed and implemented before anyone gets asked, to “test this”. It often involves a “chucking the code over the wall” at test, and then having QA find an issue and chucking it back over. A very expensive activity, and trying to enforce process changes to get you involved in feature design to ensure new features are easy to test, and are even possible to test in the time allowed, is hard. What has worked for me, is to communicate, talk to the product owner and to the release managers as often as you can. Whenever you are snowed under with testing (this happens often because of a thing called the death march), take time out to attend those design meetings for the next big feature only due next year. Even if you think you don’t have time to, and even if managers start to lecture you about priorities being that big overdue-already release next week. And this leads to the testing tool choice, because if you want developers to capture test cases, you cannot expect them to use a tool they don’t know or hate. And so my advice is to go as lightweight as possible, your wiki can work well, or A big Excel sheet might actually be good enough. Just make a fresh copy each release cycle, so you have a record. From where I stand you still have to make those good strong relationships with the support team and with the sales team, so that their inputs can flow into your test prioritization decisions.

5 Likes