Привет! На связи отдел QA в Purrweb. Не так давно мы с ребятами опробовали новый способ отслеживания багов — охотно делюсь впечатлениями.
Что такое Vercel
Vercel — платформа, которая позволяет развертывать веб-сервисы в облаке. С ее помощью разработчики размещают статические веб-сайты, которые развертываются мгновенно, а QA команда может протестировать их в этом же окружении. Vercel не требует настройки и работает с любым типом веб-инфраструктуры. Здесь можно получать предварительный URL-адрес, которым можно делиться со своими тиммейтами для совместной работы.
Работает так: разработчик скидывает ссылку на ветку, а тестировщик ищет баги прямо внутри сервиса. Когда разработчик исправил баги и все хорошо, ветку заливают на стейдж, и после этого QA специалисты проверяют стейдж, чтобы убедиться, что все работает как надо.
Как тестировали раньше
Объясню на примере абстрактного проекта, где одновременно работают 3 разработчика и 1 тимлид.
Вот как было 4 месяца назад: для того, чтобы можно было запустить процесс тестирования фронтенда, тимлид сперва мерджил все, что сделала его команда, а после заливал это на стейдж. По итогу мне на проверку прилетал готовый билд.
Открываю стейдж и начинаю работать.
С помощью колонки QA-waiting в Jira я могла сориентироваться по местам, которые нужно «прочекать»
По завершению тестирования карточки отправляются в:
- Done — если все нормально.
- Backlog — если это новые баги.
- To do (с комментариями в карточках) — если ничего не работало. Либо, когда это что-то критичное, что было прописано в задаче — например, когда не доделан какой-то конкретный кусочек задачи.
Раздел Backlog: цветные метки обозначают эпики
Зачем в бэклоге эпики? Фильтруя задачи по конкретным эпикам, мы могли понять, с какими именно багами нужно разобраться. К примеру, если нам, в первую очередь, нужно было закончить таски по онбордингу, ребята могли кликнуть по этому эпику и увидеть все, что к нему относится.
А теперь о главном.
Jira — хранилище всех багов. C какими недостатками столкнулись
Первое: все косяки плавали на дне бэклога, ожидая специально отведенного Дня Багов (который, к слову, никуда не делся). Даже за мелкие огрехи в верстке мы могли приниматься только неделю-полторы спустя.
Второе: (и это плавно вытекает из первого): проектная команда — это динамичный, живой организм. Из-за того, что за баги подолгу никто не брался, часто выходило так, что задачи, которые начинал делать один разработчик, нужно было передавать кому-то другому — просто потому что первый занят другой важной задачей/сломал ногу/взял отпуск/уволился.
Третье: (и тут меня поддержит каждый участник проектной команды): задачи, к которым ты вернулся месяц или 2 месяца спустя, в разы больнее закрывать. Это как с написанием статьи: если по ходу работы над текстом игнорировать расставление запятых, то на этапе публикации его придется перелопачивать заново — не раз и не два. По-другому их просто не расставить. Точно так же это работает и с тестированием фронтенда: даже если это супер-мелкая деталь, ее нужно сперва отыскать, убедиться, что внесенные изменения не поломают то, что работало раньше, и только потом уже править.
Переход на Vercel: зачем? Как это?
О новом подходе к тестированию фронтенда нас попросил заказчик на одном из проектов — это был финансовый B2B сервис HeadCount. Если опустить просьбу клиента, хотели ли бы мы попробовать что-то новое? Возможно. Понимали ли, что прежний формат баг-трекинга можно назвать совершенным разве что с натяжкой? Очень может быть. Так или иначе, мы пришли к платформе Vercel — пришли и поняли, как круто эта штука работает.
Расскажу немного об изменениях в процессе отслеживания и починки багов. Из главного — теперь можно тестировать изолированную работу одного разработчика еще до мерджа веток тимлидом.
Каждый участник dev-команды генерит свою собственную ссылку и отправляет ее на «потестить»
Как закрываем задачу «Передать в тестирование – принять и обработать фидбек»? Помогают project-каналы в Slack.
Отличный инструмент, позволяющий быстро засинхрониться
Для обсуждения багов у нас есть подход — он ни разу не уникальный, но очень рабочий 🙂 Ускорить общение помогают эмоджи, где:
⚠️ — когда по задаче есть комментарий. Это помогает быстрее отыскать то, что еще не поправили. По тому, что конкретно нужно поправить, я отписываюсь в слаке.
➕ — когда задача проверена и с ней все окей. О том, что все работает исправно, я также отписываюсь тимлиду в треде — для него это сигнал о том, что ветку можно заливать. Кстати, когда тимлид ставит ветку, он тоже ставит +.
👌 — когда разработчик сообщает, что по задаче есть нюансы. Например, если решили пока ее не делать или делать, но по-другому. Чтобы показать, что я в курсе.
Эмоджи всего 3, а пользы масса. Самый большой плюс — команда четко понимает, что происходит с той или иной задачей. Не перелопачивая при этом бесконечные threads в переписке.
Преимущества Vercel при тестировании фронтенда
У каждой из сторон свои собственные.
Для клиента: «В продакшен попадает более стабильная и “чистая” версия продукта. Чище продукт — счастливее клиент».
Вы спросите: «А что с тестировщиками?» Я скажу так: C Vercel задачи приходят постепенно, по мере готовности. Мне так же, как и разработчикам, не приходится возвращаться к мелким таскам спустя продолжительный промежуток времени и вспоминать #шожтамбыло. И это чертовски круто!
А вот иллюстративный пример из нашей практики тестирования фронтенда:
На одном из проектов ребята выкатили билд, где я нашла 28 багов. Все мелкие — где-то подвинуть пиксель вправо/влево, где-то добавить жирность шрифта. Если бы выкатили такую версию заказчику, он бы точно расстроился (что справедливо). В случае же с Vercel мы оставили это за «завесой», и интерфейсные косяки не дошли даже до тестового сервера.
Что стало с Jira? А с Днем Багов?
Вывалилась ли Jira из нашего баг-трекинг процесса? Нет, конечно. Jira перестала быть главным инструментом локально, однако на этапе интеграционного и регрессионного тестирований она по-прежнему осталась.
А с Днем Багов что? Он никуда не делся — починкой дефектов, мы, как и прежде, занимаемся в конце каждого спринта. Однако изменения все же случились. Из главного — разгребая все ургентно-мелкое на берегу, мы наконец-то начали жить счастливо и укладываться в 1-2 дня.
Зачем это все
Причины две.
Первая: наша команда обожает тестировать новые штуки.
Вторая: мы хотим улучшать процессы в разработке продуктов. Хотим, чтобы клиентам было в кайф возвращаться к нам снова. Так было, так есть и так будет всегда.
Облегчил ли Vercel жизнь конкретно мне? Да нет же, наоборот — с его появлением моя вовлеченность в командные процессы сильно выросла. 1-2 дня «тотального» тестирования фронтенда под конец спринта сменились на ежедневный «точечный» мониторинг прогресса всех участников команды. Апдейты по багам, общение — этого стало в разы больше. И все ради качественного результата на выходе.
