Тестирование сложных продуктов для авиакомпаний

Елена Хасанова

Заместитель руководителя в агентстве аутсорс тестирования «Кавычки»

У авиакомпаний нет поблажек на некачественные сайты и пропущенные баги. В этой сфере даже незначительная ошибка способна обернуться серьезными проблемами для бизнеса. Всего один баг может стать мемом или инфоповодом в сети и навредить репутации бренда. А сбой в работе сайта даже на несколько часов — это миллионные убытки. Чтобы избежать этого, нужна не только сильная команда разработки, но и опытная QA-команда, которая будет подходить к тестированию продукта с точки зрения каждого типа пользователей. А также проверять работу правил и логик не только на отсутствие багов, но и на наличие здравого смысла. И главное — понимать, как в совокупности работает и взаимодействует между собой вся система.

Более пяти лет мы работаем с авиакомпаниями, поэтому знаем всю подноготную тестирования IT-продуктов для этого бизнеса. Далее я расскажу, на что важно обращать внимание и в чём основная сложность обеспечения качества для ПО авиакомпаний.

Интеграции

ПО авиакомпаний обладает огромным количеством системной интеграции: отдельное ПО для менеджеров, для агентов, для стойки регистрации, для агрегаторов (Skyscanner, Aviasales, Яндекс.Путешествия и так далее).

Что важно:

• Даже малейшее изменение нужно проверить на всех смежных системах

Любое изменение, например, в покупке билета или рассадке людей необходимо проверить на огромном количестве систем. Допустим, появилось новое правило, что инвалиды не могут сидеть рядом с домашними животными. Звучит как кейс на десять минут. Но по факту, он занимает двое-трое суток — чтобы QA-команда все протестировала. Нужно проверить возможные вариации и роли, внутренние и международные перелёты, изменения мест рассадки: домашнее животное зарегистрировали на место раньше инвалида или после инвалида — как в этом случае поведет себя система?

• Тестировать ПО с точки зрения всех типов пользователей

Логика каждого ПО может работать по-разному, в зависимости от роли пользователя. Если это агент, который занимается покупкой билетов для частных лиц, то логика работает по одному принципу. А если это сотрудник авиакомпании, то по другому. Опять же, важно проводить тестирование продукта не с точки зрения IT-спеца, который выполняет свою работу, а с точки зрения пользователя: агента, сотрудника или менеджера, который проводит регистрацию на стойке в аэропорту. Помимо целостности системы, нужно проверить возможные вариации поведения пользователей, и как на них будет реагировать логика системы.

Логика рассадки

Логика рассадки — одна из самых сложных логик. На одном из проектов у нас был написан черновик по логике рассадки людей на 38 страниц, 12-м шрифтом, с единичным межстрочным интервалом — представляете себе масштабы?

Что важно:

• Отдельно тестировать не только робота авторассадки и ручной выбор, но и то, как они взаимодействуют между собой

Тестировать всё: как отработает робот, как отработает ручной выбор, как ручной выбор отработает после робота и наоборот. И это постоянно усложняется — особенно, когда внедряются зоны разделения пассажиров на борту самолета. А некоторые вещи тяжело проверить, если логика отрабатывает за два часа до вылета самолета. Учитывая то, что конфигурация на тестовой среде и на продуктовой разная, то не всегда получается сопоставить её. Поэтому приходится проверять отдельно на тестовой среде и отдельно на проде.

• При тестировании логики рассадки нужно включать собственную логику

Задачи по рассадке постоянно дорабатываются, появляются новые алгоритмы. Иногда встречаются противоположные друг другу кейсы поведения. Например, есть два варианта одной ситуации: человек может сидеть у аварийного выхода. А другой вариант этой же ситуации — не может. И ты начинаешь копаться — почему? Выходит так: что когда ребенок летит в место назначения, ему уже исполнилось 14 лет, и он может сидеть у аварийного выхода на обратном пути. А если выбрать на день раньше, то ребенку будет меньше 14 лет, и он не может сидеть там. В этом большая сложность: нужно учитывать логику пассажиров, логику поведения, логику рассадки, огромное количество правил. А ещё включать собственную логику.

Авторассадка

Авторассадка — это роботизированный сервис, который может не учитывать жизненные ситуации. И как результат — рассаживать пассажиров вразрез здравому смыслу.

Что важно:

• Проводить тестирование продукта с точки зрения жизненных ситуаций

Вот частый кейс: пользователь летит с большой семьёй и оформляет билеты через авторассадку. Что он ожидает? Ну, наверное, что людей с одинаковой фамилией посадят рядом. А в итоге всех рассадили в разных концах борта самолёта. Поэтому логику постоянно дорабатывают — дети должны сидеть рядом с родителями, семьи с младенцами не должны сидеть рядом друг с другом. Важно дорабатывать логику авторассадки с точки зрения здравого смысла. Например, домашнее животное не может находиться рядом с ребенком — такие вещи не всегда продумывают на стадии разработки.

Правила

Еще одна сложная вещь — это правила. В основном потому, что их очень много, они постоянно дорабатываются и добавляются.

Что важно:

• Разбираться в правилах, давать пояснения, регулярно добавлять правила на сайт/в приложение для пассажиров

Лучше всего эту проблему продемонстрирует кейс с домашними животными. Допустим, существует правило, что на борту может быть не более пяти пассажиров с животными. Пассажир с собакой-поводырём входит в это количество. И если на борту уже есть пять животных, то собаку-поводыря можно взять шестой. А обычный пользователь уже не может взять с собой домашнее животное — собака-поводырь всегда в приоритете.

Вот пример: человек бронирует билеты и сначала не добавляет собаку в билет, а через сутки решает всё-таки взять её с собой. Он заходит в «управление бронированием» — а там уже запрет на добавление собаки. И что он начинает делать? Он начинает долбить колл-центр. «А почему?»; «А раньше можно было!». А колл-центр, скорее всего, тоже не понимает, как так происходит. И это хорошо, если ему скажут, что у нас уже лимит — пять животных на борту. А бывает и такое, что можно принудительно добавить животное во внутренней системе, где работают операторы. Но не факт, что после такого добавления этот человек сможет нормально пройти регистрацию. Система будет выдавать ошибку, ведь на борту уже есть пять животных, а это — шестое. В итоге клиент нервничает.

Очень важно постоянно давать пояснения на сайте/ в приложении и четко писать правила. Логика меняется каждые две недели, а райтер приходит гораздо реже. Поэтому пользователи просто не понимают, что не так: почему они не могут посадить пятерых детей в один ряд; почему не могут взять собаку с собой. Правила нужно постоянно обновлять на сайтах и приложениях.

Вместо тысячи слов

Помимо тестирования огромного количества интеграций и правил, тестирования поведений пользователей, и как на них будет реагировать система — всегда важно включать собственную логику. И подходить к тестированию с позиции жизненной ситуации и здравого смысла. Разработка может не учитывать многие, хотя и понятные для пассажиров вещи. И здесь роль QA-команды огромна. Потому что от того, насколько детально и вдумчиво работают QA-специалисты, и к ним прислушивается продуктовая команда, зависит то, будут ли скандалы на борту самолета/ в аэропорту или нет; будет ли гореть служба поддержки в огне или нет. И самое главное — будут ли пользователи лояльны к бренду, захотят ли они выбрать именно эту авиакомпанию для перелёта или навсегда уйдут от неё из-за негативного опыта.

А что для вас важно при тестировании продуктов?