How Would You Test Airline Check-In?

Some of you may have seen on social media that I’ve been travelling quite a bit lately. It’s a great way for me to catch up on my reading but, as you may know from How to test a flight simulator?, it gives me a fountain of questions!

I saw a blog post recently about a bug in airport check in software for passengers. I can’t find the exact post I read but I found another one I remember reading last year:

Anyway, my recent travels and reading the blog post got me thinking. How would you approach airline check in from a testing point of view? How would you test it?

I’d personally like to start with a charter around seats getting double booked. What scenarios enable this, are there ways we could build the software to prevent this.

Over to you, how would you test airline check in?


Hi Heather,

This article caught my attention as soon as I read “airlines - check-in chaos.” It’s funny you ask the question of how would you approach airline check-in from a testing point of view? Well, I recently (2 yrs ago) worked on an airline project where we addressed this same question for our client and came up with a solution.

First, we found out which type of aircraft was the airline using? Then we used the specs of that aircraft to figure out how many seats does the plane has and then we built a solution for passenger check-in issue. We wanted to get a count on the number of passengers checking in and keep a counter on the number of seats available.

This solution was an excellent way for us to keep a count on the number of seats available vs. the number of seats sold. The best part was that it also helped the crew by checking off another task from their list of to-do things before the doors of the aircraft closes. Previously, crew members had to manually go in and count the number of empty seats and accordingly allow other passengers (waitlist passengers) board the aircraft.

1 Like

I read this post a couple days ago and found it intriguing. I thought about the process and how I’ve experienced it. I recall waiting to board and hearing offers for seats on later flights. I presumed the the flight was over sold or double booked. In my opinion, this is designed into booking systems through a conscious business decision: keep flights as full as possible. It offers the airline some flexibility in managing reservations and maintains a cash flow but at a premium (those who accept the offer fly at a reduced rate), and possible loss of good will. I agree a charter would identify scenarios around this system behavior. I’m a little more hesitant to believe the behavior would be prevented. Rather, the tests identify the behavior and it becomes a business decision to address it.

To answer your question, I would like to explore the system under various loads. At one end of the spectrum, I have a leisurely check-in queue (perhaps two check-ins per minute), and at the other end I have a large queue of check-ins (such as two minutes before the flight leaves). This profiling provides information around check-in processing (that is, the performance of the system) and the skill of the clerk. I don’t believe it is difficult to create test data for this profiling since it already exists in production system. Indeed, we may have only to analyze production data to understand where system constraints occur.

I’ve noticed when I check-in the clerk reads information from the screen. I presume they are making a comparison between the information I provide and what they read. They ask about baggage, confirm the number in my party, and direct me to the gate. It all seems simple enough and probably the reason we see a rise in automated check-in stations. Yet, I wonder what else a clerk is reading that, from my point of view, increases my wait time. Perhaps a few charters to explore this processing time might be enlightening.

Lastly, I’ve read of studies or simulations that recommend changes to the boarding process. With some instrumentation placed into the plane, I would like to have some charters that explore boarding efficiency.


Your idea relating to double booking reminded me of a blog post I wrote a while ago about testing a flight upgrade situation (my mindmup is here:

Like you, I’d probably collect data about overbooking scenarios (I recently had bought a flight ticket and was told I couldn’t check in online and when I got to the desk at the airport, they informed me that I didn’t have a seat on the plane).

On top of this, I’d look at data. Data relating to: number of seats available (across classes), number of tickets booked (in each class), type of plane, destination and flight frequency to that destination and flight duration to that destination (for “workaround” options to be able to circumvent risks from that angle).
I would then look at the check in system itself - the different methods of checking in (online, self service kiosk, in person at desk). I’d look at the performance of the systems (data transation delays and error handling). Localisation is a big risk (passenger data, such as their names if they contain any special characters… Accented characters, foreign characters, Double barrelled names with a dash, or a single quote (O’Malley) could be problematic)
I’d look at risks surrounding the upgrade (or downgrade) options through the system.
I’d also look at the timescale restrictions relating to “allowed” check in hours and restrictions, and play with the rules.

There might also potentially be escalation routes within the system for handling an overbooked flight (it’s common for flight companies to do this, so I’d be surprised if the check in system doesn’t support that). Perhaps it’s help text and contact info, or perhaps it’s a resolution feature built in.

Then I would look at accessibility risks. Can someone request accessibility assistance when checking in?

And there is so many things unmentioned that relate to checking in. E.g. baggage… Multi traveller (sitting together), travelling with babies or children, being given an emergency exit seat (what about the rules for the emergency exit seats? E.g. pregnancy, fit and able, age restrictions, etc)…

It’s certainly turning out to be an extremely complex system… :grin: