You're probably doing the wrong tests. If the main functional user test cases pass, then the quality of the sw may be good enough (depending on how critical the sw be in the real world). If you want to find failures, then you have to squeez your mind looking for boundary cases. The higher variables you mix in the same test, the higher probability to find a bug, but the occurrence of the failure then, may not be that high.
Perhap try the 5 Whys technique to work out the issue?
Such as:
Why am I not finding defects? Could I be not thinking outside the square... do I need to understand the software more? Perhaps I could speak to an expert user, or look in the help documentation.
Why are there no defect in this application? Could the areas I'm testing suffer from the Pesticide Paradox... there are always defects, they must be somewhere. Perhap I could see where other defects have been reported in the past and test around those areas.
Why are the test cases all passing? Could the test cases be expanded, or the data changed? Have I tried end-to-end or process driven testing?
Then ask two more. I'm not sure I've got the technique completely correct but hopefully you get the idea.
I typically step back and look at the tests I've run and try to identify patterns in what I've been doing. With my next set of tests, I attempt to violate those patterns. Other techniques that might help include applying Julian Harty's techniques around six thinking hats for software testers, trying different tours of the application to generate new test ideas or better develop my mental model of the application, and/or pairing with others on the project team (developers, testers, sys admins, etc...).
It really meant that the test cases you are running - either they are not updated ones or just clicking on "PASS" on any behavior.
This scenario will not come.......if that comes well.....time for all the testers to pack their bags. :)
May be you are trying the same old technique - may be you should shift your focus and try to use the application from the user's point of view (it all depends on the application - and target audiences).
Testing is a continuous process - try 'Why's' and once you are done with this....... and why do not try "Why not' ....these are the cases.....which seems to be next to impossible in real-world scenario (people will fight on this that user will not do and that) but remember one thing....... you are also an user.
Change your thinking hat may be it will help you a bit. :)
Take a step back and think just what you are supposed to be doing and what you are actually doing.
If you're not finding any defects then there's something fundamentally wrong with your approach.
I was on a project where that happened. I was just there for a few weeks to oversee the execution of testing of a sort of knowledge management application that guided people through the costing of a service. The test strategy had already been set. In effect the testers were wasting their time "testing" a content management tool that had already been used successfully countless times by that company. What they should have been doing was testing the actual implementation of that tool on that project with the data that users needed.
We should have been checking that all of the links were correct, and that users running through the most important scenarios would see the right material, in the right sequence to let them do their job. Unfortunately the project manager thought that was just a given, that the material would be right and that links would work, whereas he'd never worked with the content management tool and thought it was unsafe to take it on trust. So the first half of the testing window was wasted on pointless checking that found no defects whilst I tried to get a shift in the strategy. There was a very weird approach to risk on that project.
if you're not finding problems then you're doing something wrong.