The issues of a product can typically be revealed during the functional/regression test cycles. Most of the text books and web resources written about SQA, suggest to follow a properly designed test processes in order to catch bugs as early as possible. I strongly agree with that. However it is not always a practical approach to adhering to that kind of process. In my experience, more bugs are uncovered and caught by test teams when the product is matured and the team is familiar and well aware of the functionality of the product. One may argue that the good test design should anticipate all possible scenarios. However, it is not always true. Most of the practical and useful test scenarios are captured during the test execution stage NOT in the design phase.
I'm not going to say that QA doesn't have to be part of early planning and reviewing to find out issues. it will definitely help to capture design level defects as well as preparing test cases and scenarios. However, even with all efforts, you will encounter the last minute issues when product is mature and fully integrated, also QA have enough knowledge about the product in user's perspective.
Therefore last minute issues are not strange, specially in the modern agile development processes.
In my experience, one of the most important aspect of agile QA is to reveal critical issues as quicker as possible at any stage of the development cycle. In agile methodologies, QA do not get the luxury of following a proper release cycles and sufficient schedule for comprehensive testing. Therefore, QA should be in a position to capture critical bugs in a quicker way whenever a new build is given for testing.
So, what does it mean by finding critical bugs at the critical moments of a release?
Suppose, you are assigned to test a software product which has already undergone number of functional and regression testing cycles. Therefore, the critical issues are minimum in that kind of a product. Assume, a simple performance fix has been done in order to improve concurrency handling of the product and a minor release is expected to be done within a day. In such situation, a traditional QA process may suggest to do a smoke test to ensure the existing functionalities are not affected by that fix. Yes. That is important. However, QA should be able to try out a set of ad-hoc scenarios in order to capture some hidden issues which may have arisen due to the performance fix. QA/test engineers should use their experience to carry out some random checks to ensure that the quality of the product is not affected by the fix. There are situations where QA do not even get enough time to do a full smoke test. In such situations, QA can act wisely with the product knowledge and common sense to find out regression issues as quicker as possible.
In other words, QA should have a better understanding on exploratory testing. I will post a new blog entry on my experience in exploratory testing in due course.