Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды

в 4:06, , рубрики: gtd, qa, qa management, Блог компании 2ГИС, Процессы в IT, тестирование, Тестирование IT-систем, Тестирование мобильных приложений, тестирование по, управление проектами

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 1

Привет. Меня зовут Даша, тестирую мобильное приложение 2ГИС на iOS. Хочу поделиться нашим процессом ведения фич, который помогает не только сэкономить время, но и прокачать личные скиллы. Прочитайте статью, чтобы узнать, как нам удаётся удерживать в едином контексте продактов, дизайнеров, разработку. Мы верим, что ревью первой тестовой сборки всеми заинтересованными действительно облегчает людям жизнь. А коммуникация — ключевой момент в ведении фичи.

Наша боль

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

Раньше у нас тоже было что-то похожее: при планировании спринта прилетала задача, в начале спринта её брали в разработку, прорабатывали задачу уже в процессе. Если возникали вопросы по взаимодействию с другими командами — шли к продакту. Часто бывало, что в одних командах работа уже шла полным ходом: все предвкушали релиз, кому-то фича уже снилась на бою; а в другой команде даже не знали про её существование. Такой процесс был неэффективным, тратил кучу сил/времени, вносил хаос.

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

О команде

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

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

Релиз за 9 этапов

Весь процесс доведения фичи до релиза можно поделить на 9 основных этапов. Для наглядности возьмём недавно вышедшую фичу «Награды» и расскажем, как мы провели её по всем девяти этапам.

Награды — это поощрение юзеров за вклад в продукт. Пользователи получают их за написание отзывов, загрузку фотографий, добавление новых компаний в справочник. Их можно увидеть на табе «Мой 2ГИС».

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 2

Этап 1 — Процесс проработки ТЗ

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

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 3

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

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 4

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

Этап 2 — Составление чек-листа

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

Этап 3 — Разработка

После проработки ТЗ началась разработка фичи. Тестирование в это время дозакрывало/дообсуждало незакрытые вопросы в ТЗ и чатике, информировало разработку обо всех изменениях, если такие появлялись: новые требования, новые дизайны, новые тексты, да что угодно — разработка должна быть в курсе всего, иначе не избежать драки.

Этап 4 — Ревью первой сборки фичи

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 5

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

Пример неприятной ситуации

Сидишь спокойно вечером дома, никого не трогаешь. Думаешь, что всё позади, завтра фича выйдет на бой. Но тут в час ночи к тебе домой врывается злой продакт (это реально, потому что она живёт тремя этажами выше меня) или дизайнер (это уже менее реально, он далеко от меня живёт, но у него машина есть) с требованиями срочно исправить шрифт/цвет/отступы, иначе «не быть релизу! так выходить нельзя», а на утро уже пиар-компания намечена, и всё, всё идёт коту под хвост. И вот ты в два часа ночи сидишь, дозваниваешься разработчику, заводишь тикеты. В общем, своевременно полученный фидбек от нужных людей — это ценно. Именно получение его в самом начале не даст затянуть релиз с этого фланга.

Этап 5 —Тестирование на платформе

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

На этом же этапе бывали изменения в логике фичи (UI, например) — также давали сборку продакту и дизайнеру на ревью, чтобы убедиться, что ожидания совпали с реальностью.

Этап 6 — Интеграционное тестирование

Этот пункт необходим, если в разработке фичи участвуют иные команды, помимо мобилок. Например, мобилки + бэкенд. Если мы заменили шрифт или цвет иконки, тут, естественно, никаких интеграций не проходит. Однако, в нашем примере с Наградами задействован бэкенд — без интеграции было не обойтись.
Первым делом составили доку в Confluenсe. Как правило, вначале этим занимается один человек.

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

Составив доку, я скинула её в чатик фичи и призвала всех участников интеграции для ревью/дополнения кейсов.

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 6

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

Этап 7 — Инструктаж поддержки

Перед релизом сообщили поддержке, что скоро выйдет фича, пора готовиться. Дали почитать ТЗ, потыкать сборку. Сообщили, в какие чаты надо писать и к кому обращаться, если поступит фидбек от пользователей.

Этап 8 — Релиз

Как мы тестируем фичу от ТЗ до пост-продакшена и сохраняем дружеские отношения внутри команды - 7
Начали катить фичу, оповестили об этом чат и параллельно следили за Crashlytics, фидбеком в сторе и поддержке. Надеялись на лучшее, пили валерьянку. С Наградами всё прошло гладко, но мы были готовы незамедлительно сделать хотфикс и проинформировать всех в чатике фичи, если бы во время раскатки обнаружился критичный баг на стороне платформы.

Этап 9 — Поддержка фичи после релиза

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

А если кратко

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

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

Автор: Даша Кормушина

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js