Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.

Начало пути

Когда я пришла в Mobile Skyeng, нас, тестировщиков, было двое. Основную часть своего рабочего времени я погружалась в проект, знакомилась с инструментами тестирования и общими процессами. В оставшееся время понемногу тестировала задачи.

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

У меня не было регламента: как / когда / сколько времени тратить на обработку. Как следствие, по некоторым минорным багам долго не было ответа, я не всегда вовремя успевала закрывать треды. Таким образом, обозначилась первая проблема взаимодействия с саппортом — отсутствие правил передачи обращений и их последующей обработки.

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

Иногда меня призывали проверять обращения по мобильному браузеру, хотя я тестировала только приложение. Это происходило, так как не были определены зоны ответственности и не прописано, кто и за что отвечает. Спустя три недели мне прилетел список из примерно 20+ тредов про мобильные баги, которые собрал QA-лид веб команды из общего канала. Пришлось отложить тестирование и заняться этими обращениями. Времени на это ушло много.

Итак, расклад следующий:

• регламента обработки обращений для QA нет;

• актуальной документации на функционал приложения для техподдержки нет;

• понимания, где границы ответственности QA, а где техподдержки — тоже нет.

Точка отсчета и простые решения

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

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

Первый шаг с нашей стороны — создали канал #mobile-bugs, куда весь отдел технической поддержки стал приносить баги, которые воспроизводятся только в мобильном приложении. Параллельно мы создали документ с описанием процесса обработки обращений. В нём указали, кто за какой функционал отвечает, утвердили SLA и прочее. В шапку канала добавили ссылку на этот документ. 

Определили флоу для тестировщиков по багам:

• тестирование сборок в приоритете;

• в течении дня проверяем канал #mobile-bugs на предмет новых обращений;

• критикалы и блокеры должны быть обработаны в течении 15 минут;

• всё, что ниже по приоритету, должно быть по возможности обработано в течении дня;

• если на текущий момент нет задач в тестировании, то сначала смотрим обращения, после занимаемся другими делами.

Дополнительно записали видео, демонстрирующее отличия нативного рендера от вебвью. Его передали ребятам из саппорта, чтобы они сделали себе памятку. 

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

• каждому сотруднику Mobile Support компания выделила дополнительные девайсы для воспроизведения багов;

• ребятам выдали доступы к эмуляторам для проверок специфичных кейсов;

• саппорт стал тесно взаимодействовать с QA мобилки. Благодаря чему, они всегда в одном с нами инфополе;

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

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

Третий шаг с нашей стороны — создали воркфлоу для мобильного саппорта.

Решили действовать в случае проблем с домашними заданиями в приложении по такому алгоритму:

• Саппорту нужно проверить проблему в веб-версии в мобильном браузере (Сhrome / Safari). В случае воспроизведения передать в общую техподдержку или канал #vim-bugs. Vim — это сокращение от Vimbox, названия нашей платформы, где ученики занимаются с преподавателями или самостоятельно.

• Если проблема воспроизводится только в мобильном приложении, то разделять натив #mobile-bugs / вебвью #vim-bugs.

  

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

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

Четвертый шаг — утвердили удобную структуру оформления обращений 

Есть отдельный канал, есть команда, но многим багам не хватало описания. Ребята могли принести обращения вроде «не работает тренировка, посмотрите в чем дело». Или бывало, что отсутствовала информация об устройстве, версии ОС и версии нашего приложения. Решили, что надо обновить шаблон оформления репорта в канале.

Привели его примерно к такому виду:

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

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

Систему настроили, работает, но подул ветер перемен

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

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

Наша команда QA частично была к этому готова. Сначала было сложновато, поскольку к нам пришли новые команды техподдержки, а это порядка 50 человек, которые ранее не обрабатывали обращения по нашим мобильным приложениям. Но мы быстро модифицировали наш флоу и заменили экспертность более сильным обучением. Дополнительно все релизы мы стали описывать в отдельных подробных постах, чтобы все сотрудники саппорта были в курсе происходящего. 

Подробнее опишу этапы наших действий.

Во-первых, мы обновили шаблон обращения в канале #mobile-bugs. Разбили его на отдельные поля ввода, чтобы у оформляющего сразу перед глазами было всё обязательное к заполнению. 

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

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

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

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

И еще создали канал #mobile-tasks, куда падают все заведенные в Jira баги. По поиску в канале также можно найти похожие кейсы.

В-четвертых, совместно с лидом мы решили взять в команду стажера — QA Trainee. Его основная задача — расти в QA и учиться в процессе работы. 

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

Заключение

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

Отсутствие ясного флоу межкомандного взаимодействия, нечеткие зоны ответственности и нехватка информации об обновлениях приводят к тому, что обращение может «зависнуть» и в итоге страдают все: QA, сотрудники саппорта и, самое неприятное, наши пользователи. Мы для себя проблему коммуникации QA — Support решили и продолжаем работать над улучшением наших процессов и по сей день. Надеюсь, наш опыт будет полезен.