Тестировщики тоже продакты: как убедить команду разработки пилить непродуктовую фичу

Всем привет! Меня зовут Максим, я работаю тестировщиком в команде Pandora в hh.ru. Наша команда занимается доставкой сообщений пользователям: писем, пушей, смс, сообщений в VK и авторизационных звонков. Подробнее об этом можно почитать в другой статье. У нас была такая проблема: все инциденты, которые не смог решить саппорт, направлялись на уточнение и перепроверку мне. Эти 100 запросов и задач в квартал не только фатально сбивали меня, но и тормозили всю команду разработки. Так дальше продолжаться просто не могло.

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

Дано

Прежде чем приступить к разбору процесса работы с инцидентами от технической поддержки, представлю вам вводные:

• Инциденты от саппорта — это hhs;

• Тестировщик решает и сопровождает hhs, передавая баги в разработку;

• Все hhs имеют SLA;

• Решение hhs обычно занимает 30-60 минут;

• Сервис Aid отображает отправленные письма и статус доставки;

• Портфель — задачи для разработки и внедрения функциональности;

• Статистика: 105 hhs в 2022q4, 95 hhs в 2023q1.

Команда ответственна за две основные области в рамках статьи:

1. Доставка сообщений;

2. Поддержка и разработка сервиса Aid.

Количество пунктов в перечне может не впечатлить, но число разнообразных сообщений, которые необходимо сформировать и отправить с учетом определенных условий — совершенно точно будет ошеломляющим. Однажды я столкнулся с пользователем, который ежедневно ожидал рассылку с подходящими вакансиями строго до двух часов дня. Если рассылка приходила с задержкой, пользователь обращался в службу поддержки. Вот, например, эти 25 инцидентов от одного пользователя, которые дошли до меня от саппорта:

Теперь коротко про Aid. Сервис представляет собой одностраничный сайт, разработанный участниками «Школы программистов». Он позволяет осуществлять запросы в Hadoop и извлекать данные на основе электронной почты, даты и домена сайта.  Пример результатов запроса:

А вот и  проблемы, которые нужно было решить:

1. Неоднородность hhs;

2. Высокая занятость тестировщика;

3. hhs тормозят работу команды и доставку продукта;

4. Демотивация, которая неизбежно возникает при решении многочисленных однотипных hhs;

5. Частая смена контекста, которая сбивает с рабочего режима.

Проще говоря, частое решение hhs мешает поддержанию рабочей концентрации, отвлекает и иногда превращается в монотонную рутину. Но почему бы не написать код, который не вызывает hhs? Это интересная тема, которая требует отдельной статьи о «безопасной разработке».  Генерация hhs происходит главным образом из легаси-кода, и не всегда есть возможность провести рефакторинг или изменить бизнес-процесс.  Кроме того, на переработку трудно найти время, так как текущая функциональность все еще работает. Поэтому мы приняли решение сосредоточиться на доработке сервиса Aid, поскольку это более простой и экономически выгодный вариант, чем углубляться в рефакторинг. При планировании следующих функциональностей мы уже сразу думаем о том, не вызовем ли мы новую волну hhs и как этого можно избежать.

Выявляем проблемы

Когда я понял, что ежедневное взаимодействие с технической поддержкой не соответствует моим ожиданиям от работы, я обратился к руководителю команды, чтобы обсудить всякое и договориться о проведении разбора hhs. Мы достигли согласия на том, что я выделю наиболее проблемные моменты, а затем уже вместе обсудим возможные способы их решения.

Так я приступил к разбору задач от саппорта: выгрузил их в Miro, просмотрел каждую hhs и разложил по темам и подтемам.

Вот так, например, выглядел 4 квартал 2022 года:

Получилось выделить две главные проблемные темы: почта и SMS. Основная проблема с почтой заключалась в процессе доставки писем. Кроме того, мы получали множество запросов от клиентов, которые интересуются причинами отсутствия рассылки с подходящими вакансиями. Аналогичная проблема возникает и с рассылкой автопоиска.  В рамках проблемы с почтой отсутствует разделение между пользователями — соискателями и работодателями — мы просто определяем наиболее проблематичные темы.

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

