Kind of a yes/no question, if so, how?

If the customer is unsure of his requirements and keeps changing them, on what basis are the software testers supposed to test the software to assess its quality? Is it even possible to test the software?

  • 1
    The question feels confused as to what you're asking. Analogously, I can answer many kinds of questions, but I can't answer a question that you edit and change in the middle of me writing an answer if it causes me to have to start all over again. So, for the sake of clarity, what are you asking? If it is possible to maintain quality in a codebase with frequent changes? If it is possible to assess quality when the changes happen sooner than you are able to complete your assessment? Are you asking about quality assessment or behavior assessment? ...?
    – Flater
    Apr 10, 2023 at 22:59

7 Answers 7


Having a moving target is not a reason to skip tests and quality assessment. Sometimes clients needs to see something, to be able to better understand what they really need and what not. Welcome change: it'll be for a better outcome.

The quality assessment just needs to distinguish the software and the user satisfaction:

  • Test against the agreed citeria: Were the requested requirements adressed? If yes, the software intrinsic quality may be ok, but this is not sufficient.
  • Test against user expectations (not requirements): if the user is happy, then the full quality may be there. If the customer changes mind, it's because the expectations are not yet adressed. The quality might not be there, but probably, the requirements did not match the expectations.

It has always been like that:

  • In waterfall, requirements may have been flawed, and customer will notice after a very long time. And it'll be very expensive to fix the expectation gap.
  • In agile, the feedback on story implementation is much faster, and it'll be easy to fix misunderstandings, or to incorporate new insights learned by the customer along the journey.

If the software is already in QA at the point when a customer requests a change in requirements, then typically it should not impact QA testing because the goal should be to verify the current version against requirements which developers had at the time they wrote the code. Software quality cannot be measured against requirements which the developers didn't know at the time.

QA either has to proceed as if the requirements haven't changed, or abandon testing (and potentially abandon the release schedule) if there's some reason why the current requirements cannot be released as-is.

If testing and the release schedule are abandoned, then that's a much wider issue; the team needs to fall back into planning to understand the impact of the change, revisit estimates and come up with a revised release schedule.


You are missing a "Change Management Process"

When the customer requests something you need to :

  1. Write it down
  2. Check the contract to see if they are even allowed to change stuff and if so how much to charge
  3. Plan out how to implement the thing
  4. Estimate how long it will take
  5. Reassess the impact to see if it breaks any previously signed off compliance or rules
  6. change the overall project plan to accommodate the change
  7. Get customer to sign off that this is what they want and they accept the costs


This process protects you and the customer from arbitrary changes. The goal is to make sure that the project has the best chance of being successfully completed.

Any stage of this could fail and end up with you not implementing the change.

You totally need to be testing what you make against the request it was designed for.

You shouldn't abandon it in favour of a new change unless the customer signs off on that too.

The risk of not doing so is that you abandon everything and end up with nothing. If you make sure stuff is completed, you can at least roll back to a point before the change came in and say. Well we completed this request.


This is why we invented sprints.

Requirements change. Fine. But for 2 weeks we pretend they don’t. We produce something that shows what we can make using those old requirements and show it off.

Assessing quality works normally. Just do it against the two week old requirements. If that seems out dated you know why. It’s because the requirement was changed.

Now if you want to change the requirements you’re doing it after getting some feedback that shows you how well you communicated before.

Yes. This means you have to wait. Use that time to ensure your next requirement is written clearly.

Interrupting development in progress is a good way to frustrate and annoy developers. Sprints let us schedule change.


Requirements change. Good software design anticipates that.

I'm going to propose a very different approach to "quality" than "run the tests".

  • If you find it reasonably easy to modify the software to meet the changed requirements, then the software is of good quality.
  • If it requires huge refactorings or complete rewrites, then the software was of poor quality. Learn from the changes and seek improvements.
  • I very much agree with the bolded part, so +1; but I would suggest that this answer would be improved by some more elaboration. Right now it only contains a fairly simplistic observation about the definition of what constitutes code quality, but not how to put it into practice or weigh it against e.g. product deadlines.
    – Flater
    Apr 11, 2023 at 1:28
  • @Flater I'll think about elaborating, but it might just end up similar to your longer (and good) answer.
    – user949300
    Apr 11, 2023 at 5:04

Clean coding

The goal of clean coding is not to develop code faster (at the first pass). I can bang out a working quick-and-dirty codebase much faster than a clean codebase, hands down.

The goal of clean coding is to keep the codebase change-friendly.

Change will happen. Sometimes it happens frequently, sometimes it happens irregularly, but it will happen. When it does, you need to make changes to your existing product. This is where we get to a spectrum of how painful those changes are.

Relatively painful changes

In absence of clean coding, the changes will be painful to implement. Since this starts from a codebase where corners were cut, in all likelihood you're now going to be cutting even more corners to reduce the painfulness of the change you're making.
By cutting those corners, you will save some time and effort today. But when the next change happens, those corners you cut today will cause even more pain during that future change.

This is textbook degradation of code quality. At every turn, you give up long term stability for a quick win. It is a honeytrap. It lures you in with quick results, and it keeps you trapped in an endless cycle of complex code, myriad bugs, and an ever growing painfulness to every next change you have to make to your code.

Relatively painless changes

When your codebase is clean, the changes will be relatively painless. While setting up the clean codebase did take more effort than if you had done it quick and dirty, the subsequent changes are easy to make without significant impact to the rest of the codebase.

This means you don't have to cut corners and you actually get time to implement a proper change with an acceptable standard of quality. This also means that you don't negatively impact the next change that will happen.

The basis of your question

You are falling into the honeytrap. While you're technically still asking if it's "possible", you're indirectly implying that it's not reasonably possible to perform quality assurance on such a frequently moving target.
I will counter this notion and point out that it is more important to perform quality assurance on a moving target, specifically because it moves.

Cutting out quality assurance is effectively cutting one of those corners that I talked about in the "painful changes" section. It is a quick win (less effort to implement the current change), but it trades away long term stability as you are losing track of the quality of your codebase, which is liable to letting the code quality degrade, which will significantly increase the effort required to implement future changes.

Really, really try to combat your current attitude towards the changes. Instead of trying to fight them or use them as justification to cut out something you don't like doing, embrace them. Prepare for them as if they are a force of nature, because in your role as a software developer they essentially are as omnipresent as the weather, and you have about the same amount of control over it (which is to say none).


Yes, it is possible.

"How?" is a complex question and the answer is: it depends mostly on the used development methodology and the dimension of the QA team whether it implies or not changes of the releases schedule.

Without additional details here are two common scenarios:
    When the requirements are changed for feature being QAed it has to be decided whether to drop too the tested implementation or not.
    When requirements are changed for features under development or already released the test suite has to be adapted accordingly, that is close to developing a test suite for a new feature.

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