QA и Support: как не усложнять друг другу жизнь
Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия 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 решили и продолжаем работать над улучшением наших процессов и по сей день. Надеюсь, наш опыт будет полезен.