Jtdylktuy

No. Requirements should be originated from a single point. Your developers might misunderstand something so that you'll be testing not what your stakeholders require but what your developers implemented (effect of a broken phone).

Asking your product owner will let you catch the gaps between what the business expects vs what your team actually implemented.

I wouldn't say it's "good practice" to ask the developers for requirements, as they'll have their own interpretation of them.

If possible, always try and get your requirements from the business analyst or product owner (if they're the requesting the change or providing the requirements).

You can ask the developers as a last resort... but take what they say with a pinch of salt and challenge them (always ask 'why') if the changes don't make sense to you.

Ask your team, maybe during the Daily Standup? Saying your impeded by lack of requirements details. The team can now decide whom is the handiest to assist you. Hopefully the Product Owner is at the Daily Standup and can help you, but at least the Team coach (e.g. Scrum Master like person) can try to support you to resolve the issue.

I would expect the whole team to be aware and aligned of what they are currently focused on, including the acceptance criteria. Sounds like you are not part of the team, or not working together closely enough.

Also the Agile Testing Manifesto suggests:

We value testing throughout over testing at the end.

They suggest testing is an activity, instead of a phase or handover.
You could be working on the same details as the developers have in parallel.

Whatever you do, don't create a situation where developers are inhibited from making small improvements because the process for establishing requirements is too heavyweight, or because input from developers is undervalued. That's especially the case if developers have a good level of contact with users. Product owners sometimes are too immersed in high level business strategy issues to recognise that what users really need are little tactical improvements; if developers talk a lot to users they may have their ears closer to the ground.

I don't think it's a good idea to ask requirements directly to developers rather than the product owner. A product owner should always be centre or common point during the development process.

Lets consider, if we ask requirement directly from developers than they(Developer) will share only those points whatever they understood from product owner...that requirement will become basis for you at that point & if there will be some communication gap between (Product owner >> Developer), then this gap may increase when this requirement pass to another link of the chain (Developer >> QA) & QA will test product based on requirement shared by developer. In this case, it's will be very difficult to decide what is right or what is wrong. So the requirements must be a single source.

Some interpretations of the agile process have only the three roles: product owner, developer, and scrum master. That leaves the QA as developers with a particular skill set. So they can ask their fellow developers at any time, and they can also ask for clarification from the POs at any time (but ideally during refinements).

If in any way possible, clarifications should be requested before the sprint planning since clarifications should go into the acceptance criteria.

Even if QA are separate from the developers, as in your case, they are IT professionals with a distinctive view on the requirements and acceptance criteria, and they should always check acceptance criteria for testability before the sprint starts -- a criteria that cannot be tested may be a bad criteria.

Summarized, QA should be present while developers talk to POs, they are entitled to have an opinion on requirements from their own specific part of the team workload, and also in a general way as part of the team effort. Doing that would change the nature of QA, however. They would no longer check on the developers' work for the stakeholders, instead they would with the developers in fulfilling the acceptance criteria of the POs.

If you're doing agile then no, the development team should definitely not be your source of requirements - this comes from the Product Owner or, potentially if they are not available, a business analyst.

As noted elsewhere devs quite possibly will have their own interpretation of requirements which may not match the testers' understanding. This is why you should have some kind of implementation of the 3 Amigos early in the development process to clarify everyone's understanding of the requirements.

QA should not rely on Developers for requirement. But they need to work with Dev and BA collaborate way. Specially after requirement analysis done and when they come up with test scenarios, those need to review with BA ,DEV

Product Owner (PO) or the person who is authorised by the Product owner. Sometimes, a Business Analyst (BA) or a Requirement Engineer (RE) who would be authorized by the PO to clarify and define requirements. Even in that case, the PO will have the final authority.

Please note nothing stops you as the QA to discuss with DEV on requirements. I find the below two benefits from such discussions.

1. As a QA, you could provide some nice insights about the requirements which you think DEV might have missed out.


2. As a QA, you would get some insights from the DEV, which could make you rethink about your understanding on the requirements.

It's not a good approach to ask the developers for requirements. Especially in the world of agile methodology, there will be little or no documentation at all. Two recommendations:

• check if there is any possibility to get something like a use case




• from your experience, hands-on with app knowledge and insight, create test case and discuss it to ensure the functionality checks you added are enough to cover the scenario.