Suppose you're working with bright programmer, but every time you test the code you find a serious, obvious bugs. Things the programmer could have noticed if they did their own testing before checking in.
Great testers are meant to do great work, and finding obvious bugs is both a waste of QA expertise and a slow way for the team to get things done.
How do you tell a programmer to test their own code before checking in, instead of just "chucking it over the wall"?
Disclaimer: I am approaching this as a programmer (who is here mostly to learn how to better interact with our testers.)
It's important to remember that the developer has not always been told how to test the code. Although we wish it wasn't true, the developer was given a set of requirements from someone who really didn't care about every aspect of the system. You can't expect every dev to know every part of the system.
So, the dev gets the spec, notes down the requirements (that were provided to him) and makes sure those requirements are met. Unfortunately, there are two or three other requirements not on the spec that were pre-existing, and now broken.
Whose fault is it? Is it the dev for breaking the existing requirements? Or was it the person who generated the spec and only told him what things to test? To be honest, in a lot of companies, developers aren't even told what they need to test.
Now, for me personally as a developer, if you tell me a way I can test a piece of code better, please do. If I can stop the bug from ever seeing you, I want to do it. Otherwise, I have to fix it in three days from now when the change filters its way up to you and then back down to me, I've forgotten everything about it, and it takes me an hour to make one simple fix that should've taken me 30 seconds when I ran that test.
So you can tell a dev they're not testing their code by giving them advice instead of orders. You can say "hey, I've noticed a few patches come up that have XYZ-attribute about them. Typically, I test them with __input and catch a lot of bugs that way." Most developers I know would love to avoid going back and fixing their code after it's gone out, and will be receptive to that.
I promise you if you're confrontational about it, you'll get a very angry developer who will throw a hissy fit. In that case, you'll be saying "You have buggy code" instead of saying "Hey, here's a way to be more efficient." The latter is much more appealing, and productive!
In the past I have approached this by firstly defining the "quality bar" as to what is expected and had this agreed by the whole team. This includes setting a defect threshold for the whole team (usually 0 Sev 1's and 10 bugs per developer). When a developer or the team gets above this threshold they must stop adding features and fix their bugs.
With this in place it sets the expectations on an agreed quality target for the application. The developer then knows what he is aiming for.
Then, I use metrics and focused testing to enforce this. If a developer, or area of the application was defect prone, we would focus our testing there, hit the threshold and development would stop until the quality was improved.
Developers hate it first, but they grow to crave working on a high quality code base because they can add new features confidently and quickly.
If possible, sit down with them, explain the bugs. Explain how you found it and ask what kinds of tests they run before they say that it's ready. Start giving some suggestions. I've always found that starting the code quality discussion with some polite, constructive feedback has yielded the greatest results, letting them decide what what they think is sufficient. It's not that they don't want to deliver quality code, sometimes they just don't think of what to look for.
My recommendation is to write them up in the bug tracking system that you use. If you don't have one, you need to get one started. If the bugs are that obvious, then their project manager should have words with them. The stats from the tracking software should be able to support your argument that they are careless, or need better understanding of the business problems that the software is intended to solve.
How obvious are the "obvious" errors? My last company sold software in the tax/financial reporting arena. I had only been there for 5 years (and everyone else had been there longer than myself) when I left and many of the "obvious" domain knowledge rules and tests were things that I hadn't come across yet. One sample rule was that a Form 5500 filing may have a Schedule I or a Schedule H attachment, but cannot have both (neither is also acceptable). Everyone knew that one, and the only place it was "written" down was deep in the bowels of regulations from the IRS and PBGC; after I got called out (and embarassed) in meetings, I eventually learned it too.
At a previous employer, the closest to a bug report was shouting down the corridor "check your work better before checking it in!" which still didn't answer what was wrong. But then that company suffered from a lack of source control, so the last person to edit a file was responsible for everything that file had ever done wrong.
My point, and I do have one, is that what is obvious to you is probably not that obvious to someone else.
Sometimes I talk with them personally and ask to walk through certain issues, sometimes under the pretext of I maybe missed something and want their input. It's a diplomatic way of trying to get their side of things, and maybe see if you can pull out from them why they did not see it, or plant the seed for having them do it. Diplomacy is an important part of our work and the relations you need to have with other teams.
It might also be useful to find out why they do it this way, maybe they think they are checking completely but don't think about the area you are looking at; or maybe just looking at it wrong. Often, I have found developers code an application and test it the one way they expect it to work, while QA often tests it an entirely different way.
First, make sure you can back up your concern with some objective data, e.g. bug counts from your bug tracking system.
How you tell them depends on your relationship with the developer. If you trust and respect each other, you can try showing them your objective data. They may not be aware that they're delivering a lot of bugs.
If you don't have a strong rapport with the developer, it may be more productive to talk to your QA manager (if you have one), the development lead, or the dev manager.
Keep in mind that there may be many reasons for the developer's higher bug count; e.g.
