A Channel With No Actor

Step 1: log into Salesforce as a named user.

That step opened every test case on the project. Hundreds of them. It was mandatory, it was in the template, and for years it was simply true.

Then a channel arrived where nobody logs in.

The Channel That Breaks the Template

The order is built by a customer clicking through an external website. There is no session inside the system under test while it happens. No profile, no permission set, no running user with a name.

The first internal actor appears only after the order already exists.

That is not an edge case or a gap in access provisioning. It is the design. And it means the very first line of the test case template is asking a question the scenario has no answer to.

What Happens Next Is the Interesting Part

The template needs a user. The tester needs the case to compile. So a user gets invented.

Not maliciously. Usually it is something plausible-sounding — a profile name that sounds like it should exist for a self-service journey, borrowed from a naming convention the tester has seen elsewhere. The template is satisfied, the case looks complete, and the reviewer skims step 1 the way everyone skims step 1.

That fictional profile is now a defect, and it has a property most defects do not: it reproduces itself.

The next tester writing a case for the same channel copies an existing one, because that is what everybody does and it is usually the right thing to do. They inherit the invented profile. So does the case after that. Within a sprint you have a suite in which a made-up actor is the documented precondition for an entire channel, and the only way to find out is for someone to try to execute a case exactly as written and fail to log in as somebody who does not exist.

By then the invention looks like an established convention. Arguing against it costs more than accepting it.

The Mechanism: Templates Are Assertions

The general form of this is worth more than the specific incident.

A test case template is not a formatting convenience. Every mandatory field in it is a claim about how the system under test is exercised. "Test User" as a required field asserts that a human inside the system drives every scenario. "Login" as step 1 asserts that the scenario begins inside the boundary.

Those assertions were true when the template was written. Nothing announces when they stop being true.

And when a mandatory field meets a scenario it does not fit, the path of least resistance is never to change the template. It is to invent a value that makes the template compile — because changing the template is a conversation with three people and inventing a value takes eight seconds.

That is the trade every tester makes under deadline, and it is why fiction enters test suites through the fields nobody thinks of as content.

A Channel Is Not a Role

The specific confusion underneath this one is worth naming, because it recurs.

A channel is a way an order gets into the system. A role is who is operating inside the system. They correlate often enough that a template can conflate them for years without cost — telesales means an agent is logged in, and the agent's profile is a reasonable proxy for the channel.

They are not the same thing, and the moment a channel exists where no internal actor is present, the proxy collapses. Fill the role field for that channel and you are not recording a fact. You are recording a guess dressed as a precondition.

The honest entry is that the channel has no actor. Write that down. An empty field with an explanation in it is data; a plausible name in the same field is noise that reads as data.

Writing a Test Case That Starts Outside

If the scenario begins outside the system under test, let the test case begin outside it too. That is the whole adjustment, and it changes three things:

• Replace "log in as" with an entry point and a trigger. The precondition is not a user — it is the state the external journey must be in and the event that hands the order over. Name that event. It is the real step 1, and it is testable, whereas "log in" was never a test of anything.
• Record the first internal actor where it actually appears. For this channel that is after the order exists. Someone eventually touches it, and their profile matters — for what they can see, amend and approve on a record they did not create. Putting them at the top of the case hides that they arrive late, which is exactly the part with interesting permission behaviour in it.

Everything downstream of the handover can stay as it was. The case does not become exotic. It becomes shorter at the front and honest about where the boundary is.

Why This Escapes Review

Because it fails no test.

The invented profile does not cause a red result. It causes an execution that quietly substitutes whichever real user the tester actually had, while the written case continues to say something false. Every run passes. The document and the behaviour diverge, and nothing in the process compares them.

Then a new channel arrives, or the suite gets handed to someone new, or an auditor asks which permission set this journey runs under — and the answer that comes back is a name that has never existed in any org.

The cheapest moment to catch it is the first time a template field cannot be filled truthfully. That moment is not an obstacle to writing the case. It is the finding.

When a mandatory field in your test template does not apply, do you leave it empty and say why — or do you make something up so the case looks finished?