Comments 6
Еще не хватало чтобы тестировщик лез в нашу работу. Продуктовый дизайнер отвечает не столько за визуал, сколько за логику для пользователя (UX). Тестировщик знает правильные паттерны .Может и UX исследования мы отдадим тестировщику?
Тестировщики не могут вёрстку посмотреть в консоле, о чем речь?
С чего тестировщик взял что то что сделал дизайнер ошибочно? Покажите мне результаты исследований, тогда можно будет поговорить.
У каждого из нас есть своя зона ответственности. Может стоит придерживаться их?
Никто не отбирает работу у дизайнера, но из всего вышесказанного складывается ощущение, что дизайнер не может ошибаться, как сделано, так сделано. Тогда получается надо вообще отменить тестирование и выпускать как есть.
UX исследования никто не отдаёт тестировщику, но знакомится и участвовать в них он может.
Тестировщик считает, что дизайн ошибочный, когда им пользоваться неудобно.
Для примера, можно привести визард с несколькими страницами, в них всё выглядит отлично, и дизайнер утверждает его. Но вот возврата не предыдущую страницу нет, и он не видит в этом необходимости. В результате пользоваться невозможно, так как в случае ошибки на одной из страниц, приходится закрывать визард и вводить всё сначала.
Да, можно сказать, что наверное был некомпетентный дизайнер и что у хорошего такого быть не может, но в жизни бывают разные ситуации и не всем организациям так везёт.
Иногда UX дизайнер косячит жутко и тестировщик вполне может исправить неправильное поведение.
Например, я, работая тестировщиком, читал книги по UX, когда они еще не были мейнстримом. И до сих пор я могу поправить дизайнера, так как они, иногда, творят дичь с точки зрения управления приложением.
Если даже взять популярные мобильные приложения, там будут косяки, которые с точки зрения тестирования не могли пройти тесты. Видимо, продакты так видят.
У QA чуть ли не самая широкая область необходимых знаний. Помимо собственных тестовых методологий и всякой теории, тестировщику нужно уметь писать автотесты, постоянно поддерживать документацию в актуальном состоянии, знать как работает фронт, бэк, как они общаются, SQL, docker, CI/CD, UX, ну и куда более мелкие моменты в зависимости от специфики продукта - очередь сообщений, NoSQL, мобилки и пр. Только вот потолок зарплат куда ниже, чем у разработчиков, да и в команде обычно тестировщиков в разы меньше.
С дизайнером за свои 3,5 года опыта не работал напрямую ни разу и не считаю нужным. Над реализацией они и так спорят с заказчиками и с разрабами, проводят свои A/B тесты.
Я бы просто посоветовал в первую очередь уважать труд другого специалиста. ТЗ редко бывают полными, макеты постоянно перерисовываются, заказчик потыкал прототип - ему захотелось что-то поменять, разработчик отдал в тест продукт будто бы не смотря на него, после тестирования нашли баги. И это нормально
Вы кажется вообще тогда не понимаете в чём роль QA в проекте. Вот это наибольшее заблуждение и подмена понятий:
в первую очередь уважать труд другого специалиста
Если так говорить, то работу программиста тоже "надо уважать" и баги не заводить?
В следующем же предложении вы как раз приводите в пример одну из причин, по которым QA обязан смотреть дизайн - тз редко бывают полными, поэтому дизайнер может упустить важную бизнес-логику, сам дизайнер в целом может не достаточно погрузиться в требования или не знать весь продукт целиком. Или просто он может забыть описать какое-то состояние и поэтому разраб сделает как хочет и в итоге дизайнеру всё равно это дорисовывать, но ещё и теперь разрабу переделывать то что он сделал, а тестеру перетестить всё.
Задача QA найти баг на самой ранней стадии, чем на более позднем этапе найдена проблема, тем дороже её чинить.
Никто не обесценивает этим работу дизайнера, этим лишь подсвечиваются возможные проблемы, которые могут привести к багам.
Всё что вы описываете это как раз бэд практис - когда никакой связи в команде нет, это не про QA а тупо тестинг.
В работе с программистами то же самое: нужно убеждать не только программиста, но и его менеджера (иногда через своего менеджера), тоже приходится сначала заслужить авторитет.
Я очень люблю фидбек именно от команды, тк всплывают то старые инициативы которые с первого раза не были услышаны, конечно же будет еще откопана история изменений (порой нелинейная, и нужно обосновать почему все-таки такое решение правильное, а потом успокоить тех кого волнует что данное решение уже было раньше но потом было изменено).
Гайдлайны и компоненты кто-то должен оунерить. Те языком цифр: кто-то должен выделить свое время на создание и поддержание в актуальном виде компонентов. И далеко не всегда менеджер согласен на эту доп работу для сотрудника, а программист иногда не считает что это важная инициатива и он хочет заниматься этим в свое свободное время.
Доступность (по крайней мере достаточный контраст цветов) тестируются еще на уровне выбора цветов для макета. Вы упоминаете читаемость иконок, тут есть нюанс. Например, если речь об иконках сервиса размером 16х16 внутри дерева. Тут можно только постараться сделать иконку максимально четкой и распознаваемой (она скорее всего будет еще далека от классной читаемости при 128х128). Доступность в размере кликабельных полей - это может проверить дизайнер, но ответственность за эту часть на фронтенде/разработчике. На тему требованиям к размерам кликабельных областей есть гайды/стандарты.
Давление авторитетом это слабый путь. Тк важны критерии конкретной задачи, а не предыдущий опыт.
QA инженер и дизайн