Working with frequently changing requirements [duplicate]

Question

How Software Testing Engineer should act in environment where requirements are very frequently changing? Big tasks appear suddenly so tester doesn't perform them in a proper way. Developers do what wasn't expected and stories are done just before demo. How processes are usually fixed?

Answer 1

Frustratingly, dealing with vague requirements is a regular occurrence in software development and testing -- it's also a regular interview question (especially in faster-paced, Agile companies).

Testers are often seen as the gatekeepers of quality and, whilst it can be difficult at first, you need to learn to say no when necessary.

Developers not doing what wasn't expected? Send it back and ask for clarification. Developers not unit testing before sending it to you? Don't test the changes until they have tested (and passed) it first. Stories developed minutes before a demo? Re-schedule the demo and ask for a walk-through before you can present it.

Processes can't be fixed over night, but give it some time, be patient, be persistent... and it'll all fall in to place eventually.

Answer 2

Try talking to the team, or at least with the product owner.

Changing requirements is nothing unusual in an Agile work environment, but I guess the core functionality should be stable so it shouldn't change that much so that the product you are building one week is unrecognizable from the one you were working the week before.

Also, you said the developers are the ones changing the requirements (or doing what they want). That also seems strange.

I guess most of the testing teams (or individuals) meet these kinds of questions, but from what you are saying, both the requirements are changing and the developers are doing what they wish. So it seems the communication inside of the team is lacking or the product owner is not owning the product.

That's why I think you should first talk to the PO.