Хабрахабр

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

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

Наша боль

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

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

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

О команде

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 8 — Релиз


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

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

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

А если кратко

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»