we are using a classical V-shaped development process. We then have requirements, architecture, design, implementation, integration tests, system tests and acceptance.
Testers are preparing test cases during the first phases of the project. The issue is that, due to resources issues (*), test phases are too long and are often shortened due to time constraints (you know project managers... ;)). Developers are doing their unit-tests as they should.

So my question is simple: should developers be involved in the tests phases and isn't it too 'dangerous'. I'm afraid it will give the project managers a false feeling of better quality as the work has been done but would the added man.days be of any value? I'm not really confident of developers doing tests (no offense here but we all know it's quite hard to break in a few clicks what you have made in severals days).

Thanks for sharing your thoughts.

(*) For obscure reasons, increasing the number of testers is not an option as of today.

(Just upfront, it's not a duplicate of Should programmers help testers in designing tests? which talks about test preparation and not test execution, where we avoid the implication of developers)

  • Edited to precise that our developers are doing their unit tests. i'm concerned about the phases after the unit tests, when QA guys enter in the loop.
    – LudoMC
    Dec 29, 2010 at 19:03
  • Hmmm, will not be easy to choose between the "absolute unequivocal YES" and the "absolutely not". Will think about it a little bit more, waiting for other answers or comments on answers to have a clearer view.
    – LudoMC
    Dec 30, 2010 at 10:36
  • Ok, I accepted one answer but also up-voted some of the other answers who provided good arguments to the problem. Thanks to all.
    – LudoMC
    Jan 3, 2011 at 10:49

8 Answers 8


Looking at your question very literally ("involved in") My only answer is an absolute unequivocal


Devs should never have the final say on their own code.

But, Devs should be involved in testing the work of other devs. It does two things:

  1. It brings a developer's insight to testing. This is both from the general case of just knowing what APIs are probably being used at a given point, what the exceptions that may come from those APIs, and how they should be handled. It also helps on a specific project because the devs get a lot more exposure to the various discussions about why something is being done than QA typically does, meaning they may spot edge cases that QA wouldn't. Bugs spotted by a dev are also likely to be cheaper to fix because a dev will usually provide more information and much more insight on how to fix it right away.
  2. It gives the dev exposure to parts of the application they may not otherwise get exposure to. This will make them better developers for that app in the long run. When I know how my API is consumed, I am much better at anticipating the next thing I should do than if I'm just driving off a spec. Most importantly, I can tell when the spec is wrong before I start coding if I know the application and its use.

Finally, why wouldn't you use as many eyes as possible? You can rarely afford to go through the hiring and on-boarding process to bring additional QA people on board for crunch time. So, where do you find the extra eyes you need? Or do you try to get through crunch time with the same number of QA you had all along? Even if the devs spend 20% of their time testing and 80% fixing whatever bugs come up, it's still more eyes on the app than you had before. Automated testing only gives you a certain level of assurance and it will never be 100%.


  • +1 since developers should be involved in looking at other's code
    – Gary
    Dec 29, 2010 at 20:08
  • I'll accept this one because of 1 - the provided link (very interesting and closely linked to our situation) 2 - the good arguments in your answer: the fact that developers should not test their own code, that it gives them a good view of other parts of the application or system.
    – LudoMC
    Jan 3, 2011 at 10:49

For anything but Unit testing, absolutely not. Developers just know too much about the app and how it's "supposed" to work to be objective testers.

  • 2
    For the most part, I completely agree with this. However, the post said that the QA team is responsible for coming up with the test cases. Assuming the tests have thorough coverage, I don't see a compelling reason why the developers can't run through the test cases prior to releasing the software to QA. It may help catch bugs early and reduce overhead resulting from multiple bug fix releases.
    – Pemdas
    Dec 29, 2010 at 19:46
  • 2
    I disagree with this standpoint because having a developer's eye can be extremely beneficial during functional testing. A developer is a valuable resource so should not be going through rote test scenarios, rather they can advise testers where to go to break the application more efficiently (making the testers life more fun...)
    – Gary
    Dec 29, 2010 at 20:10
  • GR...generally I agree with your statement about developers being to valuable a resource, but the issue here is really about rearrange what resource they already have to ensure adequate test coverage. If this means that the developers have to engage in some Qaish testing then so be it.
    – Pemdas
    Dec 29, 2010 at 20:29

The fundamental difference in testing philosophies between developers and Qs is this: the programmer typically tests his program to prove that his code works ("positive" testing). QA can and does do this, but also has an additional focus on finding out what doesn't work by trying to break the software (using "negative" testing).

To the extent that the QA staff could potentially be corrupted by the programmers testing that "proves" that the software works, there should be isolation between the developer testing and the QA testing. The developer can certainly help the QA testing along by demonstrating what works, but it is up to QA to independently verify that the software doesn't break.

The best thing that the programmer can do to assist the testing effort is to provide a comprehensive, high-quality, verifiable unit testing suite, containing tests that align with individual requirements in the requirements document.


Well in terms of testing, there are 3 types.

Black box, grey box, and white box.

Black box refers to users testing the product, with no knowledge of how the product works internally.

Grey box refers to power users who have knowledge on computer programming, but is not on the development team. These people will test whether the product have memory leaks, system requirements issue and so on.

Here's the main part: White box refers to developers testing on the product at code level. This means to say that they do unit testing, debugging,... etc.

Therefore it is good that users and development team are all involved in the testing phase, but each of the testing requires an appropriate commitment level from users and development team, depending on what is tested.


UNIT TESTING is a must for all developers

For information on how this could be used to your benefit, read through the following links if you are into C++ development:


  • I agree but I was asking the question the other way. Should developers be involved in testing (excluding unit testing) where usually only QA persons are involved.
    – LudoMC
    Dec 29, 2010 at 19:01

Assuming that the project has a significant number of developers, then by all means have the developers working on testing. One caveat would be that developers don't work on testing (this doesn't include unit testing) for their own code.

  • +1 for developers not testing their own code (or at least not alone)
    – LudoMC
    Jan 3, 2011 at 10:44

I would rather see administrative staff (or actual potential users) do the QA testing than developers. Someone who doesn't know how the product was designed to work, needs to try to use it. Developers tend to be very limited in how they approach testing and frankly they are too expensive per hour to use for QA testing as well.


You Write:

The issue is that, due to resources issues (*), test phases are too long and are often shortened due to time constraints That's because developers are not doing them. One of the biggest Internet companies delivering the best most stable products do not use testers at all. They only use automatic testing, all done by the developers themselves. Results are x10 better products than when the developer leaves testing to "testers".

Its like having construction workers build your house, but have a different team make sure that the building actually stands, the doors open and close, air conditioning is working etc... It will probably take x10 to build buildings, and most will end up being unreliable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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