That is a problem. It does not automatically mean the testers are doing nothing, but a function nobody can explain is going to lose trust eventually.
The wrong response is to demand hourly timesheets. That will give you extremely detailed evidence that eight hours have successfully passed. If you want us to look at the team’s actual output and whether it makes sense for the product, we can.
Ask what changed because testing happened
What defects were found? What risks were investigated? What assumptions were challenged? What areas are now better understood? What automation or test data improved? What release decisions changed? What production issues were turned into better coverage?
Not every useful day creates a defect. A tester may spend hours understanding a complicated integration and conclude it behaves correctly. That still has value. The team should nevertheless be able to explain what it learned and why the work mattered.
Do not confuse invisible work with unnecessary work
Reading logs, building data, reproducing an intermittent failure, comparing behaviour across environments or understanding an old integration can consume hours and leave behind one short sentence: “this is not a defect.” That can still save a team days of chasing the wrong problem. If the conversation is really about money, ask what the QA team is actually delivering for its cost, not how busy everybody looks.
The test function should make that work visible enough to be understood, but management also needs to resist turning every useful activity into a countable widget simply because widgets fit nicely into dashboards.
Look for queues and waiting
Test teams often look idle because they are blocked. They wait for environments, deployments, data, access, fixes or another supplier. The tester becomes the visible person with no test running while the actual delay sits three organisational layers away.
Equally, some teams really do waste extraordinary amounts of time maintaining documents, writing scripts nobody executes or attending meetings where the same defects are described to progressively more senior audiences. Do not assume innocence either.
Talk to the team before redesigning it
If stakeholders do not understand what testing does, ask the testers themselves. You may discover they are spending most of their time on invisible but necessary work. You may also discover three people are maintaining the same regression pack because nobody has reviewed ownership since a reorganisation two years ago.
Either way, you learn more by following actual work for a release than by asking for a new operating model. Start with what people really do, where time disappears and what useful evidence comes out the other side.
If nobody can explain what the test team contributes, get onto us. We can review the work, blockers and evidence and tell you whether the problem is poor visibility, poor management, a broken delivery system or a team that genuinely is not adding enough value.