QA инженер и дизайн
Современные технологии меняют жизнь человечества, предлагая огромное количество различных возможностей. Появляется всё больше и больше разнообразных платформ и устройств, с помощью которых можно легко выполнять различные действия. Разработчики предлагают широкий ассортимент различных приложений. В связи с этим остро встаёт вопрос с качеством продукта. Ведь даже приложение обладающее огромной функциональностью, но содержащее множество ошибок и имеющее неудобный интерфейс, не будет пользоваться популярностью.
Обеспечение качества программного обеспечения направлено на улучшение рабочих процессов и повышение эффективности, позволяя компаниям завоевать доверие клиентов и повысить свой авторитет. Как результат большую роль начинает играть QA инженер. Это человек, который несёт ответственность за качество конечного продукта, улучшая и тестируя его на протяжении всего процесса разработки. Будучи частью команды, QA-инженеры участвуют в процессе разработки продукта с самого начала. Они не только тестируют, выявляют риски, но и отвечает за то, чтобы пользователю было «хорошо». QA должен сопереживать потребителю, а именно чтобы приложение было отзывчивым, интуитивно понятным и удобным в использовании.
Да, за внешний вид отвечает дизайнер и это его зона ответственности. Но данное утверждение верно отчасти. Во-первых, все мы люди и можем ошибаться, поэтому в современных командах приняты политики открытости. При этом любая потенциальная проблема может быть замечена и устранена. Во-вторых, дизайн должен подтверждаться исследованиями, а самое главное — являться результатом тесного сотрудничества с командой разработки и тестирования. Это означает принимать во внимание все возможные точки зрения.
Сейчас уже никого не удивляет тесное взаимодействие тестировщиков и разработчиков, хотя ещё совсем недавно такое трудно было представить. За это время, написано много статей, родилось немалое количество шуток о взаимодействии этой пары. Ни один современный проект не обходится без их жарких споров (а возможно и без них), в результате которых находится решение устраивающее всех, а в конечном счёте пользователя.
В работе с дизайнером всё обстоит по-другому. Если у QA возникает вопрос к интерфейсу, то проверенный с программистом, алгоритм даёт сбой. Хорошо если дизайнер адекватно воспринимает критику и у вас с ним сложились хорошие отношения. В результате вы сможете с ним прийти к какому-то решению, но часто всё происходит иначе. Укрепилось мнение, что дизайнер всегда прав, он лучше знает и только другой творец, может увидеть недочёты.
Почему же сложилась такая ситуация? На мой взгляд, в этом нет ничего удивительного, если вспомнить отношения тестировщиков и программистов много лет назад. Я тогда работал в одном НИИ и на разработчиков там смотрели как на богов, которые могут невероятные вещи. Любая критика или сомнения в коде воспринималась в штыки. Проблему ещё осложняло и то, что мы относились к разным отделам, в результате приходилось убеждать не только разработчиков, но и людей координирующих взаимодействия отделов. В итоге любой поиск и устранение ошибки занимало большее время, чем хотелось бы. Даже если источник ошибки был очевиден, сначала приходилось проверять всё остальное или лишь в конце переходить к коду. Вера в непогрешимость разработчиков была крепка. Переломить ситуацию можно было лишь одним способом — заслужить авторитет. И только после этого к твоему мнению стали прислушиваться не только программисты, но и руководители и заказчики. Времена менялись и роль QA росла, так как потребители уже насытились функционалом и хотели не только его, но и качества. Уже не надо было проходить столь трудный путь, доказывая свою правоту. Но это, в свою очередь, требовало дополнительных навыков. Если ты хочешь быть хорошим QA инженером, необходимо быть отчасти программистом.
Сегодня в случае с дизайнером приходится проходить похожий тернистый путь. Данную проблему можно наблюдать в различных компаниях независимо от размера или типа, будь то крупная компания, стартап или даже аутсорсинг. Причин возникновения недопонимания множество, зачастую они касаются обеих сторон:
дизайнер считает, что всё выполнено идеально и все замечания неверны.
дизайнер не является полноценной частью команды (относится к другому отделу), что затрудняет коммуникацию. Это проблема характерна для небольших компаний.
превалирование UI над UX в работе дизайнера. Это может быть связано с его предыдущим рабочим опытом.
проблема в том, что у QA инженера или дизайнера малая насмотренность. Например, он привык только к программам на Windows и пытается адаптировать практики для этой среды на дизайн сайта, где должны использоваться иные подходы и графические приёмы.
отсутствие guidlin’ов или библиотеки стандартных компонентов в компании.
отсутствие у одной из сторон (скорее относится к QA) видения продукта в целом. Например, тестировщик занимается только какой-то частью продукта и хотел бы что-то изменить, действительно, более удобным образом для этой части, но эти изменения приведут к тому, что либо неудобно станет в других частях, либо у пользователя будет разный опыт.
считается, что дизайн — это понятие, касающееся чисто визуального восприятия. Это не совсем так, основное назначение — помощь пользователям выполнить их задачи. Если интерфейс доступен не для всех, значит, вы выбрали дизайн, способный оттолкнуть людей от использования вашего продукта. Часто забывается доступность и его тестирование
проблема не в дизайне, а в видении самого заказчика.
Последняя проблема несколько выходит за рамки данной статьи, да и решение найти довольно трудно. Единственное, что здесь можно предпринять — это попытаться объединиться с дизайнером, найти удовлетворяющее обоих решение и убедить в нём заказчика. А как же решить остальные проблемы? Но перед этим стоит отметить, что для их решения зачастую, потребуется усилия всех заинтересованных сторон, а не только QA. Итак:
вовлечение в спор ещё одного дизайнера (старшего дизайнера или из другой команды) для установления истины (но может так случиться, что появиться третье мнение и придётся решать уже новую проблему). Но такое решение зачастую трудно использовать в небольших компаниях из-за наличия в компании всего одного дизайнера. Другой вариант, QA должен стать достаточно компетентным в глазах дизайнера или заказчика.
QA необходимо набирать экспертизу. Сейчас множество способов и источников. Можно пройти оффлайн или онлайн курсы, или найти в сети литературу на данную тему. Да, сразу вы не станете профессиональным дизайнером, но навыки вы получите и по-другому взглянете на проблему. Сейчас выходит много бесплатных игр и приложений и пользователи в Google Play и App Store с большой охотой оставляют отзыв как об ошибках, так и об удобстве пользования. В результате можно попробовать себя в качестве дизайнера-фрилансера или поучаствовать в качестве тестировщика интерфейса. По личному опыту могу сказать, что это очень хороший вариант, помогающий понять основные ошибки и получить фидбек от реальных пользователей. Даже если это отзыв ваших знакомых о создаваемом вами приложении, ещё на этапе разработки. Не упускайте ни одну возможность.
у больших компаний проблем с внутренними гайдлайнами и библиотеками обычно нет. Наиболее приоритетным решением может быть скорейшее создание таковых, при необходимости с привлечением внешних специалистов. Либо использование ссылок на внешние гайдлайны, принятые для внедрения в работу над продуктом.
быть открытым к диалогу. Это касается обеих сторон. Даже если на первый взгляд кажется, что оппонент не прав, надо взглянуть с другой стороны, возможно он не так уж и не прав. Иногда, может быть не весь вариант, а лишь его часть имеет право на существование. И умейте признавать свою неправоту.
избежать проблем с видением всего проекта, помогут интро по всему продукту при онбординге. Это не только касается приёма на работу, но и внедрении нового функционала, необходимо привлекать всех заинтересованных.
часто помогает создание отдельного чата с QA, DEV и дизайнером. В нём всё решается не один на один, а сообща. Это позволяет избежать давления авторитетом.
если пока не хватает авторитета, подкрепляйте свои слова UI/UX референсами на другие проекты, где это сделано лучше.
описывайте проблему конкретнее, не: «иконка выглядит плохо», а «иконка недостаточно контрастна, поэтому теряется на экране, это можно подтвердить с помощью встроенного в DevTools аудита через Lighthouse».
убедить в необходимости accessibility тестирование и в случае несоответствия результатов Web Content Accessibility Guidelines пересмотреть дизайн, показать, что наш продукт неудобен в использовании людям с различными видами ограничений. Сейчас можно найти инструменты помогающие разработчикам, тестировщикам и дизайнерам в этом, например axe DevTools — Web Accessibility Testing.
QA должны быть вовлечены в каждый шаг процесса создания конечного продукта, ведь именно так можно добиться значимых изменений.
важно давать фидбек дизайнеру как можно раньше. Когда дизайн уже полностью нарисован или выполнен разработчиком, то вы встретите гораздо большее сопротивление, пытаясь его изменить. Тут поможет практика, когда дизайн презентуется Dev и QA вместе до начала этапа разработки.
удобство продукта означает, что люди могут пользоваться им без обучения или помощи. Это можно выяснить, протестировав это на других членах команды. Выдайте им ключевые задания и понаблюдайте за тем, смогут ли они легко выполнить то, для чего продукт предназначен и видят ли они какие-то недостатки в дизайне.
сосредоточьтесь на понимании. Исследуйте своих пользователей, узнайте больше о людях, о том, какие задачи они хотят решить. Возможно, хорошим решением будет принять участие в опросе реальных пользователей и посмотреть отчёт об этой встрече.
В конце хочется сказать, цель этой статьи не показать, что тестировщик всегда прав, а дизайнер нет. Её посыл — что надо слушать и слышать друг друга и стараться выстроить более правильный процесс взаимодействия всех сторон, результатом которого будет качественный и удобный продукт.
