Testing pages that need a login

The single most common surprise for new users: a test recorded while you were logged in fails on its first real run. Nothing is broken. Recording captured your journey, but the cloud runner starts every run in a clean browser with no cookies, no local storage, and no session. If the journey needs an account, the test has to log in as one of its steps.

123

1. 1Put the login steps at the top so the test is self-sufficient.
2. 2Use a dedicated test account, never a real customer or admin account.
3. 3Add the sign-in steps by hand, or record them once and save them as a block.

Make login part of the test

Begin the test at the login page and record the sign-in: type the address, type the password, submit, and assert that you have landed somewhere only a signed-in user can see. Those four steps at the top of the test make it self-sufficient.

Keep the credentials in variables

Do not type a password directly into a step. Put it in a variable marked secret so it is masked in the interface, and use a global variable if several tests share the same account. Rotating the password then means editing one value rather than hunting through every test.

Use a block for it

Once more than two tests log in, move the sequence into a block. When the login form changes, and it will, you fix it once.

Logins that resist automation

Two-factor authentication, single sign-on through an external provider, and CAPTCHA all make a login hard to script. Where a code is emailed, the test inbox can read it and the flow works end to end. Where an authenticator app is involved, the practical answer is usually a dedicated test account with the extra factor disabled, rather than trying to defeat it.