Oh you'll love this. A master password to access any user.

Something like:
const masterpassword = <dayABCyearXYZ>
if (password == dbpassword || password == masterpassword) { // allow access }

The best part is this code is available to our clients. They can literally see how this "master password" is generated. And they don't want me to remove it because it's being used by testers.

Ouch

@rooter it should never be a formula and never in code.
If there is a master password it should be stored as a hash and loaded from the environment or something (also easy to have a different fixed password for testing)

why just not env that var just for QA instance so it doesn't end in prod?

EDIT: unless they do QA on prod! XD

Why would it be used by testers?
Are they testing in production?

Everything should be fully covered by unit and integration tests, automated frontend tests, and should not use real data.

I have heard decent cases for “sanitized” real data, however, as cases found in the wild are often more convoluted than random data.

But for multi tier logins, logging in as (or more accurately: impersonating) lower tier users is pretty common.

Testers should have their own test accounts wich have access to fake business objects used only in testing.

If a dev has to debug a corner case, he can still do that on a dev system using a copy of the production DB where he overwrote the original user's password hash with his own (either directly by using SQL or by using some admin menu where he can just set a new password).
Or implement an impersonation system (don't forget to log who impersonated whom from when to when).

This makes me want to never use any service again

so it's like:

sudo facebook.com login -u anyUserIWant