Добрый день, меня зовут Александр Уланов, я инженер по тестированию в компании «Одноклассники». В этой статье я хотел бы рассказать об одном из проектов, в котором я участвовал. Сразу предупрежу: в статье вы не найдете каких-то открытий и сложных подходов к методологии тестирования. Однако процесс разработки и тестирования, описанный в статье, возможно, для кого-то может оказаться интересным или даже полезным.

Эпизод 1: Страх и ненависть при OTRS

OTRS — система обработки заявок, которая позволяет организациям, занимающимся технической поддержкой каких-либо проектов, совместно работать над решением проблем пользователей. Система написана на языке Perl и поддерживалась разработчиками до ноября 2017 года.

Именно системой OTRS мы долгие годы пользовались для обработки всех обращений от пользователей. Решение использовать OTRS было принято много лет назад. Тогда стояла простая задача: найти готовое решение и максимально быстро приспособить его под наши цели. И это было ужасно, объясню почему:

• мы использовали кастомизированную под наши нужды версию системы OTRS и поэтому обновлять ее (вплоть до осени 2017 года) было, мягко говоря, затруднительно;
• со временем мы стали понимать, что система упирается в свой «потолок» нагрузки и перестает справляться с количеством заявок, которые поступают от наших пользователей;
• система OTRS была интегрирована в общую инфраструктуру таким образом, что полностью зависела от апдейтов социальной сети OK.ru. Что давало возможность обновлять OTRS лишь раз в неделю;
• штат из 90 сотрудников саппорта мог обеспечивать ответы на жалобы лишь в течение нескольких часов;
• тестирование каждого апдейта системы с нашей стороны превращался в кошмар, т.к. даже малейшие изменения могли поломать систему в любом из узлов. Когда же речь шла о добавлении нового функционала — процесс разработки и тестирования оборачивался неделями отладки системы;
• сам OTRS написан на Perl. Языке, который практически не использовался в проектах OK.ru, что накладывало дополнительные проблемы;
• и, пожалуй, самая главная проблема – ПОЧТА! OTRS обрабатывал жалобы в виде электронной почты. И это в 2016-2017 году! Отсюда тонны настроек, особенности работы с почтовыми сервисами и долгие ожидания ответов для пользователей, которые неизбежны при общении с саппортом через почту.

Эпизод 2: что мы хотели получить

Идея полного ухода от OTRS начала развиваться в компании с 2015 года. Ключевая задача: избавиться от использования почты и обеспечить возможность быстро и своевременно отвечать пользователям без многократного увеличения штата сотрудников саппорта. Самое очевидное решение — online-служба поддержки.

Также никто не хотел тратить ресурсы на полностью новую систему. Логичнее использовать свои внутренние сервисы, по функционированию которых уже есть опыт и тест-покрытие. Плюс чисто техническое требование: получить возможность делать обновления новой системы когда угодно и не зависеть от других команд. Что обещало нам гибкость при разработке и тестировании.

Примерно в тот же период в OK.ru происходила глобальная модернизация системы сообщений. Именно на основе нового месседжинга было принято решение реализовать новую систему online-support (далее по тексту — «oSupp»).

Эпизод 3: планирование

На первых этапах разработки oSupp и в результате многочисленных встреч мы видели ряд проблем. Основная — невозможно разом в одночасье переключить всю работу с OTRS на oSupp:

• нужно было полноценно оценить, как новая система справляется с технической нагрузкой (напомню, речь идет об обработке 10-12К жалоб в сутки);
• нужно было обучить сотрудников работе в новой системе;
• нужно было провести A/B тестирование как на пользователях, так и на сотрудниках саппорта и оценить, как они будут справляться с нагрузкой;
• техническое ограничение: месседжинг OK.ru никогда до этого не работал с неавторизованными пользователями. А в работе саппорта общение с неавторизованными юзерами — это чуть ли не треть всех тысяч жалоб;
• для тестирования системы нужно поднять среду, максимально схожую с реальной, но без доступа к «живым» пользователям.

Мы решили, что оптимальный путь — произвести реализацию и внедрение oSupp в три этапа:

1. Разработка и тестирование прототипа.
2. Внедрение oSupp для обработки обращений от авторизованных пользователей OK.ru.
3. Полноценное покрытие всех обращений новой системой oSupp.

Эпизод 4: тестирование и ввод в эксплуатацию

Для тестирования прототипа было создано тестовое окружение с возможностью генерировать обращения от тестовых пользователей и возможностью подключить oSupp к тестовой среде OK.ru. Тут должен отметить, что новая система разрабатывалась таким образом, что со стороны пользователя до момента непосредственного общения с оператором не менялось ничего. Остался привычный раздел «Помощь», сохранилась узнаваемая типизация тем обращений по сайту и FAQ.

До этого момента в плане тестирования не менялось ничего. Все тест-планы и покрытие автотестами не менялось. У — удобство!



После того как пользователь находил тему обращения и заполнял требуемые поля обращение падало в систему oSupp, а у пользователя прямо в разделе «Сообщения» появлялся чат с одним из сотрудников саппорта. Диалог начинался моментально при наличии в системе свободного оператора. В противном случае чат так же создавался, и пользователь получал автоматическое первое сообщение «Оператор свяжется с вами в ближайшее время».



Опять же — минимум изменений в процессе тестирования. Это обычный чат, и для него не требовалось составлять новые тест-планы. У — удобство!

