Sounds obvious, it is not possible to find a defect if it doesn’t exist no matter how good testing is. But testing is often done in environments that are a cut down version of production, they don’t have all of the interfaces, applications or complete data sets. Yes there are good reasons for this, speed and cost just to name a few. Regularly deploying and testing in an environment that is a replication of production (does not need the same capacity, but should have the same structure, data and interfaces) will help you find those issues that don’t exist in the development environment. What you are trying to do is setup the environment so any problems that could occur in production can be found. Another problem when testing in an insufficient environment is that you can get false negatives, failures that would not occur in production. Worse, false positives occur so there is a false sense of quality because you have thoroughly tested something in the development environment. When moving to another environment it can be a mistake to assume defects don’t exist in an area that has previously been tested. To make testing in a new environment easier, write your tests so they are not environmentally dependent and can easily run in any environment with different data (see earlier entry). This applies to both manual and automated tests.