It never fails. I have worked with QA groups ranging from 1 to 100 and you always end up finding the most interesting, and sometimes the most critical, issues right at the end of a product release. There are a number of reasons for this phenomenon, here are the ones I have seen most often:
- QA does not receive working features until the end of the release. Release dates are fixed and everything comes together at the last minute. We have all seen this and it always results in two things: A mad scramble by all involved; A patch soon after the initial release.
- QA is properly staffed and works on “proper procedures”, developing robust test plans for each feature.
- This is great, but sometimes leads to the basic aspects of features being tested with limited to no real world testing taking place.
- Your QA team should be building test scenarios from the original business requirements and testing these as soon as they can. If the customer can actually accomplish the the business tasks you were trying to automate they will be more forgiving of typos in a dialog. However, they will not care that the product is free of typos if the core requirements have not been met.
- You must build in time for random or freeform testing throughout the cycle. Let your team be creative.
- Lack of customer testing. QA teams do great but they are not your final customers. Supplement developer and QA testing with customer beta testing early in the process.
- Unfortunately, many times, you also fail to test for performance, scalability, and security issues until near the end. Ensure this is done throughout the cycle or you will have even larger issues to deal with late, when you least want to make these detailed changes.