Назад

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

Время чтения: 5 минут

Тестирование фронтенда
Содержание

    Привет! Я — Марина Болдырева, QA-специалист в Purrweb. Не так давно мы с ребятами опробовали новый способ отслеживания багов — охотно делюсь впечатлениями.

    Что такое Vercel

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

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

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

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

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

    Тестирование фронтенда

    Я  открывала стейдж и начинала работать.

    Тестирование фронтендаС помощью колонки QA-waiting в Jira я могла сориентироваться по местам, которые нужно «прочекать»

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

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

    Тестирование фронтенда с JiraРаздел 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 дня «тотального» тестирования фронтенда под конец спринта сменились на ежедневный «точечный» мониторинг прогресса всех участников команды. Апдейты по багам, общение — этого стало в разы больше. И все ради качественного результата на выходе.

    Насколько публикация полезна?

    Оцени эту статью!

    10 оценок, среднее 5 из 5.

    Оценок пока нет. Поставьте оценку первым.

    Так как вы нашли эту публикацию полезной...

    Подписывайтесь на нас в соцсетях!

    Поделиться