Us poor souls on your Support Staff are just another kind of end-user. Our Gui is made up of logs, reports and audits. We need love too! We need the same kind of attention to our needs as you give to your end-user.
So I have an idea.
Every time I’ve seen QA raise a bug with a dev team, the dev team has requested step-by-step instructions on how the bug can be replicated. This is true of every project I’ve seen where a separate QA team have been involved.
By all means, QA should record how they did it, but keep it secret. Get your other end-users in first. If Support can’t diagnose what QA did, they won’t be able to work out what your end-end-user did either. If Support need to ask QA how they did it, then there might be some information which needs logging – or maybe even auditing.
It really helps if QA consists of the most cunning, mean, dishonourable scoundrels available – or at least, good method actors who can think like them. If QA try to cause problems, to get hold of free money / goods / services / time off / promotion / someone else in trouble, it helps to differentiate the things which can be communicated, from the things which need to be logged, from the things which need to be audited. It’s not just because the end-users are also scoundrels. They might be the sweetest people in the world, but mistakes happen.
You can guarantee that in a big enough system, if someone can steal sheep without anyone noticing, the sheep will go missing without anyone noticing too. And it’s no good asking us why the software thinks there should be two more sheep in the field than there actually are if you don’t keep records, five sheep died, three were legally bought, one was stolen, there’s a six foot hole in your fence and you’ve let in the neighbour’s goat.
(My current client is pretty good at counting its metaphoric sheep. Goats next iteration.)