paint-brush
Testing Complex Software for Airlinesby@yelenakhassanova
131 reads

Testing Complex Software for Airlines

by Yelena KhassanovaJuly 16th, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Software for airlines is a kind of ecosystem consisting of a huge number of rules, integrations, and services. Airline software requires a huge amount of system integration since there should be separate software for managers, agents, the check-in desk, and aggregators. QA team would check the operation of rules and logic for the absence of bugs and the presence of common sense. The logic of each software product can work differently, depending on the user's role. Test the software from the point of view of all types of users.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Testing Complex Software for Airlines
Yelena Khassanova HackerNoon profile picture


Software for airlines is one of the most complex IT products. It is a kind of ecosystem consisting of a huge number of rules, integrations, and services.


Airlines will not be given any slack for low-quality websites and overlooked bugs. Even a minor mistake in this industry can turn into serious problems for your business. To avoid this, you need a strong development team and an experienced QA team that will approach product testing from the point of view of each type of user. A proper QA team would check the operation of rules and logic for the absence of bugs and the presence of common sense. Most importantly, they should generally understand how the whole system works, and its parts interact.

Integration

Airline software requires a huge amount of system integration since there should be separate software for managers, agents, the check-in desk, and aggregators.


● Even the slightest change should be checked on all communicating systems

Any change, say, in the purchase of a ticket or in the seating arrangement, must be checked in a huge number of systems. Let's say there is a new rule that disabled people are not allowed to sit next to pets. It sounds like a case for 10 minutes, but it takes 2–3 days actually for the QA team to test everything. All possible variations and roles should be checked through domestic and international flights for changes in seating arrangements. A pet is checked in for a seat before a disabled person or after them - how will the system behave in this case?

Test the software from the point of view of all types of users

The logic of each software product can work differently, depending on the user's role. That is, it can employ one principle for an agent engaged in buying tickets for individuals, but another principle - for an airline employee. Again, it is important to test the system not from the point of view of an IT specialist who does their job, but from the user's point of view: an agent, an employee, or a manager who carries out check-in at the airport counter.


Not only the system integrity shall be tested but also any possible variations in user behavior, and how the business logic of the system will react to them.

Seating Logic

The logic of seating is one of the most complex issues. A seating arrangement logic draft prepared for one of our projects had 38 pages - font size 12, single line spacing; therefore, hopefully, you can imagine the scale.


Not only test the automatic seating bot and manual seat selection process separately but also their interaction

Test everything: how the automatic seating bot operates, how the manual selection works, how the manual selection works after the automatic seating, and vice versa. The issue gets more and more complicated, especially when passenger separation zones are introduced onboard the aircraft. Some things are hard to check if the logic runs two hours before the aircraft departs. It is not always possible to compare the configuration of the test environment and the product environment, given they are different. Therefore, tests have to be run separately for the test environment and separately in the production.

● Common logic should also be used when testing the seating logic

The seating arrangement issues are constantly being refined, and new algorithms appear. Therefore, the entire team should keep records. For example, sometimes there are cases of behavior that are contrary to each other. Say, there are two options: a person can sit at an emergency exit, with another option of the same situation - they cannot sit there. We try to find out why it is so? It turns out like this: when a child flies to their destination, they are already 14 years old and, therefore, can sit at the emergency exit on the way back. While if choosing a day earlier, the child would be younger than 14 years old and would not be able to sit there.


A big difficulty is that the logic of passengers, the logic of behavior, the logic of seating arrangement, a huge array of rules - have to be taken into account while involving common logic.

Automatic seating

Automatic seating is a robotic service that may not take into account real-life situations. As a result, seats will be assigned to passengers contrary to common sense.


● Test the system from the point of view of real-life situations

Here is a frequent case: a user flies with a large family and checks in the family members via automatic seating arrangement. What to expect? Well, probably, persons with the same surname will be put next to each other; however, they end up seated at different ends of the plane. Therefore, we have to refine the logic: children should sit next to their parents, families with babies should not sit next to each other.


It is important to use common sense when refining the logic of automatic seating arrangement. For example, a pet cannot be near a child, but such things are not always thought through at the development stage.

Rules

Another complication is the rules. That is mostly because there are many of them, and they are amended and extended perpetually.

Understand the rules, provide explanations, add rules regularly on the website / to the passenger app

A case with pets is the best way to demonstrate this problem. There is a rule that the number of passengers with pets on board cannot exceed five, including a passenger with a guide dog. If there are five animals on board already, then a guide dog could be the sixth pet. An ordinary user, on the contrary, can no longer take a pet with them - because a guide dog is always a priority. Here is an example: a person books tickets and does not add a dog to the ticket at first. The next day they decide to take a pet with them.


The passenger goes to the "Manage Booking" section only to learn that there is already a ban on adding a dog. What does the passenger do? Naturally, they seek a resort with the call center with "Why can't I?" "Why was it possible earlier." Most likely, the call center also does not understand how it works. And they are lucky if the call center says that they already have a limit of five animals on board. It also happens that one can forcibly add a pet to the operators' internal system. But it does not guarantee a fault-free check-in after such an addition. The system will raise an error because there are already five animals on board, and that one is the sixth. As a result, the client gets outraged.


It is very important to constantly provide explanations on the website / in the application and use clear language to write the rules.


Besides testing a huge number of integrations and rules, user behavior, and the system response, it is always important to apply logic from a common sense perspective. Developers may overlook many real-life scenarios. And that is where the role of the QA team is huge. The customer's loyalty to the airline depends on how thoroughly and thoughtfully QA specialists work.