I agree with Lisa that you want to understand what you're shipping. I think of testing as a risk information service, helping stakeholders make informed desicions (like whether or not to ship).
Numbers, without context, don't tell the whole story though. Another way to to demonstrate value is to figure out if the test team is finding the bugs that *matter*.
Consider the following comparison of hypothetical project's outcomes. For the purposes of the comparison, let's say that the only variable between the two scenarios is the specific bugs found--the team members, lines of code, project team, business purpose, method of bug review for fix/backlog, etc. are all otherwise identical.
Scenario One: finding the bugs that matter
- 500 bugs found during development
- 480 fixed prior to release
- 20 put in the backlog
- 25 bugs found after shipping
- 0 required immediate service packs
- 25 put into the backlog
Scenario Two: not finding the bugs that matter
- 500 bugs found during development
- 350 fixed prior to release
- 150 put in the backlog
- 25 bugs found after shipping
- 20 required immediate service packs
- 5 put into the backlog
[Note that the total number of bugs was *not* 525, it was some much higher number. That's how the 500 found during development got different prioritization (fixed vs. backlog) across the two scenarios.]
We've all worked in environments with bugs in the backlog that are of such low priority that they'll never be fixed. So was it worth the effort to find, replicate, report, triage, and then backlog those bugs? Which of the 150 bugs that were backlogged in Scenario 2 were really worth finding?
This is an oversimplification, of course, but hopefully it makes the point.
If your company wants you to show "value," first figure out what *they* "value" and map your answer to that as effectively as you can. It will be easier for them to understand your value if you have congruence there. You call out money as the measure of value in your question, but make sure that's really what they want to know about the test effort.
If it is really just about the money then one thing to look at, as suggested by the scenarios above, is to see if you can come up with some rough numbers around the support/development/test/management/devops cost to deliver service packs. The cost in doallrs is what you've saved the company from having to spend. The cost in hours is time you've allowed the company to focus on money-making activities. The company should already understand the revenue they hoped to generate with the development hours they'd already planned to devote to new features and products.
