Все записи

Тестирование верстки

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

В статье Даша, руководитель группы тестирования UI, делится тем, на что обращает внимание при проверке верстки и какие моменты важно проверять в первую очередь.

Даша верстка.jpg


С чего начинается тестирование верстки?

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

  • максимально короткие значения — точка, пробел;
  • максимально длинный текст, который можно ввести;
  • соответствие ограничениям из постановки — например, максимально доступно 64 символа.
Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.


Почему важно проверять текст с пробелами и без?

Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.

Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.

Для таких проверок удобно использовать максимально широкие буквы:
  • для кириллицы — «Щ»;
  • для латиницы — «W».
Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.


Что нужно проверять в макете?

Например, в макете Figma мы смотрим:

верстка таблица.png

И, конечно, отступы между всеми элементами по вертикали и горизонтали.


Как проверять реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

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


Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

  • :hover
  • :active
  • :focus
Позволяет увидеть нужный цвет, проверить границы и сравнить с макетом, даже если мышь сейчас не наведена на элемент.


На что еще нужно обращать внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.


Когда удобно считать руками, а когда — линейкой?

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

Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».

Похожие новости

Автоматическая генерация UI-настроек

Илья — iOS-разработчик в Naumen, занимается развитием мобильного клиента платформы Naumen Service Management Platform и Chat SDK.

При работе над задачей со сжатием изображений перед отправкой на сервер команда столкнулась с неожиданной сложностью: оказалось неудобно проверять изменения без постоянной пересборки приложения.

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

ИИ-помощник для анализа требований

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

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

В статье рассказываем, как они собирали данные, какие подходы пробовали и как в итоге пришли к решению на базе RAG.

Как перестать тратить полдня на один вопрос в чате

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

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

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

Все новости