There are a couple of different problems happening here that may be intertwined.
Having a hand-off between a development team and a QA team is generally anti-agile. In order to achieve agility, teams often need to be self-organizing, cross-functional, and highly collaborative. Having a hand-off from a team that designs and builds the solution to a team that tests the solution may be indicative of a team that isn't cross-functional. Embedding the quality assurance and testing activities in one team can reduce uncertainties around the state of the work around these hand-offs since there is no more hand-off.
However, there may be good reasons to have an independent QA team. In these cases, having a clear understanding of the work is essential. The visualization of the workflow and the work in that workflow would be extremely beneficial for this. Adding and removing states to accurately reflect the reality of the workflow would be extremely beneficial to everyone involved in the process.
I'd also consider applying automation to your tool. For example, you mention Jira. Jira integrates with version control systems to allow for automatically transitioning issues. For example, I've worked with Jira and Bitbucket to automatically transition issues when branches are created, pull requests opened, and pull requests merged into specific branches. With the right transitions and integrations, you can also roll back if new branches or pull requests are made, changes are reverted, and so on. Jira can also integrate with CI servers to track deployments to various environments. All of this information can be available in the Jira UI and can make the state of the work more explicit.
Something that I've seen frequently by teams combining Scrum and Kanban is aligning the Definition of Done to states in the workflow. In order for work to transition from one state to another, there is a clear definition of "done". This helps to make sure that everyone understands what the state of the work is when it is moving into or out of a particular state.
I'd also suggest a retrospective. I'd want to make sure that the development teams understand the QA process and workflow and vice versa. Perhaps the people can identify pain points in the process and have solutions to fix it on their own. The best processes are often built by the people doing the work, with the right guidance and support.
