As a tester what is your approach when requirements change continuously in Agile?

From my experience - Faster feedback and more testing (in the form of automated tests ideally).

If behaviour doesn't change but code is refactored often, then behaviour of system should be covered by automated checks. We have unit tests, integration tests and ui tests that are run after every commit.

If requirements and behaviour changes often, then testers should be kept in loop, and plan and adjust test efforts all the time (thats why daily meetings are good)

Time spent writing detailed plans, cases and reports from rigid specs, should be instead spent on communication, learning system and automated test development, basically

When you say that 'it is the technical details that are subject to change' then you might be testing at an implementation level. If your tests fail because the implementation changes, but not the requirements; then for sure you are testing the implementation. Test driven development (TDD) articles and training go to quite some length to discuss this issue and how to avoid it.

Of course, you have to be able to adapt to changing requirements. One way to avoid 'developing insight' during a sprint may be the application of behavior driven development (BDD). In that case you apply techniques to develop the requirements and spread the understanding of the requirements through the team at the beginning of the sprint. To some extent this reduces changes during the sprint because the team as a whole understands the requirements better.

Finally, that behavior and requirements change from sprint to sprint can be expected. Be prepared to throw away your tests at any time and start over.

As a Tester when requirements changes continuously Every team member should be ready to handle the changes in the project.

• The team should work closely with the Product Owner to understand the scope of requirement change and to negotiate to keep the requirement changes to a minimum or to adopt those changes in next sprint.
• Based on the requirement changes Test Team could update the Test Plan and Test Cases to achieve the deadlines.
• The team should understand the risk in requirement change and prepare a contingency plan.

When requirement keeps changing, continuously following points will help for an agile tester:

• Write generic test plans and test cases, which focuses on the intent of the requirement rather than its exact details.
• To understand the scope of change, work closely with the product owners or business analyst.
• Make sure team understand the risks involved in changing requirements especially at the end of the sprint.
• Until the feature is stable, and the requirements are finalized, it is best to wait if you are going to automate the feature.
• Changes can be kept to a minimum by negotiating or implement the changes in the next sprint.

It is a best practice not to go for the automation process until requirements are finalized.

If requirements are likely to change frequently during development...

This is a given and is how Agile works.

It requires a different mindset for QA/QE folks who should focus on:

• Testing during development instead of after a feature is complete
• Pairing with Developers on test plans before development start
• Use Automation for the parts that are stable and not changing
• Be prepared to do manual testing at the drop of a hat when requested
• Be an expert in testing different Browser, Devices and Emulators
• Ensure that you promote a testing mindset for developers

Agile is all about cross functional teams.

As a tester and experienced working on Agile, We had daily scrum meetings to discuss our targets to be met for the respective sprint.

The targets as a whole impacted minor targets in test strategy and items to be tested immediately.

Test Automation was used for repetitive test cases.

Requirements should not be changing often during a sprint (assuming you are asking about scrum) so a changing requirement should not have much impact. The main difficulty is having a source of truth as to the most recent requirement so you do not have to sift through many tickets to figure out what the current behavior should be for a given feature.

If the UI is undergoing a lot of change I wouldn't put much effort into automating those tests. Selectors do not work very well when they change or are removed.

We Agilist acknowledge that changing requirements is a certainty, therefor the manifesto states:

Continuous attention to technical excellence and good design enhances agility.

Being able to change your software continuously without breaking other features is a big part of your Agility. If not the biggest part to be able to respond to change. The current most used way is to automate everything and certainly your testing. This means automate all of your (repetitive) testing. All of it? Yes, all of it! This is the only way you can refactor your code and release often with confidence. If any defect do occur, do a root-cause analysis and cover it with more automated tests.

The LeSS framework has some nice pages about the practises: https://less.works/less/technical-excellence/index.html

Testing no longer means testing

Confused? We can imagine! The purpose of testing used to be fairly clear–“Testing is the process of executing a program with the intent of finding errors” [Meyers79]. This changes when adopting agile and lean development.

If your team can find other means to responding to change, then automation might not be necessary, but for most teams I have seen starting to late with automation leads to a grinding halt in development.

Modern Agile is focusing on continuous delivery making test automation even more important than ever before. This only works when your users-stories are always DoneDone, this includes test automation as many other things.

Other reads:

• http://www.jamesshore.com/Agile-Book/test_driven_development.html
• http://www.extremeprogramming.org/rules/unittests.html
• https://www.thoughtworks.com/continuous-delivery