This week amidst all the crazy airline flight cancellations and my own pending flight to the Software Test & Performance Conference, I received an erroneous email from a large airline carrier.
I had already booked a flight with a major airline that was cancelling flights so I looked at flights from an alternate carrier and put a second flight on a 24 hour hold. I didn’t end up buying the ticket and the hold request expired as it should have. However the hold ticket generated an “easy online check-in email.” Mmm, feels like a missed regression test.
I think there are likely two user reactions:
1. A confused user trying to check-in for a ticket that was never purchased or issued.
2. A concerned user that their credit card on file might have been used to purchase the ticket at the expire point instead of cancelling the hold.
Big deal, it’s just one email right? I doubt it. It was one email for me (actually I received two with the same details.) It’s more likely thousands of emails because this email was from one of the largest US airline carriers. All these extra emails likely taxed email severs as well as the web servers and database servers as email recipients attempted to check-in via the email. (I know I tried out of curiosity and some trepidation that the ticket had been converted from hold to purchased).
I wouldn’t be surprised if this same error generated a spike in phone calls to customer support. I called support because I was curious to hear what they would say. I had all I could do to hold back a laugh when the service rep said oh well you know it was just one of those computer glitches.
Let me take this one step further and make a guess that with a volume of flights cancelled this week, someone might print out such an email and take it to the airport to demand a seat on a flight they never purchased. A skilled complainer could potentially grab a seat on a flight or be offered a discount to soothe the customer. Discounts are lost revenue. So now is it just one email?
So simple is not always easy. Simple is sometimes overlooked. In the quest for the crazed corner cases, do we forget to test basic functionality? Or was it a regression test that was missed?
I’ll grant that bad things happen in production frequently enough to ensure the work of software testers for years to come. In fact, I had my own recent experience with an error in production that wasn’t an issue in the test environment – a story for another time. Suffice to say that sometimes configuration settings have to be tested in their own environments because test is not prod as certainly as nothing is not null.