There is never enough time!!! (Score 1)

In my experience of testing (in my 3rd role now in Telecoms, my first 2 were in e-commerce), the project planning never, ever allows enough time for proper testing. To make matters worse, the development invariably over-runs, the deadline cannot move and testing time gets squeezed down to a fraction of it's original time.

In an ideal world, testing should be budgeted an equal amount of time to development. If a project will take 10 man-weeks to develop, 10 man-weeks of testing time should be budgeted. When you take into account the planning, execution, documentation, retesting, user acceptance testing and any load/performance testing applicable, this time is soon eaten up. The main obstacles stopping this from happening are: a) The project planners are often naive to the testing process. They see testing a s a quick one-day job to prove that the product works! (I have seen project plans that allocate 1 day of testing for 2 weeks of development work). b) The customer cannot justify the expense of testing. This is very common. Mr Customer will often ask: "Why do we need so much testing? Are the developers not capable of writing quality code?". c) Testers are often not viewed as a valued resource. I have often worked on projects where testing time has been added to increase the billable amount on a project, instead of ensuring the code works and conforms to the specification. d)As highlighted by the some of the writers here, some developers honestly believe that testers are not necessary if the developer writes good code in the first place...........hello? I have worked with some very disciplined and talented developers. Every one of them makes silly mistakes. There is always some undocumented issue which causes some integration to fail. There is always some misinterpretation of the specification. It happens. You cannot avoid it ;).

What follows is a not an comprehensive list of points, but merely a few pointers for how to ensure code is tested properly:

Ensure enough time is budgeted

Ensure the customer is aware of development process and the importance of testing. If they are not willing to pay for so much testing, bill it under development (It is part of the same process, why bill separately at all?)

If the code differs from the spec, document and communicate the changes. I have experienced many delays and problems during testing due to undocumented changes.

Ensure that the developers communicate with the testers. I have always found that working in the same area as the developers works best. It also helps avoid any 'them and us' situations.

Project managers: Be serious about testing. Your company and your job will be judged on the quality of your product. The low quoted price and the fact you met your deadline will mean nothing if the product is unstable and has not met the customer's specification. If the project will over-run, let it over-run. Don't shave off testing time to meet the deadline. It will come back and bite you on the ass very quickly!

Be honest with your customer. let them see the bug lists. Help them understand the issues. The customer will respect you more and you will be far more likely to reach that inevitable deadline extension in an amicable manner!