I have found that it isn't 'trust' in the software that we are testing for, but more so the potential for something to change.
My users seem to have more problems when their cheese moves than if the servers go down. Back when I was a Systems Administrator, stability was my main concern and patching was always a priority. I just ran the patches, verified the program started and passed it to the app owner. Now, as an App Owner (of Orion! I win.), I'm more concerned about differences in functionality and UI changes. I could care less about any memory leaks or virus vector possibilities. This means that the tests the Systems Administrators put the software through is drastically different than those of the App Owners.
Initially, my list of tests were small. Login, run a report, view some graphs. But, for each bug that arose, a new test was created. I now had to verify that previous bugs didn't happen again. My list of tests grows almost daily. Are the gauges in the correct order, is green still green, did Average Scheduled Job Delay increase more than 100%, does the group status rollup still evaluate properly, and so on. The tests continue to get much more specific.
Like slackerman19 and other said, Trust* (* but Verify). And script, script, script. Testing will never decrease, do what you can to never have to do the work again. Users will always find something to complain about and may not be as tolerant to cosmetic changes as you are. Test your functionality first. If you find cosmetic changes, send out a notification. Many will forgive you if you tell them first and especially if they didn't read the notice.
And always read the darn patch notes! Whether you're a system admin or an owner, it's you in the pot, not the vendor.