Комментарии 17
А это, нейронку уже кто-то научил кликать и заполнять формочки, сравнивать результаты? Теоретически это проще чем код писать...
Возникает вопрос "чего хотим добиться?", если используем нейронку. Дополнительно, как оценивать качество, как сравнивать результаты и с чем? Мне кажется, что история с покрытием на юнит уровне будет более надёжной, при этом, при написании кода практически полностью контролируется, что происходит и что проверяется.
Подождите, немного не понятно - как компиляция помогает тестировать верстку? width:20px и width:200px корректные css правила, но верстка совершенно разная. синтаксические проверки css были и до angular 9. тот же vscode подсвечивает неправильные стили.
Вы в своем тесте на иконки проверили не то что иконки отобразились, а то что элемент имеет определенный стиль, что согласитесь разные вещи.
Спасибо за ответ!
Если было подлито 200px вместо 20px и это попало на прод, то, вероятно, есть моменты в процессе обеспечения качества, на которые нужно обратить внимание, т.к. такое изменение было пропущено на ревью, в тестировании и т.д.
То, что элемент имеет определённый стиль в зависимости от условий является в целом важной проверкой, которую не нужно проверять скриншотом. При этом шанс того, что иконка не отобразится - ничтожен.
Если было подлито 200px вместо 20px и это попало на прод, то, вероятно, есть моменты в процессе обеспечения качества, на которые нужно обратить внимание, т.к. такое изменение было пропущено на ревью, в тестировании и т.д.
Погодите, вопрос же был, про то, как компиляция помогает в обеспечении тестировании верстки?
То, что элемент имеет определённый стиль в зависимости от условий является в целом важной проверкой, которую не нужно проверять скриншотом. При этом шанс того, что иконка не отобразится - ничтожен.
это почему? разработчик/или другая команда подредактировала общий css или удалила/изменила файл c иконками - иконки отображаются не те, или не отображаются вовсе. наличие/отсутствие стиля эту ситуацию не отловит.
Речь не про компиляцию отдельно для проверки вёрстки, речь про весь имеющийся набор инструментов, которые помогут предотвратить появление таких проблем.
Если другая команда что-то сделала, из-за чего пропадают общие элементы - такие проблемы надо ловить не скриншотами, а посмотреть на причины возникновения таких ошибок. Возможно, нужно настроить хорошие процессы ревью кода, возможно, нужно вести канал уведомления о важных изменениях, когда одни поменяли, а обновились не все. И снова, в этой ситуации, можно обойтись вычиткой проверки элемента в DOM, не доводя дело до скриншотов.
Спасибо за статью!
Мы активно используем скриншотное тестирование для дизайн-ревью. Например, когда мы мигрируем на новую версию UI-кита или делаем редизайн какого-то экрана, благодаря скриншотам, дизайнеры видят в МР разницу было/стало и могут указать на проблемы. Это самый удобный способ сопоставить две версии реализации дизайна. Иначе придется играть в игру "найди пять отличий".
Также есть вещи, которые сложно проверить без скриншотов. Например, логику перестройки лейаута при планшетном и мобильном разрешении или поведение текстовых элементов при переносе строк, переполнении.
Но я согласен с посылом, что использовать этот вид тестирования надо с умом, избегая множества скриншотов одного и того же. Также важно делать скрины устойчивыми к изменениям: например, порой достаточно скриншотить область экрана или конкретный элемент. Также скриншот плохое решение, если вам просто лень написать 10 строк кода с селекторами элементов и проверками.
Спасибо за ответ!
Мне кажется, что если у вас часто меняется дизайн, то стоит подумать в сторону целесеобразности автоматизации. Если же нет, то, кажется, скриншоты будут избыточными, т.к. дизайн уже меняться не будет или будет меняться редко. Соответственно, вы всегда будете получать одинаковый результат.
Что же касается логики перестройки лэйаута в разных разрешениях и поведение текстовых элементов - здесь нужно провести анализ того, насколько часто в этих задачах вы встречаетесь с проблемами, почему они возникают и т.д. Вполне возможно, что, устранив причину появления таких проблем, вы пересмотрите свой подход.
Я понимаю, что если есть возможность проверять правильность DOM, то проверка именно её локализует ошибку лучше и будет куда стабильнее. Но полный отказ от скриншотов вызывает некоторые сомнения. Если б вы сказали "мы уменьшили использование скриншотов в 10 раз" – я бы понял, но после полного отказа я жду, что вёрстка поедет (если, конечно, вы не переводите этот этап на ручное тестирование)
Давно вы отказались от скриншотов?
Спасибо за ответ!
Конечно, на первых порах можно оставить набор критичных тестов со скриншотами, из-за опасений "вдруг вёрстка поедет". По наблюдениям, конкретно у нас верстка никуда не едет уже долгое время. В случае же возникновения проблем с вёрсткой можно попробовать выяснить причину, почему она поехала, как это можно предотвратить в дальнейшем. Просто так она не поедет
Ну так тесты-то нужны, чтобы обнаружить поехавшую (не всегда даже из-за ваших изменений – могли просто подвезти новую версию WebView) вёрстку вовремя. Как вы увидите, что она поехала, если не проверяете её?
Можно подойти комплексно: выяснить, почему подвезли новую версию WebView и никто об этом не был проинформирован; узнать, митигируется ли риск обновления любых других сторонних компонентов, из-за которых едет вёрстка; выяснить, почему разработка идёт таким образом, что при обновлении чего-то стороннего всё едет; выяснить, насколько часто это происходит и т.д.. Я к тому, что сама ситуация, когда можно полагаться на скриншотный тест как на последний рубеж обороны, не самая хорошая.
Опять то же самое.
Для всего, что вы пишете, надо иметь возможность обнаружить, что вёрстка поползла. Причём желательно узнать это не от юзеров. Так что этап обнаружения проблемы опускать нельзя. У вас есть только выбор – ручное обнаружение или автоматизированное.
выяснить, почему подвезли новую версию WebView и никто об этом не был проинформирован
Например, в iOS приехало обновление WKWebView. Допустим, все проинформированы. Что вы будете делать? Проведёте ручное тестирование всего интерфейса?
узнать, митигируется ли риск обновления любых других сторонних компонентов, из-за которых едет вёрстка
Проверять, когда появляется новая версия системных либ – это оно?
выяснить, почему разработка идёт таким образом, что при обновлении чего-то стороннего всё едет
Важно, но опять же – это разбор по следам проблемы, которую желательно обнаружить до того, как приложение уйдёт в продакшн.
Так что вопрос "давно вы отказались от скриншотов?" актуален. А для себя сделаю отметочку: не обновлять приложение Tinkoff, пока не пройдёт хотя бы пары недель с выпуска новой версии.
Процесс обеспечения качества предполагает, что при тестировании мы оцениваем, как будет тестироваться ПО, какие проверки на каком уровне или этапе будут проведены.
Необходимо понимать, что нам нужно тестировать свой продукт, а не логику, элементы дизайна или компоненты, например, другой команды.
Что-то вы тут не самым удачным образом смешали тестирование и обеспечение качества. Заговорив про последнее, вы резко скатились в тестирование. Проведение тестирования вам ни разу не обеспечит качество. Оно вам обеспечит нахождение багов, подтверждение соответствия требованиям, может быть немного удовольствия.
Однако, у вас должны быть критерии качества продукта, тогда да - тестирование вам даст результаты, которые можно будет рассматривать на предмет соответствия/не соответствия критериям качественности.
Если проблема только во времени, то можно шаги снятия и проверки скриншота выполнять в цикле, с некоторым интервалом. Если за заданное время ожидания правильного скрина не удалось получить совпадающий скрин, тогда провал. Если скрин совпал в любой итерации сравнения , даже при первом сравнении, то Успех и продолжение теста.
Задержка выполнения теста будет только в том случае, когда не хватило времени для верного отображения, но это все равно лучше чем ложный провал
Как отказаться от скриншотов в тестировании