Common problem that QA/testers may face incase if s/w project requirement changes continuously

This are basically some common problem that many software tester/QA face while testing software application. Few steps that can be taken care here to handle such cases/situation:

• Work with project stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
• It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the developers.
• Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
• The project's initial schedule should allow for some extra time commensurate with the possibility of changes.
• Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version.
• Make sure that customers and all project stakeholders understand the scheduling impacts, inherent risks, and costs of significant requirements changes.
• Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes.
• Try to design some flexibility into automated test scripts. Focus initial automated testing on application aspects that are most likely to remain unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans).
• Focus less on detailed test plans and test cases and more on ad-hoc testing (with an understanding of the added risk that this entails).