During last year, several of the projects of the company where I work failed. We develop web software, that are not especially complicated (the most are CRUDS and search form about this data).One of the problems that management has identified is the test phase. Putting simple, our protocol is:Analysis of the requeriments  DevelopmentWhen construction is over, upload the executable to a server Execute test plan Repair the errors Execute the test plan, to check if errors persist. If all is ok -> Send to the client.The problem is that when we finish phase 3 and start phase 4, the number of errors is to damn high, that the execution plan takes to much time, and we get an interminable list of things that we have to repair. Until arrive to the test plan we are on time, but after this we spend more hours that were planned and then fail the project. We deliver with enought quality for the client but spend more hours repairing bugs.The management is looking for a solution, and is planned a meeting to ask us for ideas to improve the quality before the first test plan. Any idea?
How to decrease errors before testing?
testing;planning;quality
P. Brian Mackey is right about TDD being useful - and any unit tests will improve things dramatically.  As a tester, I can tell you that a thorough unit test suite dramatically decreases the number of bugs, and limits the remaining functional bugs to mostly a few predictable areas where I can focus my testing (mostly integration points / environmental interactions).  This simplifies test coverage and makes testing go faster.  Other ideas:Get QA involved ASAP.  If you don't have at least one QA specialist sitting on all or nearly all of the meetings, starting with the design stage, you are missing a lot of value.  Senior testers can help find design flaws, bring up small features that will greatly speed up testing, and can start planning test strategy sooner when they are involved in design meetings.Get good, solid requirements, get them early, and get QA to review them.  A good QA specialist will find holes in the requirements that no one thought to address.  Sometimes things that are minor details to devs are huge blockers to QA (e.g., the specifics of business rules; dev can build the framework for rules and then add the actual rules later with little effort, but tests can't be written until the specifics are known).  The worst test cycles I've seen have been when the BA folks didn't get clear requirements, got them late, or communicated modifications to requirements verbally to developers without notifying QA.  Also, test automation can't be developed concurrently with product development without good requirements up front.Develop more incrementally.  Don't throw the entire product to QA, but deliver pieces throughout the development cycle as they are finished for component testing and component integration testing.  Agile development techniques are great for reducing the test cycles and distributing them more smoothly throughout the project so you don't have a huge snarl at the end.If you have developers or testers who read code working in QA, have them do code reviews as well as developers (so one dev, one QA reviews each major code change).  This both helps QA learn the code base and system, and also provides a quality-focused perspective on the code.Use more automation in your QA process.  Limit manual testing to a few well-defined areas.  Automated tests can be developed before the development on the component is finished, can be run at night, and require relatively few resources once developed.  Although you will probably invest more test resources overall into automation, a lot of the tester time will happen before the 'test bottleneck', when tester time is cheap.Ensure that developers make working with and unblocking testers a high priority through the entire development cycle.  When you discourage a tester from asking questions, learning the system, and generally doing their job, you acquire technical debt.  Developers might not realize this because you don't pay interest on that debt until you get to the test phase; the cost is externalized from the developers.Automate test environment setup.  It's time-consuming, and most testers need to do it at least daily to keep up with bug fixes.  A tester should be able to install the entire product(s) with a single command.