Ответ — в статье
Ответ — в статье

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

В один момент тестировщик позвал на помощь дизайнера. Тот попросил тестовый телефон, протестировал всю функциональность за 10 минут и нашел пять недочетов!

Наметанный глаз дизайнера способен заметить тончайшие детали, которые легко упустить при ручном тестировании. Поэтому тестирование UI с участием дизайн-команды показалось нам необходимым шагом. 

Меня зовут Наташа Филиппова, я руководитель группы разработки в Lamoda Tech. После запуска дизайн-ревью жизнь команды разделилась на «до» и «после», поэтому в этой статье я опишу наш опыт подробнее.

Проверка перед релизом

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

Особенно это актуально для мобильных приложений. Например, на Android есть приложение Window VQA, с помощью которого можно протестировать размеры кнопок, отступы. На iOS таких приложений нет.

Дизайнеры видели результаты работы лишь на собственном устройстве, когда функциональность уже выходила в продакшн. Из-за этого сильно страдало качество.

Если они замечали ошибки, фикс занимал много времени из-за долгого цикла развертывания на Android и iOS. Раньше мы выпускали релизы каждые две недели. Исправление бага в проде затягивало этот процесс минимум на неделю.

В такой системе дизайнерам иногда казалось, что они работали в стол. Можно было потратить недели на работу, а потом не попасть в выборку A/B-тестирования и не увидеть результатов своего труда. А если фича показывала не очень хорошие результаты, ее даже не раскатывали на пользователей. 

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

Внедрение дизайн-ревью

Сначала мы решили, что сразу после разработки будем передавать дизайнерам на проверку те фичи, которые хоть как-то затрагивают визуальную часть продукта. Было два варианта:

  1. смотреть фичи на устройствах QA или своих личных,

  2. получать их в виде скриншотов, задач и комментариев.

В это время условия усложнились: началась пандемия COVID-19, которая требовала изменения подхода к процессу. Просто показать сборку на тестовом устройстве мы не могли из-за удаленки. Команда QA стала прикладывать к отчетам скриншоты и видео, писать комментарии с запросами на проверку и тэгать дизайнеров. Это позволило эффективнее контролировать качество, даже несмотря на невозможность передавать устройства дизайнерам для быстрой оценки.

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

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

Теперь QA брали задачи, проводили тестирование и затем передавали макеты дизайнерам для дополнительной проверки. Так в итерации появилось два этапа взаимодействия.

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

Эти изменения сократили общее время тестирования UI в среднем на 20%.

Однако такая перестройка процессов была сопряжена с двумя трудностями:

1. Как уже упоминали выше, мы выдали дизайнерам по одному устройству. Но когда переход к новому флоу показал результаты, добавили еще один гаджет на другой операционной системе.

2. Недостаток прозрачности и связи между QA, дизайнерами и продактами создавал сложности в передаче задач, отслеживании их статусов и реагировании. Так мы поняли, что необходимо улучшать коммуникации в процессе. 

В рабочем мессенджере мы создали отдельный чат для координации и отслеживания процесса дизайн-ревью. Дизайнеры сами предложили использовать эмодзи для обозначения статусов задач. Например, ? — «задачу увидел, смотрю». Такие внутренние «ритуалы» сделали процесс наглядным и понятным для всех участников.

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

Выводы и перспективы

Мы поняли, что тестировать дизайн руками QA сложно с точки зрения тестирования, но просто с точки зрения процесса. Однако тестировать руками дизайнеров — наоборот, просто с точки зрения тестирования, но сложно с точки зрения процесса.

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

Примерно через полгода после внедрения в мобильные приложения систему раскатали и на web. Теперь вся клиентская разработка в Lamoda Tech проходит тестирование в новом воркфлоу. Этот подход дает значительно большую эффективность при экономии времени команды в среднем до 20% и вообще считается стандартом на рынке.

Теперь наши дизайнеры сами проверяют реализацию своих макетов, QA не пытаются считать пиксели и сравнивать шрифты «на глазок», а в разработке значительно снизилось количество багрепортов.

Расскажите, использует ли ваша компания дизайн-ревью? Ждем ваши истории и вопросы в комментариях.

Комментарии (4)


  1. yanpurvenes
    04.06.2024 18:39

    Макет под экран был один или несколько, учитывая особенности некоторых телефонов?

    А если не секрет, куда они столько часов тратили на один макет? Есть же основные моменты, которые в макете можно посмотреть. Мелкие вещи даже если будут пропущены, то это явно минор и можно исправить постепенно.


    1. zhannazhanna
      04.06.2024 18:39

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


  1. Blurr_30
    04.06.2024 18:39

    Сколько времени дизайнеры тратят на тестирование? Насколько из-за этого нового этапа увеличилось время выката фичи в продакшн? Насколько дизайнерам самим понравилась увеличение рабочей нагрузки?


    1. zhannazhanna
      04.06.2024 18:39

      Отвечают наши коллеги-дизайнеры:

      «Во многом дизайнеры и стали инициаторами процесса, так как видели много багов в проде) Запуск ревью стал решением проблемы. Для нас это просто часть работы, как арт-надзор. 

      Если задача падает в ревью, дизайнер берет ее с наивысшим приоритетом, чтобы не тормозить выкатку фичи на прод. Время на ревью зависит от того, сколько багов пропустил тестировщик. Иногда может занимать часть дня, иногда минут 5»