Дизайн-ревью Яндекс Музыки. Тестировщик сравнивает дизайн макета с тестовой сборкой

Как вы считаете, написание данных проверок исчерпывающе или в этом есть смысл, с учетом дефицита времени у QA инженеров?

Ответ на вопрос заключается в следующем: на этапе проектирования задачи баг поправить можно, но уже после внесения всех правок с высоким приоритетом никто вам исправлять процент прозрачности на плашке не будет. Все ваши находки упадут в бэклог и останутся там навсегда. Поэтому все UI капризы нужно отлавливать на первом этапе заведения баг-репортов. Если у разработки нет времени т.к. чинят что-то блокирующее, то увы придется пожертвовать низким приоритетом.

И что же делать? Можно как вариант объединить баги шрифтов, размеров и прозрачности с одного экрана в одну задачу на исправление, и тогда приоритет у правки возрастет. Дополнительно хочу подсветить, что мы можем столкнуться с изменением одного экрана, который влияет на связанный функционал в остальных частях МП (если это старый UI баг).