How do I test a platform's mobile app for managers approving time off?

Your offline queue test is the right idea, but you're being too kind. Don't just toggle airplane mode. Simulate a real dropout - approve it, then kill the app *and* turn on airplane mode before it can sync. Reconnect an hour later. That's where most of these "seamless" sync features actually fail.

Also, good luck getting a real backend log sample. Every vendor claims they have immaculate audit trails, but I've seen logs where the user ID is missing or the event source is just listed as "mobile" with no device fingerprint. If they won't show you a redacted sample during the eval, assume it's a mess.

What's the actual user scale for this test? If it's just you and a dummy account, you're not stressing anything.

Your checklist is a solid start. I'd add one more item under Technical Scrutiny: API documentation review for the specific approval endpoint. When a mobile approval fails silently, it's often because the mobile app uses a different API path or payload than the web version. Ask to see the API spec for the `PATCH /time-off/{id}/approve` call. Look for idempotency keys or conflict resolution parameters, which are telltale signs they've designed for unreliable networks.

Also, on the push notification test, don't just use a slow connection. Simulate the app being in the background for 12+ hours, then tap the stale notification. Some apps will launch but fail to deep-link to the specific request because the session or context has expired.

The API review is crucial, but you need to go one layer deeper. The presence of idempotency keys is a positive signal, but you must verify their implementation isn't just a random UUID slapped on a request. Ask how the backend handles a duplicate key - does it reject the second request as a duplicate, or does it return the success response of the first? The latter is correct for true resilience.

Regarding stale notifications, the 12-hour test is good. The root cause is often that the deep link payload is a transient, server-generated code that expires. A better design uses a persistent request identifier in the notification data, allowing the app to fetch the current state upon launch, regardless of latency.

That's a good technical distinction on the idempotency keys. It also points to the real problem: you'll never get a straight answer on the backend implementation during a sales cycle. Their engineers will describe the ideal pattern, not the actual buggy code handling your requests.

A persistent request ID in the notification is the right architectural move, but it's rare. It means they've built their notification service with access to the canonical data model, not just as a separate fire-and-forget system. Most vendors haven't.

You're right about the implementation details, but that's precisely why you don't ask engineers during a sales call. You ask procurement to add a specific clause in the master service agreement. It should state that the vendor's system audit logs for critical actions, like approvals, must include the user ID, a timestamp with timezone, a unique request identifier, and the event source with device fingerprint. Then you have contractual recourse when their logs are, as user23 put it, a mess. Without that, their "immaculate audit trail" is just marketing copy.

The contract clause idea is smart, I've seen it work. But a warning: I've also had vendors agree to it, then we find out their "device fingerprint" is literally just "iOS" or "Android" with no version or device ID. Makes the audit trail useless for troubleshooting.

It helps, but you still need to test the logs directly during the trial. Ask them to generate a test log entry from your mobile approval and show you.

Exactly. "Ask them to generate a test log" is the only move. If they can't do that for a single approval during your paid trial, their entire audit system is theater.

I once had a vendor's "log sample" turn out to be a screenshot from their admin UI, not the raw database entry. The real data was a JSON blob that just said "platform: mobile". Useless.

> "Ask them to generate a test log" is the only move.

It is, but you have to ask for the *raw* log entry. Specify it as a curl command hitting their audit API or a direct database export. A screenshot of their UI or a prettied-up CSV is just processed theater.

If they push back, that's your answer. Their logging is a cost center they've likely under-invested in, and you'll be the one debugging with "platform: mobile" when an approval goes missing.

Your checklist is fine, but you're overcomplicating it. You can test all this and still get burned by the one thing you can't see: what happens when their notification service goes down for ten minutes. Your approval will just sit there, and you'll never get a push.

Most vendors don't expose their service health, so you're trusting black boxes anyway. Ask for a live status dashboard during your trial. If they don't have one, their "slick" app is just lipstick on a pig.

Totally agree on the "don't just toggle airplane mode" test. That's the difference between a demo and reality. The real failure pattern is the app assuming network is always there *after* an action.

On the log point, the "event source: mobile" thing is infuriatingly common. It makes correlating events across web and mobile sessions impossible. A good audit log needs the session or request ID from the mobile client, not just a generic label.

As for scale, even a small stress test with a dozen dummy users making approvals simultaneously can reveal queueing or locking issues you'd never see solo.

Your "offline queue" test is spot-on. But skip the airplane mode toggle - that's too clean. The real test is to approve something, then walk into an elevator or dead zone before the confirmation spins. Let it sit in limbo for a few minutes, then see if it actually goes through when you're back in range.

Also, for the log sample, don't settle for anonymized. Ask for the raw field mapping. If their "clean audit trail" can't show you a direct link between the mobile session ID and the backend transaction ID, it's just decorative.

And while you're at it, try approving the same request from two devices at once. You'll quickly find out if their conflict resolution is "last write wins" or something more thoughtful.

You've hit on the core frustration. Even when you do get to talk to an engineer, they're describing the system as it exists in their version control, not necessarily in production.

The "persistent request ID" example is perfect. I've seen vendors list it as a feature in their security whitepaper, only to find it's slated for a future release. That's why the follow-up question after any technical assurance is always, "Can you confirm that's deployed in the current generally available build?" The silence or deflection is often more telling than the initial answer.

100% on the dropout test. I'd add, try it with background app refresh disabled too. That's the state half your managers will have it in to "save battery" 😅

The "immaculate audit trail" line got me. Last vendor demo I saw, they showed a beautiful UI log. I asked for the raw event, and it was missing the exact timestamp zone offset. Their response? "We store everything in UTC, it's fine." Yeah, fine until you're trying to figure out who approved what during a daylight saving time switchover chaos.

And scale - even just five test accounts hitting approve in a 30 second window can expose weird bottlenecks you'd never catch solo.

The UTC cop-out is a classic. A timestamp without the originating timezone is just a guess. You need both to recreate the sequence of events across distributed teams.

Your battery saver point is critical. Test with the OS aggressively killing background processes, not just the toggle. That's when you'll see if their sync logic actually respects the OS's lifecycle or just fails silently.

And for the five-user test, make sure those accounts are in different geographic regions if the platform claims global readiness. That often trips up their timestamp logic even when local tests pass.