Is there a checklist the developer must go over before passing their work to testers?

Also, what are the conditions/cases the developer must pay attention to ?

closed as too broad by gnat, Thomas Owens Dec 11 '16 at 19:04

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Is there a checklist the developer must go over before passing their work to testers?

Absolutely. Ideally, this checklist consists of two items:

  • Verify that the continuous integration cycle has ran to a completion, and
  • Make an entry in a bug/feature tracking system for the changes going to QA

The real checklist is hidden behind your continuous integration strategy. Since this list is centrally managed and fully automated, individual developers cannot throw their code over the wall to QA "forget" to check something important before submitting their work to the QA team. You know that developers often become "forgetful" under time pressure, right?

The continuous integration system needs to run a build, and run all the unit and integration tests. It goes without saying that developers need to make new unit tests available to the continuous integration system as they develop new features and fix bugs.

Developers should not touch what comes out from the continuous integration system before giving it to QA, not even to install and quickly try it out. If QA says that the build did not install, you need to fix your continuous integration cycle to make sure that it does not spit out non-installable or non-working artifacts.

The second step is a pleasant one (marking a bug fixed or a feature complete), so developers rarely, if ever, forget to do it.

  • 1
    What if there is no CI? – dlp Dec 11 '16 at 15:13

That depends. There are several philosophies:

  • Test Driven Development wants you to write Regression/ Unit-Test before you even start to code.
  • the coder knows the tricky parts of the code and might test accordingly
  • an independent tester might find errors that the developer never thought about. Also, the tester might be more familiar with the area where the software is actually employed, and might do some validation ("Are you building the right thing?" compared to verification "Are you building it right?") as well.

So the level of testing each partner does depends on your project and your organization. It's important do agree on this level beforehand. Of course the code should at least compile and run without throwing errors.


Does it do what it was designed to do? Does it throw the appropriate exceptions when given bad input? Is it usable? (that applies to APIs as well as UIs).

Your code should be -- to the best of your knowledge -- bug free before giving it to testers. You should do whatever tests you need to do to feel comfortable with the quality of your own code.


Everything you can such that QA doesn't reply back to you, CC'ing your manager saying "you clearly didn't test this deliverable". You could have unit, integration, system and manual (i.e. you) testing at your disposal. Failing to do those would just be wasting the QA's time.

One QA guy who worked for me would ask for "proof" that the developers had tested the deliverable. This could be xUnit results, output from scripts or even a paper-based checklist. Suffice to say that this stopped developers from just forwarding him the build output.


From a tester point of view, the biggest mistake of a developer is to provide a code that does not compile.

  • 2
    Arguably if the code doesn't compile into a usable executable, it's not ready for anyone to see, let alone QA/testers. – joshin4colours Jan 24 '12 at 14:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.