Другие темы не так популярны, однако насторожил раздел «Бэкофис», где возникли проблемы, связанные с Aid. Это критическая область, где не должно быть никаких ошибок.

Рисуем карту, выстраиваем приоритеты

Я учел все инциденты и опыт работы с технической поддержкой, установил функциональность, которую нельзя проверить саппортом, и на основе этого составил roadmap развития сервиса Aid. Вот как он выглядит:

Мы установили следующие приоритеты развития Aid:

• Приоритет 1: определить количество необходимых запросов в Aid в hadoop;

• Приоритет 1.5: реализовать авторизацию в Aid;

• Приоритет 2: отображение анонимных автопоисков;

• Приоритет 2: проверка формирования подходящих вакансий к резюме; 

• Приоритет 2: информационные подсказки по статус доставки писем.

Добавляем метрики

Мы столкнулись с проблемой в работе сервиса Aid, который обращался к Hadoop для получения данных. Было замечено, что основные трудности возникали между 11 и 16 часами дня, когда количество запросов от пользователей в техническую поддержку было наивысшим. Кроме того, мы обнаружили, что параллельные запросы из других сервисов тормозили запросы в Aid. Чтобы решить эту проблему, мы приняли решение собрать дополнительные данные о запросах в Aid и использовать их для обращения к команде DWH.

Для сбора информации о работе сервиса Aid, я попросил разработчика добавить метрики, чтобы отслеживать время выполнения запросов и количество запросов в день. Это было необходимо, поскольку запросы, которые длились более 60 секунд, обрывались по таймауту, и техническая поддержка не получала результаты выгрузки. Вот пример ситуации, произошедшей 22 февраля 2023 года:

После получения метрик и выявления проблем, мы обратились к команде DWH с результатами и запросили выделение дополнительных ресурсов. Проблема оказалась на стороне DWH. Они выполнили обновление Trino с 369 версии до 409 и Java до версии 17. После обновления команда DWH столкнулась с падением Trino во время пиковых нагрузок ночью, поэтому приходилось обрабатывать тяжелые запросы днем, что и приводило к замедлению работы всех сервисов.

Для устранения проблемы им потребовалось настроить различные параметры Java, такие как xmx и другие опции. Только после настройки этих параметров сервис вновь заработал нормально и инциденты с Aid были исчерпаны.

Авторизация

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

Важно понимать, что Aid — далеко не самый приоритетный продукт в нашей команде. Он предназначен для поддержки, поэтому мы выделяем один портфель на квартал для внедрения крупной функциональности. Этим портфелем и был перевод Aid на новый фронт. Кроме того, мы успешно добавили метрики, что позволило выполнить программу развития сервиса в полном объеме. Еще одна хорошая новость заключалась в том, что доработка DWH была выполнена бесплатно — благодаря их ресурсам.

Также в первом квартале 2023 года, в рамках работы над портфелем, связанным с переводом SMS на нового провайдера, наш разработчик добавил функциональность поиска SMS в Aid по номеру телефона. Это произошло во время тестирования, когда у разработчика были свободные ресурсы. 

Идея такой доработки возникла из потребности в проверке отправки SMS техническим саппортом без необходимости обращаться к разным сайтам подрядчиков, где каждый имеет свой личный кабинет. Мы стремились иметь одно место, где можно было бы просмотреть все отправленные SMS, независимо от страны или провайдера SMS.

Теперь мы можем быстро проверить в Aid, была ли отправка SMS, не прибегая к поиску кабинетов у различных SMS-провайдеров. Ниже представлен пример результата поиска SMS по номеру телефона.

Все эти доработки уже доказали свою эффективность в сокращении нежелательных ситуаций — hhs стало меньше. Как и проблем с работоспособностью сервиса Aid.

Второй разбор полетов

Как только закончился первый квартал, я снова повторил разбор hhs. И вот что из этого вышло: 

На скринах можно заметить уменьшение инцидентов от саппорта — hhs. Все так же наибольшее количество задач имеет Почта, за ней следуют SMS/Звонки, а на третьем месте — Aid. Однако, это легко объясняется тем, что команда DWH работала над оптимизацией Trino, и процесс тестирования негативно сказался на работе Aid. Интересно увидеть, какая ситуация будет в третьем квартале.

