QA и Support: как не усложнять друг другу жизнь
Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.
Начало пути
Когда я пришла в Mobile Skyeng, нас, тестировщиков, было двое. В начале основную часть своего рабочего времени я погружалась в проект, знакомилась с инструментами тестирования и общими процессами. В оставшееся время понемногу тестировала задачи.
На имеющиеся четыре мобильные приложения мы ежедневно получали обращения от пользователей через отдел техподдержки. Общий и мобильный саппорт раскидывали обращения по двум разным каналам в Slack, а мы с коллегой должны были их разбирать в свободное от тестирования время. И вот вскоре меня стали тэгать в сообщениях с обращениями пользователей. Только как их обрабатывать я не знала — изучение функционала было в процессе.
У меня не было регламента: как / когда / сколько времени тратить на обработку. Как следствие, по некоторым минорным багам долго не было ответа, я не всегда вовремя успевала закрывать треды. Таким образом, обозначилась первая проблема взаимодействия с саппортом — отсутствие правил передачи обращений и их последующей обработки.
Следующая проблема — не было актуальной документации, по которой техподдержка могла бы отвечать пользователям по функционалу приложений. На актуализацию попросту не хватало времени. Это приводило к тому, что периодически дергали с вопросами в личке или в каналах для багов.
Иногда меня призывали проверять обращения по мобильному браузеру, хотя я тестировала только приложение. Это происходило, так как не были определены зоны ответственности и не прописано, кто и за что отвечает. Спустя три недели мне прилетел список из примерно 20+ тредов про мобильные баги, которые собрал QA-лид веб команды из общего канала. Пришлось отложить тестирование и заняться этими обращениями. Времени на это ушло много.
Итак, расклад следующий:
регламента обработки обращений для QA нет;
актуальной документации на функционал приложения для техподдержки нет;
понимания, где границы ответственности QA, а где техподдержки — тоже нет.
Точка отсчета и простые решения
После очередного обновления нашего приложения обращений стало заметно больше. Мы постепенно стали заменять вебвью слайды домашних заданий на нативный рендер. Он вызывал много вопросов у пользователей и приводил к специфичным багам, которые воспроизводились только в конкретных обучающих материалах.
Мы с коллегой решили, что нужно упорядочить процесс обработки обращений, чтобы у нас появились ориентиры — сколько времени есть на тестирование, сколько — на обработку багов. Поговорили о сложившейся ситуации с лидами веб платформы и совместно с мобильным саппортом приняли решение задокументировать флоу обработки сообщений, а также определили стратегию по созданию коммуникации QA-Support.
Первый шаг с нашей стороны — создали канал #mobile-bugs, куда весь отдел технической поддержки стал приносить баги, которые воспроизводятся только в мобильном приложении. Параллельно мы создали документ с описанием процесса обработки обращений. В нём указали, кто за какой функционал отвечает, утвердили SLA и прочее. В шапку канала добавили ссылку на этот документ.
Определили флоу для тестировщиков по багам:
тестирование сборок в приоритете;
в течении дня проверяем канал #mobile-bugs на предмет новых обращений;
критикалы и блокеры должны быть обработаны в течении 15 минут;
всё, что ниже по приоритету, должно быть по возможности обработано в течении дня;
если на текущий момент нет задач в тестировании, то сначала смотрим обращения, после занимаемся другими делами.
Дополнительно мы записали видео, демонстрирующее отличия нативного рендера от вебвью. Его передали ребятам из саппорта, чтобы они сделали себе памятку.
Второй шаг предприняла техподдержка — была увеличена и укомплектована команда мобильного саппорта, котораяи стала обрабатывать все баги, касающиеся мобильного приложения. Другие линии техподдержки при появлении аналогичных обращений передавали их в эту команду узких специалистов. В чем плюсы такой команды:
каждому сотруднику Mobile Support компания выделила дополнительные девайсы для воспроизведения багов;
ребятам выдали доступы к эмуляторам для проверок специфичных кейсов;
саппорт стал тесно взаимодействовать с QA мобилки. Благодаря чему, они всегда в одном с нами инфополе;
так как команда маленькая и хорошо владеет функционалом всех четырех приложений, нам — тестировщикам, проще донести информацию о новых фичах и изменениях.
Самое важное, что наш мобильный саппорт держался с нами на передовой: ребята были в курсе всех изменений продукта и первыми узнавали о багах, появляющихся на проде в свежих версиях приложения. Благодаря новым инструментам для диагностики и знаниям о самых последних апдейтах, команда самостоятельно проверяла проблему и передавала тестировщикам. В целом, нам всем стало комфортно вместе работать.
Третий шаг с нашей стороны — создали воркфлоу для мобильного саппорта.
Решили действовать в случае проблем с домашними заданиями в приложении по такому алгоритму:
Саппорту нужно проверить проблему в веб-версии в мобильном браузере (Сhrome / Ыafari). В случае воспроизведения передать в общую техподдержку или канал #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 решили и продолжаем работать над улучшением наших процессов и по сей день. Надеюсь, наш опыт будет полезен.
