This question already has an answer here:

I work for a company where the development manager expects a developer to create test cases before writing any code. These test cases have to then be maintained by the developers. Every-so-often a developer will be expected to run through the test cases.

From this you should be able to gather that the company in question is rather small and there are no testers.

Coming from a Software Architect position and having to write / execute test cases wearing my 'tester' hat is somewhat of a shock to the system. I do it anyway but it does seem to be a rather expensive exercise :)


I seem to need to elaborate here: I am not talking about unit-testing, TDD, etc. :)

I am talking about that bit of testing a tester does. Once I have developed a system (with my unit tests / tdd / etc.) the software goes through a testing phase. Should a developer be that tester and developer those test cases?

I think the misunderstanding may stem from the fact that developers, typically, are not involved with this type of testing and, therefore, assumed I am referring to that testing we do do: unit testing. But alas, no.

I hope that clears it up.

marked as duplicate by gnat, user40980, GlenH7, Martijn Pieters, Bart van Ingen Schenau Apr 6 '13 at 6:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    You're coming from a Software Architect position and you weren't aware of the hugely popular trend called Test Driven Development? – user16764 Nov 5 '12 at 4:38
  • Eben Roux, I have edited my answer. Yes,developer can test the Unit Test part. But for other tests, for example, acceptance test, regression test you should have professional and dedicated tester. – Md Mahbubur Rahman Nov 5 '12 at 4:55
  • Are you asking whether to recommend that your company hires a dedicated tester? – user16764 Nov 5 '12 at 5:06
  • @user16764: the question is in the title :) – user23356 Nov 5 '12 at 5:15
  • 2
    I do not think developers should be doing the testing that QA does. But if your in a small company developers do a lot more than write code. – Harrison Brock Nov 5 '12 at 5:41

I do not see a big problem per se in the process you describe. True, dedicated testers traditionally have more experience in designing such test cases, but then again, if your developers do that regularly this won't matter.

However, there is something to be said about being blind to your own faults. Testing your own stuff means you already have an established mindset on whatever it is you test, simply because you developed it. A separate tester will add a fresh perspective and is much more likely to find problems f.ex. in the usability area.

The one major drawback that has not been mentioned before is that you may not be allowed to do so in some projects, depending on the standards you have to adhere to. Several SW development standards explicitly forbid testing your own stuff (not in the TDD sense, but in terms of validation/acceptance testing). In such cases, testing your own work most likely is a breach of the project's contract.


What you are describing is a test plan or test case. Ideally you would have an independent QA specialist that would create and possibly run these test cases.

However, given the small size of your company/team, having the developer create a test plan from the requirements prior to creating the code is the next best thing.

By creating the test case at this point in the process you have less knowledge about the solution and would ideally write a better test case.

I am not a big fan of this method though. If the company/organization doesn't want to spring for dedicated QA, then a possible improvement in the process would be to have a peer write and run the test case.


Sure. A developer should create test cases and then run through test cases.

Before the development community was convinced of the benefits, some people thought that unit tests were a waste of time. Some developers thought that their job was to write production code, so spending time on unit tests, which aren't production code, wasn't what they were being paid for.

These days, most professional developers know that unit tests are an important part of writing production code. It means you deliver better quality code and it makes jobs like refactoring or adding new features easier.

The research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams - via Phil Haack.

If your code isn't covered by unit tests, it is legacy code.

From http://www.enhance-php.com/Content/About-Unit-Testing/


Should a developer be that tester?

Yes, developer can test the Unit Test part.

But for other tests, for example, acceptance test, regression test you should have professional and dedicated tester.


I also work at a company where most teams have no dedicated testing/QA function. We prefer to describe it as quality is everyone's responsibility: making sure the code you write does what it is intended to do is never someone else's problem. Writing and executing manual test plans is not mandated as a solution, but quality software is expected and teams must find some way to achieve that.

The intended effect of this organizational style in my organization was to make everyone act responsibly in the short term and to encourage innovative approaches to quality in the longer term. Many teams started off dedicating a day out of each sprint to manual testing. After a while, more teams began to do more thorough code review and design review, and some teams have automated all or part of their pre-release smoke tests to reduce the time spent testing and to reduce the risk of error.

You're right that dedicating engineer and architect time to repetitive manual testing is a pretty costly approach, but it has the effect of making those producing the code feel the impact of their mistakes and, given the right sort of team, can encourage a deeper understanding of the full path of a change from brain to production, rather than an attitude of just "throwing code over the wall" for QA and operations teams to deal with.

  • Thanks for your input. I am definitely not advocating throwing anything over the wall :) --- I doubt whether there are many developers that write code and then not test in some form. And yes, quality software is definitely everybody's business. I have worked with QA teams quite a bit in my 16+ years so I know all about that. Just not used to running through the testing phase myself. Vetting one's own code just seems a bit strange. So I write it, test it, and then get asked: "Is it 100%"? I just do not think that is prudent. – user23356 Nov 5 '12 at 6:09
  • The process is actually closer to: read BRD, develop test cases, write code, test code (development), run through test cases. – user23356 Nov 5 '12 at 6:12

There is no "should". The goal is to create useful, defect free software. You should do whatever is necessary to attain that goal. For some organizations that means the developer also writes the final acceptance tests. In other organizations there are legions of testers to do the final test.

Certainly, in a perfect world you would have trained acceptance testing professionals, just as you would have build engineers, usability experts, performance testers, etc. Small companies sometimes have to combine roles.

At the end of the day, this is your software. Do you want it released in the wild with bugs?

  • Thanks for your input. No, I do not want my software released into the wild with bugs :) --- that is why I test it. I have a FOSS project that has been going close on 2 years. I do not have a formal testing phase with test cases. I do, however, test the software. – user23356 Nov 5 '12 at 14:52

I'm a big fan of independence at the Testing stage:

  • An architect has a vested interest in showing his specification is correct
  • A developer has a vested interest in finding all the non-conformances


  • A developer has a vested interest in making sure his own code passes the test
  • A tester has a vested interest in finding all the non-conformances

Yes, a single individual can do all roles - and this is commonly happens, especially in small teams and small companies. But you cannot beat independence.

But if you are having to fulfill multiple roles, please wear the hat for the job, not with any other hat :)

  • +1, Thanks for the input. Had to accept the first relevant answer. – user23356 Nov 5 '12 at 8:50
  • 1
    @EbenRoux: you don't have to accept an answer right away, especially in such a short period of time. Give the whole world a chance to answer (ie: at least 24 hours) before picking the right answer. – Bryan Oakley Nov 5 '12 at 11:59
  • @Bryan Oakley: too many answers make choosing 1 just that much more difficult :) – user23356 Nov 5 '12 at 14:53

There are reasons why developer should never test his own code (bias to positive tests, influence of white box knowledge and assumptions like "this cannot ever happen because the component is like that..", creative instead of destructive thinking), yet I think it is not that big a deal, if we are not talking about mission-critical software. I find it very odd even for small company not to have any quality control personnel. It is just not really good idea when person should find problems in his/her own work, in general.