A hospital portal logs users in with OAuth, but the synthetic web test pastes one static bearer token and does not repeat the portal OAuth flow. What should the test do instead?
Select an answer to reveal the explanation.
Short Explanation
Copying one ticket stub onto the door is not the same as you walking the entry line the venue actually uses. The hospital portal uses OAuth, so the test has to follow that flow instead of pasting a single static bearer token. The trap is switching to a different auth method, dropping credentials, or aiming a network-loss test that does not log in.
Full Explanation
OAuth is a login flow in which the application obtains a token, and often a fresh one, according to that flow. Pasting one static bearer token once is a different action: the test is replaying a snapshot of a credential rather than performing the exchange the portal uses. The test should follow the OAuth flow the application uses, including how a fresh token is obtained. Switching the portal test to basic authentication uses a different method than OAuth, so the result would not describe the hospital login. Running the portal test with no credentials and no bearer token skips authentication and cannot show that the OAuth path works. Pointing a network-loss test at the portal, because that test does not log in, abandons the login question entirely and measures only the path. Exam caveat: a bearer token can be a product of OAuth, but a token pasted by hand is not the OAuth flow. Operational check: read the test steps and confirm they perform the same OAuth grant the portal uses and then present the resulting token, rather than a single hardcoded bearer value, a basic-auth header, an empty login, or a network-only probe.