We experienced this a lot.
The main problem, which I have experienced a lot is that the feature gets tested, it seems OK, you push it to production and then you experience problems.
My approach to this (I am a one-man QA operations with 4 developers!) is a good mix of automated regression tests combined with unit testing the current feature.
I don't have the time or capacity to write (selenium in my case) scripts for all the various features being delivered, so what I do is tested them manually. That's usually fairly straight-forward. I focus on multiple browsers, version and devices at this point to see how things look. I try to put in unusual values, click all links, that kinda stuff.
Also 'when' QA gets involved is important. I have seen two approaches to this:
- When the feature has been coded and delivered and is deemed 'ready for QA'
- During the design session
It is easiest to do 1) but this leads to QA being too late in the process and - critically - not being involved in the design or layout. This in turn leads to low motivation and low job satisfaction which are the two biggest killers to getting high-quality work. Under approach 2) when QA is involved up-front during design, they are then more likely to be motivated to do good QA when the time comes.
Also - make sure (and humor can help here) that QA knows that it's really good when they find bug(s). It is their job and it saves the company from putting it in front of the client.
"Many QA testers quickly feel they become Product Owners themselves. Find a ay to work with this, not against it."