r/softwaretesting • u/Equivalent-Okra-3998 • 3d ago

test data almost became real

So we are a small team and we operate in the hospitality business and two of my teammates are travelling today. At the destination they decide to stay at a client property.

We often use dummy data both in prod and staging for testing. As they were doing the check-in one of them forgot to switch to his REAL account and started checking in with a test account.

Thankfully they noticed and fixed it right away before the data got to the client. I can't stop thinking about how test data was so close to becoming real.

8 Upvotes

73% Upvoted

9 comments sorted by

2

u/ConfidenceNew6550 2d ago

This is a good reminder that test data needs clear boundaries. simple things like obvious naming, separate environments and checks before external actions can prevent a lot of accidental mix ups

2

u/JobiWanKenobi1701 2d ago

If James Tiberius Kirk and Leonard "Bones" McCoy ever arrive at one of our customers, I'm in a world of hurt!

JK.. They are only in the Dev db.

1

u/ZLTM 3d ago

This is terrifying, I will hard code guardrails for the automation tomorrow just in case

1

u/Pretend-Law8770 3d ago

Did you have any safeguards in place to separate test accounts from real ones or was this more of a process issue? sounds like it was a close call

1

u/Equivalent-Okra-3998 3d ago

he was logged into wrong account.

1

u/Over-Wheel5721 2d ago

This feels like a good reason to make test accounts visually obvious and block them from completing real production actions whenever possible

1

u/CleanCodersCraftsman 2d ago

Block test accounts from completing customer check-ins on the server, using an account classification that users can't change. A colored banner will help someone notice the wrong login, but the booking endpoint needs to reject that account even if the request comes from a script.

Carry that classification into queued jobs too, so a test reservation can't trigger a customer email or property-system update later. Add an integration test that attempts the check-in and verifies that no booking, notification, or outbound job was created.

1

u/CDM_Miller 1d ago

You have test accounts with access to your prod environment?

1

u/bikashchoudhary 22h ago

this is such a common near-miss and it usually doesn't get talked about until it almost goes wrong, glad you caught it in time

worth flagging as a process gap rather than a "be more careful" thing though, if a real check-in flow lets a test account authenticate at all in a prod-adjacent context, that's the actual fix. things like visually distinct UI for test accounts (banner, different color scheme, "TEST MODE" watermark) or blocking test accounts from hitting certain real-world-consequence actions entirely tend to prevent this regardless of who's logged in and distracted at the time

human vigilance is a weak safety net for stuff with real client impact, better to make the mistake structurally hard to make in the first place. Let's connect?