Yhyjyk

Considering Agile software development process. Is it a good practice to ask requirements directly to developers rather than product owner ? Just because development team had gathered some requirement from product owner as they are ahead with development. Ideally from whom QA should gather requirements ?

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.

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.