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/

EDIT:

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.

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?

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

But

• 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 🙂

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.