Hey there, Iām a freelance developer and a client of mine is looking for a tool for QA testing for their mobile app. They have a couple of automated tests (i.e. unit tests) but most of their QA is manual and they use a Google Doc and Excel sheet to track the different test cases.
Which tool do you use for manual testing?
Thanks!
It depends on what Iām testing but I do have a few favourite tools I use daily!
For accessibilty testing my go to chrome plugin is WAVE
(https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh)
For bug recording iāve found that screencast-o-matic is the easiest to use (https://screencast-o-matic.com/screen-recorder)
For cross browser testing I always use browserstack, although it isnāt always the most reliable! (https://www.browserstack.com/)
Hope this helps 
James
Thanks @james_qa, I didnāt know Wave and screencast-o-matic!
But what Iām looking for is something to organize the manual test suite better ā not sure Iām using the proper terms though 
I have used TestRail in the past. Integrates with Jira quite well, too, if you are using that.
TestRail is geared towards regression testing but you can create one-off suites as well.
Thanks @froberts! Yes, I had a look at Testrail but it doesnāt seem to be so intuitive. At least for me, not knowing so much about the QA terms and processes.
I do manual regression testing where I work and we use Testrail. When I first started working here, they had test cases in TFS(Azure) and I had to export them and import them into testrail (not a fun process). Our Scrum Team QAs/functional testers use Azure for their test cases. TFS has some cool options for integrating with the builds, etc., but it is definitely not ideal for regression.
TestRail is definitely designed more for Regression testing. To start, Testrail, has two, organization structures, i.e., repository types ypu can choose from, single repository and multiple repository. This is where the organization of it comes into play. Ours was set us as multiple repository when I started working here. It consists of test suites. What i found was that when i created test runs, it was less than smooth to add specific test cases and/or entire groups of test cases to the test runs.
So I changed to the default recommended single repository which has sections and sub sections instead of testsuites. It works so much better.
Basically, what I do is I confirm with upper management which areas and functions of the software are priority using priority 1- priority 4.
We have monthly releases. So each month, I create a Milestone in Testrail for that months release. Then I create a Test Run within that Milestone containing the priority tests divided by Priority. Then as we are testing during the 2 week regression cycle testrail will give you a visual chart showing progress of each run, including ran, not ran, passed, failed, ect. What I like best about testrail is that you can drag and drop the test cases into other folders, you can bulk edit specific data on the test cases at once like priority, etc.
Also, when I first started using it, I created 3 different projects because I started over a couple of times and wanted to see how it would flow with different setups. One other thing is if you edit a test case that is actively in a test run, it will update the test case that is in the run as well, which is nice.
Theres also a plethora of reporting that can be done and can be emailed to you or to a group of people and can be scheduled to regularly be sent.
Hope this helps some!
Thanks for the very complete answer @tech4ever1! 
When you say āits not intuitiveā, what might you be looking for? I will also recommend HP ALM, and Ranorex if you have not checked them out.
Hello,
Most of the manual testers used these below tools while doing manual testing.
1.Test Case Management Tools (TCMT) and
2.Defect Tracking Tools (DTT)
There are various Test Case Management Tools are available but mainly I refer Test Manager, Test link, Spira, TCZILLA, Test Rail, QC etc.
Defect tracking tools are mainly used to track the defects which are found in the application
such as QC, BUZILLA, JIRA, BUGZINI, RATIONAL CLEAR QUEST
if you want to know more about this please check here: Top Defects/ Bug Tracking Tools
I hope it is helpful for youā¦
Keep Reading
Correcting the use of āmanual testingā is not just about game on words, BUT an act of respect to testers and testing.
Use #Testing when you mean testing.
Use #AutomationInTesting when you mean the use of automation to assist testing.
Use #Checking when you mean checking.
Think about it before you prefix #testers or #testing with #manual next time.
Worth looking https://bugasura.io/ from @testertested
I would recommend two articles to start with
This article explains why āmanual testingā is not the correct term to use in testing 
and
this article explains why testers should not put too much focus on tracking test cases. there are more important stuff to do in testing - āthe thinkingā ānew test ideasā
you can use some mindmap tools to visualise your test ideas but please do not track and then report on the numbers to anyone as ātesting progress reportā or similar
I meant for someone like me whoās not so knowledgeable in QA jargon, it doesnāt feel easy to setup for the simple use case of my client.
Thanks @priti_testrig, thatās definitely helpful! I know now that what theyāre looking for is more of a TCMT, since they use GitHub to track all the bugs.
Thanks @testerawesome for pointing that. And I didnāt mean to offend but as I said in another response Iām not accustomed with the QA jargon, now I am and Iāll pay attention in the future
Thank you for your understanding and I appreciate your attitude on this.
Iām one the a few amongst testers encourage others to use the appropriate terms.
Manual prefix is more likely invented to accommodate the automation works in testing. (Personally, I think itās wrong.)
It should be the other way around. Automation is here to assist and accommodate human activities.
Thank you again for your understanding. I hope blog posts or articles I shared above gives you some new perspective of thinking how you may tackle your current problem.
@jeremybenaim We use JIRA for requirements and development workflow management. The JIRA Xray plugin is also used to manage all our test cases.
There is many test case management plugins for JIRA.
The essential tool we all bring to our testing problems is the Mk.1 Brain.
We use Azure DevOps for requirements and workflow (and also document the testing of each work item). Manual regression test scripts are recorded in word and excel (the testing itself is tasked in Azure DevOps) but most important tool for manual testing is the tester. No process will give a good test coverage unless youāve got a fantastic team of testers with inquiring minds.
Testing is a human process - learning about a product, with the intent to find quality related threats.
You question it, you model it, you observe it, you infer.
A test is an instance of testing.
A test should provide you with information.
Cem Kaner was saying something like: a test that doesnāt give me any new information is a waste of time.
When performing a test, you can take some notes - video, paper, or in any tools you want.
Testing can leave behinds plenty of artifacts. Some are more useful than others.
I store code in git,
I store technical documentation, links, credentials in a word file locally.
I store models in mind maps, or text files, locally.
I store testing sessions notes in separate text files.
I store self organizational things in Evernote.
I store environments and configuration files locally and back them up somewhere.
I store thousands of API checks in Postman, and/or SoapUI files in Cloud or Locally.
I store bug reports in Jira.
I publish some of the testing notes in the Jira tickets corresponding to the stories for which Iāve done the testing. These are used mostly to review valuable info which needs to be treated before closing a topic and publishing the feature to production.
I store technical & business - information & documentation that I use for helping with testing, like e-mails, meeting and dialogs discoveries, some stakeholder requirements, shared database exportsā¦I do this in files, locally on my pc.
And lots more thingsā¦
I share from what I have only what the interested party(stakeholder, dev, business analyst, tech lead, process owner, project manager, CTO, etcā¦) desire. Not more. I store hundreds of MB worth of testing artifacts for each product I work on.
Can you be more specific about the problem that you have, and why do you or the client need you to store ātest-casesā?