I am wondering how typical it is for programmers to switch hats and do testing on each other's work. Assume that the team wants to take a "shared responsibility" approach to moving tasks from being formalized to their release -

  1. is it a good idea to have programmers work as software testing as long as they didn't write a feature?

  2. Does this happen often?

  3. To what degree a programmer can "test" their own work?

Even with TDD and unit tests, isn't there still a need for a software testing apparatus in the development process?

  • 7
    This isn't "switching hats" at all. Programmers who don't write tests are doing it wrong. Apr 19, 2011 at 16:06
  • This is too broad question, you will get answer ranging from TDD (mostly "technical" quality) to acceptance tests(aka what customer cares about) - these can be very different! Answer also depends on the scale of the project (one man shops to large corporations...)
    – MaR
    Apr 19, 2011 at 18:02
  • 3
    Programmers can never really switch to Test to break from Code to Make .
    – Aditya P
    Apr 19, 2011 at 18:08
  • Related: programmers.stackexchange.com/questions/31710/…
    – LudoMC
    Apr 19, 2011 at 19:26
  • @Aditya, that's a strong statement. Maybe you should try to support it. Apr 19, 2011 at 21:41

8 Answers 8


Devs testing each others' code should not be done instead of testing by a focused QA specialist, but would be great in addition to testing by a focused tester. Developers are skilled in thinking about how to make the product work. Testers are the only people on the team (BAs, PMs, devs, etc.) who are focused on figuring out how the product could fail. It's a very different mindset. Think about your "down time" work - e.g., when you are outlining projects in your head while showering. Do you think, "Oh, I bet this would be a good way to tackle that feature!" or do you think, "Hey, I should see if I can get that code to fail if I do THIS!"? Work doesn't just happen in the office, and devs probably won't be working on breaking code in their "free time". Testers should also accumulate a wide variety of knowledge of testing tools and techniques and experience choosing between them that devs don't have, and think intuitively in terms of coverage.

At the same time, cross-disciplinary experience is a very Good Thing, and there is always a benefit to working with other developer's code. Having devs put more effort into testing before a specific QA / testing person looks at the code will probably result in better quality code, which will probably result in faster test turn-around, better test coverage, and may even reduce (but not eliminate) the number of dedicated testers that are needed.

If you really have to make trade-offs due to low head-count availability or if the skill pool for QA is exceptionally bad where you are, this setup would be better than nothing - but the goal should still be to get a real tester in before the team grows too big.

  1. Having the programmer test their features can be a mixed bag. On one hand the programmer can be "too familiar" with the code block and simply test well known pass/fail type parameters. On the other hand if that programmer that is "too familiar" with their code is diligent in making the feature work, they'll have more knowledge on fringe cases that could cause issues, since they know the inner workings of the function and potential loopholes within it.

  2. I think this happens more often than not. I think a majority of programming shops out there are in small teams, or under a lot of pressure to get things done. This doesn't afford them the luxury of a dedicated QA / Tester in their group, so everybody has to pull their share. There are still a fair number of "lone cowboy" shops out there where each developer is essentially responsible for the entire life cycle of their app. That is the case for me.

  3. I'll defer back to #1 for this. I think a programmer is capable of testing their own work, outside of the TDD model, since they have intimate knowledge of how their feature works. They need to take care to "step back" and be able to cover specific and broad issues with the code (such as "fat fingering" a text entry field - what happens?), but it can be done.

  • IRT 1: This is one of the advantages of pair programming: you keep each other honest. Apr 19, 2011 at 16:07

I've never seen a bad method of testing.

Should programmers test their own code? Yes - obviously.

Should other people test their code? Yes - obviously.

Is coverage testing a good idea? Yes.

Is Monte-Carlo testing good? Yes.

We can have what we consider a pretty good setup for testing, and then a new person does some testing. Guess what? They find problems that weren't found before.

A sign the quality is getting good is when the percentage of problems being found in testing that aren't really bugs approaches 100%.

  • 4
    "I've never seen a bad method of testing." I have some people to introduce you to...
    – Dan Blows
    Apr 19, 2011 at 19:16
  • 1
    You may have tests which do not bring much value, are always out of date, but on the other hand incur maintenance costs and impose design constraints. Then it is a bad method of testing.
    – quant_dev
    Apr 19, 2011 at 19:48
  • @quant_dev: OK, I suppose I've been lucky. Apr 20, 2011 at 0:03

There is a large and growing development movement called Test Driven Development or TDD. I don't claim to be an expert and have actually struggled to get my head around doing this method by default, but the gist is that the developer first writes a failing test then writes the code to pass that test.

The concept has many strengths. One is that you have a great set of tests. Another is that since this is done in many small increments you know right away if you break something. One of the things that I have seen with this method and other "mandates" of test everything is that you don't get developers running around putting in extra features because they are cool or neat. There is always a cost to a feature and many times a developer doesn't see or feel that cost. With TDD they do, since you write a test case before you write code.

There are extensions on this theory as well taking the test writing to the requirements source where the business expert writes a set of functional tests that make up the spec and then the developers develop to that set of test cases.

So with TDD the developer writes a lot of tests, some argue for a ratio of 1:1 for lines of test code to lines of code.


Turning this around - I think there is big value to be had in recruiting at least a few people for the team who are better at testing than they are at coding. It's a skill set that is different from development and I think - even with TDD and other agile practices - that someone with a good eye for testing is invaluable for product quality.

So as easy to ask - should testers be coding as much as coders are testing.

IMO - yes, there should be at least a little bit of a mix. Having a perspective on the other end of producing a product keeps you well rounded and may raise new insights.


I think that it is the responsibility of a programmer to do a fairly decent amount of due diligence before checking in a piece of code and signing it off, this means:

  • Writing thorough unit tests.
  • Testing that code in a real use scenario and trying to break it - i.e. interact with it as it would be used in production.


  • Then another programmer should review that code and the unit tests.

  • Then a dedicated tester / QA person should test that code.

I don't think that there is any excuse for not doing the first 3. And I don't think that there is any excuse for not doing the last step, but having a dedicated tester test every bit of code is expensive and smaller companies (think at least) that this is luxury that they cannot afford.


Personally, I don't believe that specific testing should ever be left out of the equation. I think you need to find people that are at least not developing the same product (or maybe large module), which would allow some other programmers to test, so long as they really have no idea what the implementation is. I think the most important thing is that whether or not they ever do, developers should be able to function as testers, and testers should be able to function as developers. Having both knowledge bases and familiarities makes development, testing, and communication between the two that much easier.

  1. Yes, although they aren't "working as software testing". Writing tests is part of a programmer's job. Also, writing good tests is a skill. Being unable to properly test your own features is not a flaw in testing, it's an indicator of lack of skill*.

  2. I would certainly hope so.

  3. While a programmer can completely test their work, there may be value in an external QA process. I have rarely found that to be the case, however.

The goal of testing is threefold:

  1. To drive development
  2. To manage change
  3. To provide confidence

Developer testing can and should serve all of these purposes. If developer testing is sufficient for them, there's no need for further testing.

* Pair programming makes it even harder to write such bad tests because you're never testing your own features.

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