А вот для обеспечения работы сотрудников система создавалась с нуля. Нужна была быстрая система, которая бы позволяла вести одновременную работу для нескольких десятков сотрудников в режиме online и которая была бы способна обрабатывать тысячи обращений в сутки.



Разработка и тестирование производились итеративно. Примерно раз в неделю мы добавляли в систему новые функциональные модули, что позволяло не копить задачи и постепенно покрывать систему тестами. Я составлял текст-кейсы для тестирования, параллельно выделяя из них те, которые возможно автоматизировать. Процесс разработки полноценно функционирующего прототипа занял у нас около пяти месяцев.

В результате мы получили web-сервис, куда мог залогиниться сотрудник-оператор и принимать к обработке заявки от пользователей. Для группы сотрудников саппорта мы несколько раз проводили А/В тестирование, чтобы уже на этом этапе понять, насколько им удобно и понятно работать в новой системе. Это был полезный опыт. Систему oSupp мы смогли проверить на искусственно созданной нагрузке нашего test-окружения. Однако это не давало гарантий, что в реальной среде мы не столкнемся с проблемами.

В феврале 2017 года мы начали внедрять новую систему в продуктовую среду. Как я писал ранее, при обращении в службу поддержки пользователь должен выбрать тему обращения. Для первых тестов системы на реальных пользователях мы выбрали несколько тем, нагрузка по которым была минимальна. Система проработала в таком виде около недели. А/В тестирование для пользователей не потребовалось, т.к. изменений функционала со стороны портала практически не было. Со стороны oSupp три оператора, находящиеся online, справлялись с нагрузкой. Мы оперативно отслеживали проблемы, которые моментально могли исправлять, т.к. новая система oSupp больше не была завязана на апдейты основного портала. Теперь обновлять систему и исправлять проблемы мы могли тогда, когда хотели. У — удобство!

Постепенно мы увеличивали количество тем, обрабатываемых через новую систему. Таким плавным развертыванием мы не только могли контролировать нагрузку, но и постепенно обучали сотрудников саппорта работе с новой системой без необходимости отвлекать их от остальной работы. К середине лета 2017 года около 35 % тем обращений были переведены на обработку online-сервисом. Уже треть нашего штата сотрудников работали через oSupp. Система была покрыта документацией, тест-планами и минимально необходимыми автотестами, которые запускались при обновлении системы. К декабрю 2017 года мы перевели в онлайн все заявки от авторизированных пользователей.

Следующий важный этап — обеспечение online-поддержки для пользователей, которые испытывают проблемы с аутентификацией. Речь о тех, кто забыл пароль, был взломан, заблокирован, либо просто пользователи с нестандартными обращениями. Ключевая техническая проблема на этом этапе — система сообщений OK.ru исторически рассчитывалась на переписку вида «пользователь ОК (оператор саппорта в нашем случае) — пользователь ОК». Нам же требовалось обеспечить работу ситуации «пользователь ОК (оператор) — неавторизированный пользователь».

Началась плотная работа команды саппорта с командой сообщений OK.ru. В итоге были придуманы решения, которые позволяли прямо на экране логина OK.ru получать online-чат с оператором службы поддержки. При этом уже существующая и введенная в эксплуатацию система oSupp изменений не требовала. А новая сущность online-чата работала на доработанном движке месседжинга OK.ru. У — удобство!



К реализации этого решения мы приступили в начале 2018 года. В плане тестирования также не было особых трудностей, т.к. подобный чат обладал минимальным набором функционала. В первую очередь мы запустили поддержку жалоб от неавторизированных пользователей с web. На данный момент идет реализация поддержки подобных жалоб с мобильных приложений.

Эпизод 5: итоги

Из состояния прототипа в полноценно работающий сервис oSupp перешел к лету 2018 года. По данным на март 2019 года 60 % обращений обрабатывается через online-поддержку. Штат сотрудников при этом изменен не был. 90 сотрудников службы саппорта в режиме online охватывают порядка 6000 жалоб от пользователей ежесуточно. В пиковую активность на портале ожидание ответа от оператора занимает до 10 минут. При обычной нагрузке операторы отвечают в течение 1-2 минут. Благодаря переходу на «живое» online-общение на 15 % выросли успешные восстановления доступа к профилю у пользователей.

Теперь мы обладаем 100 % собственным продуктом, вольны дорабатывать его как и когда угодно. Команда больше не зависит от обновлений портала OK.ru. Новая система обработки заявок написана на языке Java, на котором реализованы многие сервисы OK.ru. Процесс тестирования системы oSupp полностью покрыт тест-кейсами, а при обновлениях подстраховывается автоматическим тестированием.

Должен отметить, что полностью мы не отказались от OTRS. Система offline-поддержки была заморожена в середине 2017 года, и сейчас выполняет роль страховки. Туда попадают обращения от недобросовестных пользователей, которые любят бесцельно спамить в службу поддержки. Так же через OTRS осуществляется обработка обращений, которые по специфическим причинам пользователей не могут быть обработаны online. Сейчас в планах нашей команды стоит реализация обработки обращений, поступающих из мобильных приложений и внедрение в работу системы чат-ботов.



Однако главная наша цель была достигнута — мы уходим от использования почты. Теперь для решения проблем наши пользователи получают быстрые и своевременные ответы.
Наше главное достижение: для пользователя существенно сократилось время ожидания ответа и получения помощи.