От ошибок не застрахованы даже профессионалы. Приведем истории с тестированием макетов сайтов, расскажем о распространенных багах и покажем, как этого избежать. 

Мы работали над крупным проектом, где заказчик хотел реализовать множество дополнительных сервисов и опций. Макеты увеличивались с каждым днем. После этого мы решили взять аналитика и QA-менеджера. Первый тестировал дизайн-макеты, второй – верстку. Листы с багами совпали наполовину. Это значит, что этих багов можно было избежать на стадии дизайна. Расхождения дизайн-макета и прототипа происходят практически во всех случаях. Тестирование представляет собой не только проверку, но и субъективное мнение аналитиков касаемо юзабилити. Именно поэтому нужно учитывать не только дизайн, но и пользовательский опыт.

Мы разрабатывали новый проект, после чего у клиента появилась новая услуга, которую нужно было внедрить на сайт. Нам предъявили макеты, сделанные сторонним дизайнером. Мы провели проверку, собрали 200 строк в баг-листе, при этом около 20 строк были недочетами в бизнес-логике. Все макеты отличались сложным юзабилити. Мы переделали макеты, оставив прежнюю логику, однако сервис оставался по-прежнему сложным для использования. После этого у клиента поменялся менеджер, который вел этот проект. Мы обсудили с ним детали и пришли к выводу, что требуется менять не только макет, но и логику. В результате мы сократили макет с 28 всего лишь до 7 страниц. Из этого можно сделать вывод, что логика и дизайн тесно связаны друг с другом. Следует обязательно тестировать проект на юзабилити и при этом все этапы работы лучше всего выполнять одной командой, без сторонних специалистов.

Клиент отправил нам макеты на несколько гигабайтов – это были огромные и сложные объемы. Было понятно, что без тестирования верстку макетов делать невозможно. В результате мы столкнулись с несколькими трудностями:

• Сломанный телефон. При недостатках в дизайне нужно было дорисовать элементы. В итоге мы передавали информацию по цепочке специалистов, что было крайне неудобно.

• Получение файлов от клиента. Дизайнера не было в студии, поэтому иногда мы не могли найти требуемые файлы.

• Разница в компетенции. Заказчик не обязан знать технические особенности, иметь навыки программирования. Однако в результате коммуникация усложнялась, как будто мы разговаривали на разных языках.

• Проблемы в бизнес-логике. При обнаружении таких багов нам приходилось изменять макеты и техническое задание для дизайна.

• Дизайн не соответствовал мобильной версии.

• Проблемы с утверждением дизайна. По мере тестирования проекта клиенту переставали нравиться какие-то детали, и он просил их изменить.

Из этого можно сделать вывод, что при работе над макетом стороннего дизайнера следует обязательно проводить тестирование. Лучше всего – не браться за такое задание вообще, как как длительные объяснения и уточнения отнимают много времени. Гораздо быстрее работа протекает внутри одной компании с хорошо налаженной коммуникацией.

Таким образом, почти половины багов при верстке можно избежать, если проводить полноценное тестирование макетов перед их передачей программисту. Наши специалисты занимаются как тестированием собственных, так и проверкой сторонних макетов, работают в одной команде, разбираются во всех тонкостях дизайна и программирования. Именно поэтому при разработке вашего сайта нам удается избежать недочетов и ошибок, а при их обнаружении – своевременно устранить.