Changes are inevitable at the last moments of most projects. There are urgent requirements to do such changes and there will be situations where you
must do some critical fixes before shipping the product. In any case, both development and QA teams must be in a common understanding on how such changes affect the stability of the AUT (Application under test).
Sometimes, it will be required to repeat a complete functional test cycle after a significant change. In such cases, sufficient time must be allocated to do a full round of functional testing.
Or else, everyone (both development and QA) should take the responsibility if something goes wrong.
It is a common practice in most organizations to transfer responsibility to QA teams when clients find issues in a product after a release, which is not always valid in agile processes where everyone test and contribute to quality assurance regardless of their title/role playing in the project.
After doing a significant change at the last moment without providing enough time to complete the testing on affected areas, there is no point to blame QA. Everyone should take the responsibility.
This is one of the weird situations most QA teams come across regardless of the process being followed. With better understanding about the tasks and responsibilities of each other, project teams can avoid these concerns. Otherwise, rigid hard core processes must be followed although they are not always realistic.
After all, each team member should understand that QA is not a trivial activity. It takes time and effort to setup and configure test environments, uncover bugs, reproduce them in different platforms, report through defect tracking systems, verify the reported bugs in new builds, ensure the issues are not regressed.
A few months back, Krishantha posted a nice blog entry about how last minute changes affect software QA testing which is a good reference for anyone interested in this.