С почтой тоже все ясно: у нас все еще оставались проблемы с доставкой, рассылкой подходящих вакансий и автопоиска. В отношении SMS возникли трудности с международной доставкой из-за перехода на нового оператора. А еще в тот период наблюдались массированные SMS-атаки.

Также появилась новая категория — «Каскад». Это внутренний термин, описывающий процесс, в котором работодатель приглашает соискателя по разным каналам связи. Если первоначальная попытка отправить сообщение не увенчается успехом, пробуется следующий канал и так далее. Например, «Каскад» может включать отправку Push-уведомления, затем сообщения во Вконтакте, и, если нужно, SMS. К сожалению, это проблема, которую нельзя быстро решить, так как требуется изменение давно существующей функциональности. Для решения этого бизнес-процесса, возможно, потребуется стать ее владельцем и пересмотреть механизм работы. Если эта проблема будет усугубляться, мы рассмотрим возможность дополнительных доработок в Aid или обратимся к текущим владельцам кода.

Также, у нас появилось дополнение к нашему Roadmap развития Aid. В первом квартале один из наших менеджеров обратился к технической поддержке и попросил дать обратную связь по Aid, чтобы мы могли учесть ее в будущем. Вот что мы получили:

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

Нам повезло, что техническая поддержка удовлетворена функционалом Aid, и большинство их пожеланий сводятся к микрофронтовым задачам. Мы реализовали их в процессе перевода Aid на новый фронт.

После решения двух ключевых задач для Aid — оптимизации работы и перевода на новый фронт с авторизацией — мы были готовы перейти к следующим портфелям задач.

Отрицательная доставка писем

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

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

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

Также я решил отложить еще один портфель, связанный с проверкой причин недоставки рассылки с подходящими вакансиями для резюме. Для его реализации требуется внедрение логики в Aid и дополнительное время на проработку. Тогда я предпочел сосредоточиться на функциональности, которую техпод не может проверить без участия команды разработки. А еще должна быть возможность быстро и экономично ее реализовать.

Отображение автопоисков в Aid

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

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

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

После реализации портфеля, связанного с отображением Автопоисков, я потратил свой ресурс на доработку во втором квартале. Как я уже говорил, у нас заложена всего одна функциональность в квартал. Однако!

Лучше всегда иметь в наличии несколько заранее проработанных портфелей. И если тимлид не знает, какой следующий портфель выдать разработчику, мы можем предложить уже готовый. Например, внедрение функциональности отображения отправленных пуш-уведомлений в Aid. Этот портфель подобен предыдущим, и его можно быстро реализовать. Хотя эта функциональность не является приоритетом в рамках Roadmap развития Aid, она позволит нам предоставить клиентам дополнительные возможности, расширяющие отображение практически всех отправляемых нами сообщений. А еще это упростит задачу мобильным тестировщикам, которым ранее приходилось выполнять запросы в хранилище для просмотра отправленных пуш-уведомлений.

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

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

Что дальше 

В перспективе у нас останется несколько портфелей второго приоритета, связанных с логикой и отображением. В него входят:

• Портфель отображения причин, по которым не формируется рассылка «Подходящие вакансии» для соискателей;

• Портфель отображения подсказок с причинам недоставки писем;

• Портфель отображения причин, по которым не формируется рассылка «Автопоиски».

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

Мы проводим эти улучшения не только для поддержки, но и для всей команды: сокращаем время, затрачиваемое на hhs, и позволяем технической поддержке самостоятельно решать запросы клиентов.

Посмотреть

Немного цифр

Вместо заключения приведу общую статистику по количеству hhs за каждый квартал:

• 4 квартал 2022 года: 105 hhs;

• 1 квартал 2023 года: 95 hhs;

• 2 квартал 2023 года: 76 hhs.

Общее количество времени, потраченное на разработку различных функций в Aid:

• Перенос Aid на новый фронт и реализация авторизации: 14 дней;

• Добавление метрик: 10 дней;

• Доработка фич по обратной связи: 2 дня;

• Отображение Push-уведомлений: 11 дней;

• Отображение автопоисков: 8 дней;

• Отображение SMS-сообщений: 4 дня.

Общее время, затраченное на разработку функционала в Aid, составляет: 49 дней.

Хорошие результаты!