1) "testing" is a subjective term ... video game companies with QA dept's test their games to see if they work within specified parameters. Meanwhile a dedicated gamer with way too much time on their hands will always find some exploit or cheat to use in a speedrun or what-not. This person is just spending way more time to dig into the system, time that would not be cost-beneficial to the company to QA. And, sometimes they're (ab)using the system in a way not intended. (EG: a game that's intended to be played and enjoyed suddenly turned into a speed run that it wasn't intended for).
So, you have to first get the client to explain to you the bugs and issues they found. If they found really, really obscure stuff that wouldn't come up unless someone was really looking for trouble (IE: outside normal use-case scenarios), then they're idea of "testing" and your idea of testing on not on the same page (not apples to oranges).
2) "Testing" should be done in Taguchi style fashion, IE: you have ideal parameters the system should perform under, but also you should test it for semi-obscure ways it could be used that you could forsee someone (ab)using it with.
Taguchi was a Japanese statistician and process optimizer. He advocated for machinery to get built to operate within very broad spectrum of (ab)use case scenarios, then fine-tuned to work under optimial conditions.
EG: you might have a battery that's supposed to ideally function in environments of -20C to 100C. He would advocate to design the battery to operate between -50C and 150C to create a wider (ab)use case scope to cover clients really mistreating the thing, then tune it to work better between -20C and 100C, and then optimize it further to work best in the most common scenarios clients would use it in (let's say most users of the battery will use it between 10C and 50C).
You have to decide if that's useful for projects or not. Often programming companies will get slapped on the hands for over-engineering a product. (EG: they need a simple calendar applet biult into it, but the person in charge of making it spends a lot of time making a super-robust calendar applet).
But, then, catch-22, you build the thing to spec (what the client wants), then find out they're using outside of the spec they gave you.
EG: they neglected to tell you they wanted to track email addresses for customers in their CSR app. So, their CSR's started using the 4th line on the address input to input emails. But, some addresses really do need all 4 lines (especially if they have a "care of" / c/o header line, or an apartment numbering system that needs it's own line). Then company complaines that the 4th line is a wonky email data tracking location. Well, yeah, no kidding.. it's being used outside the original scope of the design.
So, you need to sit down with whoever is complaining that the project has bugs, and figure out if they really are bugs from not meeting design spec, or from them (ab)using the project in situations not outlined in the scope.
3) based on the above... Having a good Business Analyst / Project Manager will make-or-break a project. The BA may have simply done a crap job of scoping the system from the start. You're making up test scenarios per scope they gave you, system tests fine.. but you find out later that while you were making up tests for a bicycle, customer actually wanted a motorcycle and complains why there's no throttle and what-not.
So, I would go back to your system specs and see if you really created use-case scenarios to meet all predicted TYPICAL use-cases.
EG: if there's a date entry field... you set up a test to make sure it's only accepting dates. That's pretty no-brainer. You setup tests to input strings and numbers and what-have-you. It's scope as an optional field. Then customer comes back and complains that the field is requiring input.. duh, it wasn't scoped as a required field, so...
If you setup use-cases and tests per project scope, then there is either an issue with the BA scoping the project from the start, the customer not being forth-coming with the scope needed from the start, or someone customer-side trying to (ab)use the system in a way that's not intended. Possibly all 3.
So, go speak with the client to see what they're complaining about, and see if they're off the reservation doing weird things with the project that it was never scoped to do.
Write down all the issues they're having, then assign some kind of "likelihood" factor to each. This gives an idea of how likely someone would be in doing that action. If it's a very low likelyhood action, then chances are higher you probably didn't test it as well.. b/c the cost-benefit comes in testing the 20% of features 80% of people use, not the other 80% of features 20% of people use.
Basically, a client will expect perfection. That can happen over time, especially if it's an agile programming environment. (IE: every iteration will add new features and fix current bugs, so client complaining just needs to give feedback and wait for next roll-out / update.)
But, nobody can be perfect. A QA tester is paid to cover the most common scenarios, like a driving game where the driver can drive through trees... oops, that's a bug that needs to get addressed. But, someone finding some exploit where they can press the brake and gas and left-right on the controller at the same time (which shouldn't be possible, but the keyboard allows them) in order to cheat and instantly accelerate .. who the heck would find that in QA?
So, talk to the folks and figure out if it's valid bugs, or if it's "you guys have too much time on your hands and are coming up with obscure exploits" type of stuff.
Your company can't spend infinite amounts of time/money on QA, so you can't find all situations. If you tested the product to work within spec, then you should be fine. If they're using it outside spec, then that's an issue the BA needs to take up with them.
If you're not doing a good job testing within spec, then you need to sit down with the BA to figure out how they can help you come up with use-case testing better. (Soemtimes a BA will write really obscure specs or use high-level jargon that makes no sense to programmers, or will write a spec from customer's perspective instead of doing their job and translating into tech req's).
Basically, not trying to say you didn't do you job, but not saying they should treat you liek a scape goat either.
When anyone questions my work, I go to the source to discuss it with them to see if we're comparing apples to oranges, and often find out they're doing something completely off the reservation.
