Have you ever been in a situation where you were requested to test a feature that didn't have acceptance criteria? Is it possible to even test a feature that doesn't have clear requirments?
Recently in our testing team slack channel I challenged our test team with this: Find the bug in this image: Once you find it add a 🐛 reaction 
"gonna need some acceptance criteria 😬"
"Now...what if we all think it's something different? 🙂"
"the bug is lack of acceptance criteria!"
Before you go any further have you found the bug?
SPOILERS... DETAILS OF THE 🐛 INSIDE
The first resposnes were:
"Extra Finger", "Too Many", or "not enough knuckles for the fingers present".
The conversation continued into:
"depends on what create_human.exe is supposed to do"
"Maybe it's not supposed to be a human? Alien hands matter too"
"OR... the hand is missing an arm"
"As a live entity, I need to see a representation of my hand to feel inspired when walking into a break room."
"As someone who identifies with aliens I appreciate the inclusion of alien hands on my breakroom"
"Before seeing the 6th finger, I actually thought the bug was there was a poster about quality, on the "break" room ...I was reading too much into it..."
"Gotta have a quality break"
"maybe it’s supposed to be Brake room and they just make brakes"
"the ‘brake’ room is where they do all their work xD"
One thing to point out from this conversation, and team interaction is it is totally possible to test without acceptance criteria. Though testing without clear requirements, it is easy for things to get way more subjective, and you may spend some time working with your team trying to convince them that aliens do work at brake factories.
In today's agile world where we value face to face communication over written documentation, there are times where a conversation between a developer and product manager could have happed without a tester being present or a conversation in slack goes down with the whole team and no one takes it on themselves to update the User Story. When this happens the software tester doesn't have to be stuck. There is lots of explatory testing that can be done, and conversations can be had with product owners and developers to help guide and priorize the test efforts.