Можно подойти комплексно: выяснить, почему подвезли новую версию WebView и никто об этом не был проинформирован; узнать, митигируется ли риск обновления любых других сторонних компонентов, из-за которых едет вёрстка; выяснить, почему разработка идёт таким образом, что при обновлении чего-то стороннего всё едет; выяснить, насколько часто это происходит и т.д.. Я к тому, что сама ситуация, когда можно полагаться на скриншотный тест как на последний рубеж обороны, не самая хорошая.
Если я правильно понял вашу мысль, то отвечу, что цель статьи не расписать отдельно процесс обеспечения качества. В целом, тестирование входит в этот процесс, поэтому здесь и упомянуто.
Речь не про компиляцию отдельно для проверки вёрстки, речь про весь имеющийся набор инструментов, которые помогут предотвратить появление таких проблем.
Если другая команда что-то сделала, из-за чего пропадают общие элементы - такие проблемы надо ловить не скриншотами, а посмотреть на причины возникновения таких ошибок. Возможно, нужно настроить хорошие процессы ревью кода, возможно, нужно вести канал уведомления о важных изменениях, когда одни поменяли, а обновились не все. И снова, в этой ситуации, можно обойтись вычиткой проверки элемента в DOM, не доводя дело до скриншотов.
Конечно, на первых порах можно оставить набор критичных тестов со скриншотами, из-за опасений "вдруг вёрстка поедет". По наблюдениям, конкретно у нас верстка никуда не едет уже долгое время. В случае же возникновения проблем с вёрсткой можно попробовать выяснить причину, почему она поехала, как это можно предотвратить в дальнейшем. Просто так она не поедет
Если было подлито 200px вместо 20px и это попало на прод, то, вероятно, есть моменты в процессе обеспечения качества, на которые нужно обратить внимание, т.к. такое изменение было пропущено на ревью, в тестировании и т.д.
То, что элемент имеет определённый стиль в зависимости от условий является в целом важной проверкой, которую не нужно проверять скриншотом. При этом шанс того, что иконка не отобразится - ничтожен.
Мне кажется, что если у вас часто меняется дизайн, то стоит подумать в сторону целесеобразности автоматизации. Если же нет, то, кажется, скриншоты будут избыточными, т.к. дизайн уже меняться не будет или будет меняться редко. Соответственно, вы всегда будете получать одинаковый результат.
Что же касается логики перестройки лэйаута в разных разрешениях и поведение текстовых элементов - здесь нужно провести анализ того, насколько часто в этих задачах вы встречаетесь с проблемами, почему они возникают и т.д. Вполне возможно, что, устранив причину появления таких проблем, вы пересмотрите свой подход.
Возникает вопрос "чего хотим добиться?", если используем нейронку. Дополнительно, как оценивать качество, как сравнивать результаты и с чем? Мне кажется, что история с покрытием на юнит уровне будет более надёжной, при этом, при написании кода практически полностью контролируется, что происходит и что проверяется.
Можно подойти комплексно: выяснить, почему подвезли новую версию WebView и никто об этом не был проинформирован; узнать, митигируется ли риск обновления любых других сторонних компонентов, из-за которых едет вёрстка; выяснить, почему разработка идёт таким образом, что при обновлении чего-то стороннего всё едет; выяснить, насколько часто это происходит и т.д.. Я к тому, что сама ситуация, когда можно полагаться на скриншотный тест как на последний рубеж обороны, не самая хорошая.
Спасибо за ответ!
Если я правильно понял вашу мысль, то отвечу, что цель статьи не расписать отдельно процесс обеспечения качества. В целом, тестирование входит в этот процесс, поэтому здесь и упомянуто.
Речь не про компиляцию отдельно для проверки вёрстки, речь про весь имеющийся набор инструментов, которые помогут предотвратить появление таких проблем.
Если другая команда что-то сделала, из-за чего пропадают общие элементы - такие проблемы надо ловить не скриншотами, а посмотреть на причины возникновения таких ошибок. Возможно, нужно настроить хорошие процессы ревью кода, возможно, нужно вести канал уведомления о важных изменениях, когда одни поменяли, а обновились не все. И снова, в этой ситуации, можно обойтись вычиткой проверки элемента в DOM, не доводя дело до скриншотов.
Спасибо за ответ!
Конечно, на первых порах можно оставить набор критичных тестов со скриншотами, из-за опасений "вдруг вёрстка поедет". По наблюдениям, конкретно у нас верстка никуда не едет уже долгое время. В случае же возникновения проблем с вёрсткой можно попробовать выяснить причину, почему она поехала, как это можно предотвратить в дальнейшем. Просто так она не поедет
Спасибо за ответ!
Если было подлито 200px вместо 20px и это попало на прод, то, вероятно, есть моменты в процессе обеспечения качества, на которые нужно обратить внимание, т.к. такое изменение было пропущено на ревью, в тестировании и т.д.
То, что элемент имеет определённый стиль в зависимости от условий является в целом важной проверкой, которую не нужно проверять скриншотом. При этом шанс того, что иконка не отобразится - ничтожен.
Спасибо за ответ!
Мне кажется, что если у вас часто меняется дизайн, то стоит подумать в сторону целесеобразности автоматизации. Если же нет, то, кажется, скриншоты будут избыточными, т.к. дизайн уже меняться не будет или будет меняться редко. Соответственно, вы всегда будете получать одинаковый результат.
Что же касается логики перестройки лэйаута в разных разрешениях и поведение текстовых элементов - здесь нужно провести анализ того, насколько часто в этих задачах вы встречаетесь с проблемами, почему они возникают и т.д. Вполне возможно, что, устранив причину появления таких проблем, вы пересмотрите свой подход.
Возникает вопрос "чего хотим добиться?", если используем нейронку. Дополнительно, как оценивать качество, как сравнивать результаты и с чем? Мне кажется, что история с покрытием на юнит уровне будет более надёжной, при этом, при написании кода практически полностью контролируется, что происходит и что проверяется.