E2E for debuging

Technical, Testing

title: E2E for debuging created_at: 2020-03-11T14:52:16.823Z updated_at: 2020-03-11T14:52:16.823Z tldr: customer complaints to E2E tests is_published: 1 star: false category: Technical, Testing share_type: share

Customers are always right. They interact with your application in 100 different ways and expect it to work. In one of these unforeseen scenarios, your application is going to break.

Wait but isn't this notifiable by sentry. Most commonly yes, but in a rare scenario, your application has gone into an infinite loop and there is no coming out of this. We can do an E2E test when a customer support ticket is created.

The flow

Every product has its own way of working. So just writing down the flow here. Implementation is upon dev.

So, when a customer complains about a technical issue, A new ticket is raised (zendesk), Create a trigger on this (via zapier) to AWS amplify or a micro EC2 instance. Copy customer data and run all E2E against this data. Get the logs attach it to the ticket and destroy the instance. Thats it!

For a small setup debugging unknown issues becomes a bliess...

So what kind of errors does this catch?

Typically overuse or broken memories or events.

Let's say a customer ordered 100,000 different hot dogs via api and opens the UI to see it, for some reason we need to display the cart as 100,000 images, and the cart is not paginated... the maximum orders were like 25 at that point... The app crashes. Sentry can't notify you because the app is broken. Running E2E against customer data is easy to debug. Don't worry these tests are ran under a black box, so data safety should not be an issue.

Further reading