If you main focus is manual testing then I would focus more on using a good test tracking tool like Jira, Trello, VSTS(MS) or Pivotal Tracker. Most of these have free trials of some variety. I like Jira. I would focus on that plus a well developed agile process and person to manage the process and avoid the things that will always happen without management such as "backlog from hell", etc.
In order to address 'change A this week' and 'change B that week' you need to develop processes that manage that such as agile development and tie them into the tool you use which will usually involve a GUI that has a board with tickets on it for features/changes/bug fixes that can also handle 'sprints'.
btw - free products - should be avoided when you are going to use them as part of your business. They will either break and not be fixed out of the blue, or they will break due to things they interface with changing, or they will suddenly change into paid products, be discontinued, etc. the list of things that can go wrong due to choosing a free product is long. Nothing of lasting value is really free right?
There are not really 'industrial' standards in this area for manual testing that I am aware of. There are certainly testing certification and the like but they have little respect in the community as a reflection of the ability to add value. Software engineering and quality within it is still at an infancy.
Non-technical people usually cannot maintain a complex automation suite*.
* A suite that runs quickly, is easily maintainable and extendable and adds maximum value
The fact that nontechnical people can't usually use a GUI to build complex application products is also true for automation.
Examples of GUI tools in both areas are Visual Basic and Selenium IDE. These two UI tool examples show how limited our current generation of UI tools are.
I refer to the problem often as 'the thousand test problem' and it is a simple issue that I often pose to vendors that come before me. I recently saw another one of those vendor UI automation 'this will be amazing for your company' product demos. After a half hour demo I asked one question: This looks like a great product for doing 1 test. How would this product address maintainability and extensibility and performance issues when there are a thousand tests. The vendor said that their product didn't address that. Demo over. Thank You.
The problem isn't with the vendors or the tools (I am actually a fan of UI tools for certain situations), the problem is deeper than that. As time passes and products continue to grow and be maintained, test suites grow in size and take longer to run. Also you will usually start to experience intermittent errors, especially in browser based tests due to the nature of using an asynchronous program that is not under your control. Also the effort to update and change the tests becomes greater and greater and often involves a lot of tribal knowledge by one or a few key people. Due to all these issues the value of the tests starts going done. Eventually it actually becomes negative. As your test suites are so slow to run they slow down product development and your competitors eat your lunch.
The solution is to have test automation that is DRY, uses SRP and other programming principles to maintain it.
The other issue that you will run into is that most non-technical folks will use the UI to test every data combination and business case. These tests may be from a few seconds to a few minutes each. Technical programming folks however will (should) break down testing into backend user testing, integrated testing, UI testings and usability/performance testing. Backend tests run in less than 1 second each so when you reach the point of having 1000 tests, UI tests may take hours or days and backend 'unit' tests might take a few minutes.
One option is http://www8.hp.com/us/en/software-solutions/quality-center-quality-management/index.html as it seems to cover the features you want. As hou can see it is complex and not free.
btw I also see the following statements as being indicators of needing more technical expertise to address them:
- "people from non-technical background that will work on QA at the QA stage, before the new/updated product goes into UAT stage." Not wise.
- "So I am not very sure how to manage that". Right, you need technical expertise