In the company where I work there are 3 products: software, application and site - each with a different QA process. The question is how would you suggest integrating the QA process in different scenarios? Because there are tasks in which the QA man checks the task and there are those who "created" the task and checked whether it was indeed done at his request. I look forward to your comments on this subject. Thanks!
First, take a look at the answers to this question. While it is about introducing testing to teams that didn't have it, it also covers the way the teams have different processes.
Then you want to consider these issues:
- Communication - you need to get everyone together and have each team's process documented. You also need to find out from each team which parts of their process work well and which are giving them issues.
- Find common ground - there will be parts of each team's process which are similar or even identical. That is your starting point.
- Remember that each process evolved for good reasons - it's something of a truism that every complex process that more or less works evolved from a simple process that worked. This applies to your three teams as well: they started with something simple and built on it whenever they found shortfalls.
- Respect - each team is working the way it does because it works for them or it used to work in the past. When trying to consolidate this into a single process, you need to respect their experiences and the reasons their process exists.
It doesn't matter what tools you use, as long as you can find a reasonable compromise between the three processes that works for all three teams.
It's not uncommon to have multiple products and usually the QA process needs to be adjusted to the individual product. Further it's not uncommon that the stake holders for a project do some testing to make sure the requirements are implemented the way they were meant.
As QA you usually do defect testing and you need to tailor that to your product. A website will need different tools and processes to be tested than a server backend providing a REST API for example. So you should start by defining (and writing down) a test concept for any of your products as well as (if you don't have it) a global test strategy. When you have that you can start to look for/develop tools and integrate them into your process in a way to support the test concept.
When you're done with that you have a working QA process for your entire product line which you can now fit into the overall development process. Just to mention it, it is usually not a bad idea to let your process at least be inspired by the rest of your company, a waterfall testing process with agile development doesn't usually work out that well.
Sadly I can't give you anything more precise since I don't know your actual structure or process.