Тестирование веб приложений с Vercel: без лишних мерджей и головняка

Что такое Vercel

Vercel — платформа, которая позволяет развертывать веб-сервисы в облаке. С ее помощью разработчики размещают статические веб-сайты, которые развертываются мгновенно, а QA команда может протестировать их в этом же окружении. Vercel не требует настройки и работает с любым типом веб-инфраструктуры. Здесь можно получать предварительный URL-адрес, которым можно делиться со своими тиммейтами для совместной работы.

Работает так: разработчик скидывает ссылку на ветку, а тестировщик ищет баги прямо внутри сервиса. Когда разработчик исправил баги и все хорошо, ветку заливают на стейдж, и после этого QA специалисты проверяют стейдж, чтобы убедиться, что все работает как надо.

Как тестировали раньше

Объясню на примере абстрактного проекта, где одновременно работают 3 разработчика и 1 тимлид.

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

Открываю стейдж и начинаю работать.ё

По завершению тестирования карточки отправляются в:

• Done — если все нормально.
• Backlog — если это новые баги.
• To do (с комментариями в карточках) — если ничего не работало. Либо, когда это что-то критичное, что было прописано в задаче — например, когда не доделан какой-то конкретный кусочек задачи.

Зачем в бэклоге эпики? Фильтруя задачи по конкретным эпикам, мы могли понять, с какими именно багами нужно разобраться. К примеру, если нам, в первую очередь, нужно было закончить таски по онбордингу, ребята могли кликнуть по этому эпику и увидеть все, что к нему относится.

А теперь о главном.

Jira — хранилище всех багов. C какими недостатками столкнулись

Первое: все косяки плавали на дне бэклога, ожидая специально отведенного Дня Багов (который, к слову, никуда не делся). Даже за мелкие огрехи в верстке мы могли приниматься только неделю-полторы спустя.

Второе: (и это плавно вытекает из первого): проектная команда — это динамичный, живой организм. Из-за того, что за баги подолгу никто не брался, часто выходило так, что задачи, которые начинал делать один разработчик, нужно было передавать кому-то другому — просто потому что первый занят другой важной задачей/сломал ногу/взял отпуск/уволился.

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

Переход на Vercel: зачем? Как это?

О новом подходе к тестированию фронтенда нас попросил заказчик на одном из проектов — это был финансовый B2B сервис HeadCount. Если опустить просьбу клиента, хотели ли бы мы попробовать что-то новое? Возможно. Понимали ли, что прежний формат баг-трекинга можно назвать совершенным разве что с натяжкой? Очень может быть. Так или иначе, мы пришли к платформе Vercel — пришли и поняли, как круто эта штука работает.

Расскажу немного об изменениях в процессе отслеживания и починки багов. Из главного — теперь можно тестировать изолированную работу одного разработчика еще до мерджа веток тимлидом.

Как закрываем задачу «Передать в тестирование – принять и обработать фидбек»? Помогают project-каналы в Slack.

Для обсуждения багов у нас есть подход — он ни разу не уникальный, но очень рабочий 🙂  Ускорить общение помогают эмоджи, где:

⚠️  — когда по задаче есть комментарий. Это помогает быстрее отыскать то, что еще не поправили. По тому, что конкретно нужно поправить, я отписываюсь в слаке.

➕  — когда задача проверена и с ней все окей. О том, что все работает исправно, я также отписываюсь тимлиду в треде — для него это сигнал о том, что ветку можно заливать. Кстати, когда тимлид ставит ветку, он тоже ставит +.

👌  — когда разработчик сообщает, что по задаче есть нюансы. Например, если решили пока ее не делать или делать, но по-другому. Чтобы показать, что я в курсе.

Эмоджи всего 3, а пользы масса. Самый большой плюс — команда четко понимает, что происходит с той или иной задачей. Не перелопачивая при этом бесконечные threads в переписке.

Преимущества Vercel при тестировании фронтенда

У каждой из сторон свои собственные.

Для клиента: «В продакшен попадает более стабильная и “чистая” версия продукта. Чище продукт — счастливее клиент».

Вы спросите: «А что с тестировщиками?» Я скажу так: C Vercel задачи приходят постепенно, по мере готовности. Мне так же, как и разработчикам, не приходится возвращаться к мелким таскам спустя продолжительный промежуток времени и вспоминать #шожтамбыло. И это чертовски круто!

А вот иллюстративный пример из нашей практики тестирования фронтенда:

На одном из проектов ребята выкатили билд, где я нашла 28 багов. Все мелкие — где-то подвинуть пиксель вправо/влево, где-то добавить жирность шрифта. Если бы выкатили такую версию заказчику, он бы точно расстроился (что справедливо). В случае же с Vercel мы оставили это за «завесой», и интерфейсные косяки не дошли даже до тестового сервера.

{{tg-banner}}

Что стало с Jira? А с Днем Багов?

Вывалилась ли Jira из нашего баг-трекинг процесса? Нет, конечно. Jira перестала быть главным инструментом локально, однако на этапе интеграционного и регрессионного тестирований она по-прежнему осталась.

А с Днем Багов что? Он никуда не делся — починкой дефектов, мы, как и прежде, занимаемся в конце каждого спринта. Однако изменения все же случились. Из главного —  разгребая все ургентно-мелкое на берегу, мы наконец-то начали жить счастливо и укладываться в 1-2 дня.

Зачем это все

Причины две.

Первая: наша команда обожает тестировать новые штуки.

Вторая: мы хотим улучшать процессы в разработке продуктов. Хотим, чтобы клиентам было в кайф возвращаться к нам снова. Так было, так есть и так будет всегда.

Облегчил ли Vercel жизнь конкретно мне? Да нет же, наоборот — с его появлением моя вовлеченность в командные процессы сильно выросла. 1-2 дня «тотального» тестирования фронтенда под конец спринта сменились на ежедневный «точечный» мониторинг прогресса всех участников команды. Апдейты по багам, общение — этого стало в разы больше. И все ради качественного результата на выходе.