If requirements are likely to change frequently during development. Although a complete change in requirement is possible, most of the time, it is the technical details that are subject to change. e.g. the intent of the requirement or behavior of the feature is the same but implementation details can change.
In this case: as a QA, what can be done if requirements are changing continuously and the company follows Agile model?

  • 1
    Voting to close as primarily opinion-based, as Agile does not define the testing approach. Each team should do what works for them as long they can respond to change. Commented Feb 8, 2017 at 6:27
  • 2
    @NielsvanReijmersdal Doesn't Agile says that scope is frozen for the sprint time? This guidelines somehow defines how testing should be done.
    – dzieciou
    Commented Feb 8, 2017 at 6:48
  • 2
    No, Agile does not even have a Sprint. Scrum does and Scrum does not equal Agile, it is just the process management part. Also Scrum does not freeze sprints, it just suggest you do. It freezes the Sprint goal, to quote the Scrum-guide: "No changes are made that would endanger the Sprint Goal;". Testing practises are not mentioned by Scrum, nor by the Agile manifesto (agilemanifesto.org) Commented Feb 8, 2017 at 7:45

9 Answers 9


Before answering this question, I would like to explain Why requirements are changing continuously in any Development Cycles:

People change their minds for many reasons and do so on a regular basis. This happens because:

  1. They missed a requirement: A stakeholder will be working with an existing system and realize that it's missing a feature.
  2. They identified a defect: A bug, or more importantly the need to address the bug should also be considered a requirement.
  3. They realize they didn't understand their actual need: It's common to show a stakeholder your working system to date only to have them realize that what they asked for really isn't what they want after all. This is one reason why active stakeholder participation and short iterations are important to your success.
  4. Politics: The political landscape within your organization is likely dynamic (yes, I'm being polite). When the balance of political power shifts amongst your stakeholders, and it always does, so do their priorities. These changing political priorities will often motivate changes to requirements.
  5. The marketplace changes: Perhaps a competitor will release a new product which implements features that your product doesn't. Legislation changes. Perhaps new legislation requires new features, or changes to existing features, in your software.

"You don't have to change, survival is not compulsory."

As a QA:
If requirements are changing continuously then testing should be done prioritizing the features; It should ensure that common flows are all tested as much as possible.

  • Design some flexibility into test cases; this is not easily done; the best bet is 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 this entails.
  • Focus initial automated testing on application aspects that are most likely to remain unchanged.
  • Devote appropriate effort to risk analysis of changes, in order to minimize regression testing needs.

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

  • 3
    This. Focus on keeping abreast of the changes so your testing is reflective of the moving oracles.
    – ernie
    Commented Feb 7, 2017 at 18:17
  • agreed, very comprehensive.
    – Yu Zhang
    Commented Feb 7, 2017 at 19:28
  • and make sure, that the automated tests are responsibility of the developers.
    – ne2dmar
    Commented Dec 21, 2017 at 15:56

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.


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.

  • Where is this best practise described? Seems more like an opinion. Unit-testing is described as the practise in the Extreme Programming, they say all code should have unit-tests. As XP is the oldest Agile framework I should hold some truth here: extremeprogramming.org/rules/unittests.html Commented Feb 8, 2017 at 6:34
  • In Agile environments I often consider requirements as never complete Commented Feb 8, 2017 at 12:51
  • If you wait for the day when requirement is compleletely freezed to start automation, that day might never come. Commented Dec 21, 2017 at 23:32

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

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.

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.


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 practices, check here for more details.

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:

  • 2
    ok. How can you automate all the testing exactly ? When developer asks you "Hey, can you check X", do you answer "Yes, let me write some tests for X first though, see you tomorrow"?
    – George
    Commented Feb 7, 2017 at 19:23
  • 1
    I mean all of the test-cases you are going to repeat. You might still need some manual testing and exploring and other work to find the test-cases, but in the end do not repeat any manual tests, automate them. I would suggest to start with the test automation before the coding. It is called Test-Driven Development and very common for Agile teams. Writing tests is part of the teams job and should not be postponed until the feature is done, do it in parallel. Commented Feb 7, 2017 at 19:29
  • 1
    I would rather change a feature to be testable by automation then to test it manual. This weekend on FOSDEM a ThoughtWorks employee kept repeating to us that they deployed an application every x-seconds with over 20k tests. In a world of continuous delivery manual testing is really not done anymore. :) Commented Feb 7, 2017 at 19:35
  • 6
    That's a little different testing than what i had i mind. Sometimes you cant even be sure the implementation itself is right, if you start with assumption that you need to cover X with automated tests, then your tests are covering faulty implementation and are useless. If you say that before writing tests you should of verified that implementation is correct, then that's testing as well. Not manually test, more like critically think about what is actually being developed before you jump into automation.
    – George
    Commented Feb 7, 2017 at 19:46
  • 7
    Not to mention that in Agile, i dont see the point of jumping in automation straight away. If during development requirements change, rewriting automated tests that dont produce any value. (test broke, no shit, we changed how X works) is not the best use of time. Rather automate once feature is more stable, and add to regression suite so you dont have to test again.
    – George
    Commented Feb 7, 2017 at 19:50

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.

  • The thing with products is that as you are building them the market-fit will change. Often you will have to change half of your product as you learn what works and what doesn't. Advising to skip automated testing sounds as you do not understand the fundamentals under Agile. You should structure your tests (and selectors) to be able to handle the changes easily. Since manual testing each iteration will slow down experiments and learning and that is not an option in an Agile-shop. The automated tests are the source of truth. Commented Feb 7, 2017 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.