Description

If there is an option to deviate from the main workflow (create an account, forget a password, update a delivery address, force a login), take that detour. Take multiple detours and hope you find your way home to the original aim with all your data and states intact.

The story

As a user with a testing background, I am frequently worried when I realise that I’m deviating from a straight workflow (e.g. search for item – add to cart – go to cart (with successful login) – select pre-existing (valid) payment method and address – pay).

The deviations can be things like:

• Forgetting a password and having to reset it
• Having to add a new address (delivery or billing or – worse – both!)
• Having to add a new card or payment method
• Having to confirm a credit card payment with a password for the credit card I’ve forgotten
• Having to go back and edit items in the cart

The reason these things worry me is that I’ve experienced errors when deviating. I’ve been stuck in loops of password links being sent but expiring before I receive them. Once I ended up falsely booking two flights instead of one. They also worry me because they are probably not tested particularly well. Automated tests (even UI tests for workflows) won’t (and shouldn’t) cover too many cases.

And I run into these kinds of errors with all kinds of software. Even new, more recent solutions

Confirming credit card purchase via app

It’s a security feature now that paying for goods online with a credit card requires that I confirm the purchase in my app on my phone.

• If I’m already logged into the app, then I get a push notification and can successfully confirm the purchase.
• If I’m not already logged in (which is likely, because the auto logout happens after 5 minutes), then clicking the push notification opens the app in the login screen. I log in…and see no confirmation option. The event or request that should show the confirmation seems to get lost. The only option at this point is to cancel the payment on the website (a potentially risky detour in itself!) and re-do it within the 5 minute frame for the app lifecycle.

Paying via credit card with a locked phone

This pattern is repeated when I pay in a shop with my phone.

• If the phone is unlocked, the payment is confirmed
• If the phone is locked, I’m prompted to unlock it. After unlocking, I can ‘t pay, but have to restart the payment process via the cashier. (Other people in the queue really love me for this one!)

These things are things I try to avoid as a test-savvy user. However, when I’m exploring, then it makes sense to really exercise these paths. Because they are – in my experience – likely to cause problems.

This is in some ways related to the “you can never go back” because going back is also a detour. However, there are many cases where a detour doesn’t involve going back, so it’s definitely worth documenting separately.

Summary

Back to overview