They ask: What does an agentic testing workflow actually look like?
You say: A chain with a person at both ends.
The agent reads the requirement and its acceptance criteria. It produces test cases from those criteria. It generates the automation. It executes. When something fails it isolates the failure and diagnoses it rather than reporting a colour.
Then it escalates what it cannot resolve, and a human decides what ships.
The part that makes it work is the beginning. The chain is only as good as the criteria it started from. Vague requirements produce confident, thorough, useless tests, and you will not notice because everything will be green.
The answer that ends the conversation early: describing tools rather than the chain. They want to know whether you have thought about the flow of work. Naming products answers a different question.
They ask: What do you do when requirements are unclear?
You say: I test the requirement before I test the software, and I have a specific check for it. Can this sentence fail.
The application should be user friendly cannot fail. There is no observation that contradicts it, so it cannot be verified and it cannot be built against. Two engineers will read it differently and both will believe they complied.
A criterion that can fail names the actor, the action, the boundary and what happens at the edges. Including the empty case, which is where most specifications go quiet and most defects live.
I raise these as questions rather than corrections. It is the same information and it gets a much better reception.
The answer that ends the conversation early: "I ask the business analyst for clarification." Everyone says that. Say what you ask and you have shown the room how you think.
They ask: A release is going out in an hour and there is a data set of thousands of records. How do you test it?
You say: I sample deliberately, and I say out loud that it is a sample.
The method is called equivalence class partitioning. You take records from the beginning, the middle and the end of the set, plus anything unusual, and if those are correct you accept the set. It is what you do at the market. You do not taste every grape. You taste from the top, the middle and underneath, and if all three are sweet you buy the basket.
I want to be honest about when this is right. Under time pressure, on a fix that has to ship, it is the correct call. If there is time to compare every record by machine, do that instead. Sampling is a decision made against the clock, not a standard I would defend when the clock is not running.
The answer that ends the conversation early: presenting sampling as best practice with no conditions. The follow-up question is what you would do with more time, and if the answer is the same, you have described a shortcut as a method.
They ask: Why automate something a person could just check?
You say: Because of what checking actually costs. Take a statement export with a few hundred rows and several fields on each. That is close to a thousand comparisons for one document, one account, one date range.
Carefully, with breaks, that is most of a morning. At the end of it you have verified one statement. Change the date range and you start again.
That is the argument for automation and it is not about modernity. The manual version cannot be run at the frequency the business needs. A script does the same comparison in minutes and does it identically every time, which a tired person at row two hundred does not.
The answer that ends the conversation early: "automation is faster." Faster is not the argument. Repeatable at frequency is the argument, and it is the one that survives a follow-up question about cost.