What can be done if requirements are changing continuously in Agile?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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:

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

Answer 9

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.