Некоторые думают, что юзабилити-тестирование — это что-то очень сложное, почти магия. Но юзабилити всегда начинается с простого: здравого смысла, логики, последовательности. И проверить мобильное приложение на наличие такого юзабилити может сам заказчик и, конечно, разработчик.

Что нужно для начала тестирования

1. Техническое задание. Чтобы понимать, каким приложение должно быть.

2. Сценарии использования приложения. Чтобы понимать, каким хочет видеть приложение пользователь.

3. Прототип или готовое приложение. Чтобы было, что проверять.

5 главных вопросов юзабилити

Ответы на эти вопросы покажут: насколько приложение удобно (да и вообще пригодно для использования). На этом этапе нет нужды обращаться к конечным пользователям, вполне сойдёт собственный опыт.

1. Понятна ли основная функция приложения с первого взгляда на главный экран

Что является основной функцией? Это то, за чем пришёл пользователь в мобильное приложение. Визуально и функционально это может быть кнопка, дашборд, график, карта, меню и другие элементы.

Самый эргономичный спецпроект Cossa и Surf — о том, как создавать и развивать удобные, полезные приложения. Кейсы, обзоры, советы экспертов: всё ценное в одном месте.

Разработка, маркетинг и продажи в мобайле →

Реклама

Здесь важно продумать сценарий использования приложения пользователем — и решить, что именно он ожидает увидеть, открыв приложение. Ради чего он нажал на иконку?

Всё просто, если подключить здравый смысл.

Но не всё так прямолинейно.

В мобильном приложении для интернет-магазина основной функцией будет совершение покупки. Но размещать на главном экране кнопку «Купить» преждевременно. Это лишь конечная цель пользователя — сначала он хотел бы выбрать товар.

Поэтому пользователь ожидает увидеть на главном экране что-то наподобие кнопки «Выбрать», которая ведёт в каталог.

Либо несколько кнопок, так называемых «конверсионных путей», которые ведут в подразделы каталогов (например: Мужчинам, Женщинам, Детям).

В этом случае цель приложения составная. Поэтому на главный экран помещаем кнопку с первым шагом к цели.

Хорошо продуманный путь пользователя покажет правильную последовательность экранов. Каждый последующий экран должен приближать пользователя к цели. Не нужно искусственно уменьшать или увеличивать количество шагов.

Соблюсти логику движения поможет правило «один экран — одна основная функция». Остальные функции на экране должны быть менее заметными.

Вот, например, главный экран приложения, которое мы разработали для Pizza Hut. Цель пользователя — заказать пиццу. Поэтому на главном экране есть несколько кнопок, ведущих в разные разделы меню.

А вот главный экран приложения для менеджеров Burger King. Тоже сделали мы.

Всего за минуту менеджер или руководитель может оценить показатели по ресторану и выполнение плана (числа на скриншоте к реальным показателям компании отношения не имеют).

2. Все ли кнопки имеют понятный пользователю дизайн и удобный размер

Приложение провалит любое юзабилити-тестирование, если кнопки будут:

• Непонятны. Чтобы сделать кнопку понятной, нужно пользоваться гайдлайнами (для Android и iOS отдельно). Представьте, что дорожные знаки стали бы рисовать дизайнеры, пытаясь сделать что-то уникальное. Многие водители почувствовали бы себя дураками, впервые выехавшими на дорогу. А это неприятное чувство, которое пользователь не захочет испытать второй раз.
• Неудобны. Какие кнопки можно считать удобными? Опять помогут гайдлайны. Например, для смартфонов на iOS площадь кликабельных элементов должна быть не меньше 7×7 мм.
• Незаметны. Это странно, но в некоторых приложениях кликабельные элементы не очевидны на фоне других. Фактически обнаружить такую кнопку можно лишь «методом тыка». Получается, что и нажать на кнопку можно случайно. Всё это затрудняет взаимодействие с интерфейсом.

Посмотрите на экран моего смартфона. Куда нужно нажать, чтобы добавить контакт? (Кстати, адресная книга в смартфоне — тоже приложение).

Я набрала выдуманный номер и решила сохранить его. Жму «Добавить контакты».

На следующем экране я увидела список моих контактов. Куда же жать?

Нажала на кнопку «Меню» в левом верхнем углу. Хотя на предыдущем экране я уже явно дала понять, чего хочу! Ну ладно.

Вот что увидела.

Дело в том, что я могу добавить номер телефона к уже существующему контакту. Но для меня как для пользователя это не очевидно, формулировки пунктов меню тоже не очевидны. Именно поэтому у меня в списке контактов случаются дубли. Я начинаю чувствовать себя дураком.

Нажимаю «Добавить контакт». И вижу это.

Ввожу имя человека и создаю новый контакт. Куда жать, чтобы сохранить?

Ответы оставляйте в х.

3. Может ли пользователь легко вернуться на предыдущий экран

Пользователи Android ищут кнопку возвращения на предыдущий экран в верхнем левом углу. Если разработчик решит разместить кнопку в нижнем левом или в правом углу, это будет непривычно.

Худшее решение — вообще лишить пользователя такой кнопки (например, заставляя раз за разом возвращаться в меню).

Для того, чтобы понять, как пользователю будет удобнее, не обязательно штудировать статьи о юзабилити и гайдлайны (на самом деле обязательно). Как минимум возьмите самые популярные приложения и посмотрите интерфейс для каждой платформы. Что у нас самое популярное? Мессенджеры и соцсети. Возьмите и сделайте так же (что касается навигации).

4. Может ли пользователь воспользоваться поиском и фильтром, если список слишком длинный

Если в приложении пользователь натолкнётся на длинный список товаров, картинок, файлов, сообщений, то нужно предоставить пользователю инструмент, который поможет найти то, что нужно.

С другой стороны, важно понимать, что фильтр уместен, когда у позиций поиска есть категории и различные свойства. А также если пользователи точно не знают, что ищут. В противном случае фильтр может лишь затруднить поиск.

Например, фильтр не нужен в списке городов, но нужен в каталоге обуви.

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

5. Сохраняются ли данные при выходе из приложения

Представьте, вы заполняете корзину, потом решаете поразмыслить и выходите из приложения. И вот вы решились оформить покупку, входите в приложение, а корзина пуста. Самые стойкие заполнят корзину вновь, другие плюнут и уйдут к конкурентам.

То же касается непредвиденных сбоев. После сбоя введённые данные должны сохранятся.

Если приложение будет отвечать хотя бы этим простым правилам юзабилити, пользователи уже будут благодарны.

Что делать с результатами тестирования

Если вы провели тест самостоятельно, отдайте результаты разработчикам. Разработчики помогут расставить ошибки по приоритету.

Например:

1. Эти ошибки должны быть исправлены незамедлительно.
2. Эти ошибки должны быть исправлены до определённого срока.
3. Эти ошибки требуют более детального тестирования. Нужно назначить тест.

В общем, тестирование ради тестирования — пустая трата времени. Поэтому после тестирования важно разработать чёткий план по устранению найденных недочётов. Также не лишним бывает обратиться к независимой команде разработчиков для взгляда со стороны.

Подытожим

Первые правила юзабилити:

1. Основная функция приложения понятна с первого взгляда.

2. Все кликабельные элементы понятны, удобны, видны.

3. Пользователь может быстро вернуться на предыдущий экран.

4. Пользователь быстро находит нужную информацию в списках.

5. При выходе из приложения данные сохраняются.

Список можно продолжать и углубляться в подробности. Если вам есть что добавить, пишите в х.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.

Чек-лист Softengi: разработка мобильного приложения, зачем, почему и кто может сделать?

По данным StatCounter Global Stats в октябре 2013 года 80,33% Интернет-пользователей в мире пользовались стационарным компьютером, и только 19,67% — мобильным Интернетом. В октябре 2014 года ситуация выглядит иначе — 67,17% пользуются компьютером, а 32,83% предпочли мобильный Интернет. Мы переходим в мобильный мир?

Мы уже там. Судя по статистике, мы в нем задержимся.

Тем не менее, это не означает, что нужно немедленно бежать заказывать собственное мобильное приложение. Чек-лист с вопросами ниже подскажет, может быть, целое приложение просто вам не нужно? А если все-таки нужно, то зачем и кто может это сделать?

 1. Зачем мне мобильное приложение? 

— С какой целью мне нужно мобильное приложение?- Кто будет целевой аудиторией приложения? — Кто мои конкуренты?Ответы на эти вопросы помогут понять, вам нужно мобильное приложение или мобильная версия сайта или веб-приложения. От ответа зависит все — бюджет, сроки, исполнитель работы.

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

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

Аналитический инструмент на сайте даст анализ браузеров и устройств пользователей и поможет решить вообще, нужна ли мобильная версия веб-приложения или сайта.Почему важно понимание целевой аудитории? Половина пользователей мобильного Интернета в Европе и США относится к возрастной группе 18-34.

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

Возможно, этот рынок уже занят вашими конкурентами, и инвестиции будут бесполезны, а вместо этого лучше вкладывать деньги в улучшение качества обслуживания клиентов и, таким образом, выделиться среди конкурентов.

 2. Что мое мобильное приложение будет делать? 

— Какие продукты/услуги будут предлагаться пользователю? — Какие функции оно должно выполнять? — Гибридное или нативное приложение? Вы ответили на первые вопросы, и по-прежнему уверены, что собственное мобильное приложение нужно делать. Самое время подумать о функциональности.

Информировать пользователя о продукции, услуге или акции и мотивировать его связаться с вами, или же пользователь должен выполнить определенное действие — заказать, купить, играть, искать и т.д. От этого ответа зависит, нужна ли серверная часть, которая сделает разработку дороже и дольше. Если никаких сложных действий не требуется, см.

пункт первый о простой мобильной версии приложения или сайта.Гибридное или нативное приложение это другой важный пункт, от которого зависит время разработки и бюджет.

Чек-лист для тестирования IOS-приложений. Часть 2

Готовы к продолжению? Мы тут составляем обязательный чек-лист для тестеров iOS-приложений, а также для их разработчиков и владельцев. Часть вторая. Если пропустили первую часть, милости просим сюда. Итак, приступим.

Напомним про mind map, которую мы использовали в прошлой статье для иллюстрации чек-листа

#4. Ресурсы устройства.

Обязательна обработка следующих ситуаций:

• Нехватка места при установке или работе мобильного IOS приложения: должно отображаться уведомление с необходимой информацией о сложившейся ситуации. «Крэш» приложения не должен происходить.

• Недостаток памяти для функционирования системы при активной либо фоновой работе приложения: все данные полученные при работе приложения должны сохраняться (если иное не предполагается функционалом самого приложения, например, синхронизация данных с сервером).

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

Вот, например, Вы находитесь в новом, неизвестном городе, скачиваете через Wi-Fi навигатор или гид по этому городу, но при попытке запуска приложение закрывается с пугающими сообщениями, вместо корректного уведомления о недостаточном объеме памяти для корректного запуска. Скорее всего, вы сразу удалите такое приложение от греха подальше. А если бы вы увидели понятное уведомление, то легко удалили бы пару ненужных старых приложений и спокойно перезапустили свой навигатор или гид по городу.

#5. Разрядка батареи.

• Проверить, что при разряженной батарее отображается уведомление:

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

• Проверить, что при полной разрядке приложение завершает работу без ошибок:

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

#6. Работа с прерываниями.

Телефон нужен в первую очередь для звонков, и имеется очень большая вероятность, что при работе с вашим приложением, пользователю кто-нибудь позвонит, или напишет сообщение. При тестировании iPhone приложений подобную ситуацию нужно проверять на различных формах данного приложения.

Помимо этого, форма для входящего звонка или сообщения должна быть доступна при открытом приложении, все элементы приложения и формы просто обязаны отображаться корректно и не перекрывать друг друга, а в случае с интерактивными приложениями, они прерываются на момент звонка, и возобновляются по его завершению.

#7. Сворачивание/разворачивание активного приложения.

При сворачивании и разворачивании должна быть обеспечена корректная приостановка iOS приложения при его сворачивании, и продолжение процесса при разворачивании. Особенно данная проверка актуальна для игр.

Ведь во время игрового процесса, иногда долгого и изнуренного, у пользователя рано или поздно появляется причина, чтобы свернуть игру и естественно вернуться снова для достижения заветной цели и потерять все что непосильным трудом было добыто очень огорчит пользователя.

В нынешних условиях конкуренции мобильных приложений, многие выпускают продукты в сжатые сроки, желая отвоевать свое место на рынке и ухватить свою долю прибыли, но совсем забывают про имеющиеся баги, что в дальнейшем влечет падение репутации, доверия пользователей и соответственно прибыли. Разные дефекты, несут разную важность, от верного цвета той или иной кнопки, до украденных личных данных или денег со счетов. Тестируйте, пока не добьетесь нужного качества своего приложения!

Чек-лист 29 распространенных ошибок в юзабилити мобильного приложения

04.04.2016

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

Для своих сотрудников мы создали чек-лист распространенных ошибок в юзабилити мобильного приложения. Этот список стал удобным инструментом для тест-драйва очередного продукта перед сдачей. Мои коллеги-разработчики проверяют по нему самих себя, а тестировщики — принимают работу программистов.

Итак, приступим.

Работа с экранами

1. Все навигационные элементы на дисплее обязаны иметь достаточный размер и быть расположенными на оптимальном расстоянии друг от друга (таком, чтобы пользователь однозначно попадал по нужным);

2. Приложение не должно падать при быстром многократном нажатии одной и нескольких кнопок одновременно;

3. Никаких пустых экранов. Важно, чтобы пользователь, на каждом этапе работы с приложением, понимал, что ему делать дальше, и что происходит прямо сейчас.

Ресурсы памяти

1. Утечка памяти может возникать во время продолжительной работы внутри приложения, и на окнах со значительным количеством изображений. Часто проявляется, если кэширование картинок работает некорректно;

2. Ошибки приложения могут появляться в ответ на недостаток памяти для функционирования ОС смартфона — тестируйте как во время работы в фоновом, так и в активном режиме;

3. Системные ошибки при переносе или установке приложения на SD-карту — очевидная, но распространенная проблема;

Технические особенности дисплеев и ОС мобильных устройств

1. На ретина-дисплеях текст и другие элементы интерфейса показываются мельче, чем на обычных. Соответственно, если изображения для ретина-экрана попадут в неретина версию — они могут отобразится просто огромными;

2. Должна быть предусмотрена адаптация приложения к ландшафтному и портретному режиму смартфона;

3. Проверка версии ОС при установке обязана исключить возможность установки приложения на не поддерживаемое мобильное устройство;

4. Важно, чтобы визуальные компоненты приложения соответствовали своему назначению по смыслу и концепциям платформы (решения,оптимальные для одной платформы, запросто могут стать неуместными в другой);

Реакция на внешние раздражители

1. Оповещения других приложений, звонки, SMS, MMS;

2. Зарядка устройства.

3. Разрядка, выключение или изъятие аккумулятора устройства;

4. Время и условия перехода устройства в режим ожидания, включая защиту паролем;

5. Отключение и включение сотовой сети, режима в самолете, Bluetooth, GPS.

6. Подключение и отключение USB-кабеля, SD-карты и других внешних устройств;

7. Утеря связи с прокси или сервером;

Локализация

1. Проверка правильности и корректности перевода;

2. Уточнение соответствия всех надписей формам и кнопкам, к которым они относятся;

3. Проверка специфических особенностей интернационализации, разделителей в числах, форматов дат. Например, мы привыкли к дате в формате ДД.ММ.РР,  в то время, как для американцев общепринятая ММ.ДД.РР.

Обратная связь

1. Кнопки и ссылки должны иметь выраженный отклик на действие — “нажатое состояние”, которое позволит пользователю убедиться, что нажатие случилось;

2. Скорость отклика элементов интерфейса должна быть достаточно большая, даже на самых слабых устройствах из всех, которые поддерживает ваше приложение;

3. Индикатор загрузки контента или соответствующее сообщение о требуемом времени должно показываться в каждый момент ожидания;

4. Оповещения с ошибкой доступа к сотовой сети, Bluetooth, GPS должны отображаться корректно;

5. Сообщения-предостережения должны быть очевидны для пользователя, если он пытается удалить важную информацию;

6. Уведомления об окончании игры или процесса должны отображаться всегда и корректно;

7. Важна синхронность уведомлений (звуков и вибраций приложения) с другими событиями, которые отображаются на экране.

Обновления

1. Должна поддерживаться та же версия операционной системы, что и у предыдущей версии приложения — если обновленная версия приложения использует новый функционал операционной системы, то нужно сделать урезанную версию приложения для предыдущих поддерживаемых версий ОС.

2. Все данные пользователя внутри приложения обязаны сохраняться после установки обновленной версии.

Приведем простой пример из практики компании Mauris — Lifestyle приложение TRENDMEON. В изначальной версии приложения, при первом запуске приложения скачивалась сразу вся база скидок, и потом отображалась локально.

Но вскоре обнаружилась проблема — если у пользователя был медленный интернет, база скидок подгружалась медленно. Пользователи воспринимали это как глюк. Они считали, что приложение зависло и выходили из него.

После первых нескольких негативных отзывов мы изменили алгоритм отображения скидок (теперь подгружается не вся база сразу), чем уменьшили время ожидания при первом заходе до 1 секунды.

Дополнительно мы уведомляем пользователя о возможных задержках при первом заходе в приложение.

Таким образом, загрузка обновленной базы происходит незаметно для самого пользователя. Ниже вы можете увидеть скриншоты “до” и “после”.

Тестируем мобильные приложения: наш чек-лист

• # Обеспечение качества
• Февраль 2017 г
• 14480 просмотров

О тестировании уже было написано достаточно: и о трудовых буднях мобильного тестировщика, и о сложности выбора устройств, на которых проводить тесты, и об операционных систем и их версиях. Сегодня решил поделиться с вами несколькими интересными фичами, на которые нужно обращать внимание при тестировании.

Тестирование верстки мобильных приложений

Кто не любит красивые приложения? Каким бы полезным и функциональным оно ни было, если при этом оно выглядит непрезентабельно, то вряд ли будет иметь успех.

Экраны смартфонов становятся все больше и шире, и использовать их одной рукой уже проблематично, а иногда просто невозможно.

Чтобы и размер экрана увеличить, и удобство использования обеспечить, производители девайсов придумали такую функцию, как управление одной рукой.

Так вот, при тестировании верстки важно не забывать про эту фичу и тестировать в режиме управления одной рукой, проверяя, что приложение все еще правильно функционирует, а элементы на экране отображаются корректно и соответствуют макетам.

В iOS устройствах в режиме управления одной рукой экран сдвигается вниз и скролится – в этой реализации меньше проблем и багов. В Android устройствах фича реализована интереснее: диагонали экрана уменьшаются, и верстка значительно изменяется.

Не забывайте тестировать ваши приложения с включенной фичей “Управление одной рукой”.

Теперь поговорим про разрешения экранов iOS устройств. Всего 10 устройств, 4 различных разрешения и три диагонали экрана.

Модель	Диагональ (в дюймах)	Разрешение экрана (в пикселях)
iPhone 4/4S	3	640×960
iPhone 5/5C/5S/SE	4	640×1136
iPhone 6/6S/7	4.7	1334×750
iPhone 6 Plus/6S Plus/7 Plus	5.5	1920×1080

Начиная с iPhone 6 и выше, у девайса появился увеличенный режим экрана, изменяющий разрешение экрана. А с новой фичей приходят и новые баги, т.к. макеты экранов рисуют обычно под 4 разрешения и не учитывают увеличенный режим.

Бывает и такое: заказчик хочет pixel-perfect верстку и предоставляет макет с точными координатами расположения элементов на экране.

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

После этого случая мы предпочитаем адаптивную верстку, которая растягивается под разные разрешения экранов. Это значительно снижает количество ошибок, хотя и не исключает их полностью.

Тестирование установки и обновления приложения

Да здравствуют обновления! Успешные продукты развиваются, появляется новый функционал, иногда исправляются старые ошибки. Важно помнить про тестирование установки и обновления.

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

Во время тестирования приложения нужно тестировать как установку, так и обновления, чтобы убедиться, что новые и текущие пользователи смогут пользоваться приложением.

Работа приложения с большими объемами данных

На моей практике был такой кейс: разрабатывали приложение для создания встреч и приглашения на них друзей. Заказчик жаловался, что приложение постоянно тормозит, но на наших устройствах все работало нормально. Как оказалось, приложение использовало телефонную книгу смартфона.

У заказчика было более 500 контактов, на наших тестовых устройствах — не более 100. При обращении приложения к контактам происходило подвисание приложения на пару секунд, что и вызывало негативную реакцию.

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

Если ваше приложение использует галерею или телефонную книгу телефона, нужно обязательно тестировать на больших объемах данных и проверять производительность приложения.

Чек лист: что проверить перед релизом

1. Тестирование при включенной функции «Управление одной рукой»
2. Тестирование iOS девайсов при включенной функции «Увеличенный режим экрана»
3. Тестирование установки приложения с нуля
4. Тестирование обновления приложения
5. Тестирования приложения с большим количеством записей в телефонной книге (если приложение использует записную книжку устройства)
6. Тестирования приложения с большим количеством фотографий в галерее (если приложение использует галерею устройства)

Проводя тестирования мобильных приложений, не забудьте включить эти пункты в чек лист. Это поможет повысить качество приложения и получить больше положительных отзывов от пользователей.

Гештальт и эвристика: как создать интерфейс приложения

Допустим, вы разрабатываете мобильное приложение. У вас много работы, клиенты проблемные, конца правкам не видно. А может, вы не разработчик, но у вас есть идея создать приложение, которое решит проблемы пользователей. Отличное начало, дело за малым: сделать понятный интерфейс.

Мы разобрали законы гештальт-дизайна и эвристические принципы, чтобы создавать интерфейсы, одинаково удобные для клиентов, для пользователей, для всех.

А Владимир Солосин, старший маркетинг-менеджер Яндекс.Такси, проанализировал интерфейс приложения популярного диджитал-издания Mashable. И оно оказалось далеко не идеальным.

ПРИНЦИПЫ ГЕШТАЛЬТА

Принципы гештальта — это теория о том, как люди воспринимают визуальные элементы интерфейса.

Наш мозг пытается понять мир через свой опыт, используя знакомые формы, образы и цвета.

Этот принцип сформулировал в 1910 году психолог Макс Вертгеймер, когда наблюдал оптическую иллюзию на железнодорожном переезде: одна за другой загорались две лампочки, отчего казалось, будто огонек света бегает из стороны в сторону. Но Макс был ученым и знал, что это просто две статичные лампочки — никакой магии, никакого движения.

От загорающихся лампочек «загорелся» и сам Вертгеймер и создал теорию гештальта. А через сто лет дизайнер Кэролайн Боннер описала 6 законов того, каким должен быть интерфейс приложения.

1. Сходство

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

2. Обрамление

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

Этот закон применяют, когда на одной странице нужно оформить несколько несогласованных между собой абзацев текста или чтобы разграничить группы элементов разного назначения. В нашем примере текст первоисточника взят в рамку, чтобы разграничить его с текстом репоста. В отдельный блок выделены мгновенные реакции, а в еще один — комментарий с фото, гифками и стикерами.

 3. Непрерывность

Элементы, расположенные на линии или кривой, воспринимаются как сгруппированные. Непрерывность помогает понять направление, в котором следует смотреть, нарушение непрерывности сигнализирует о конце раздела, обращает внимание на новый фрагмент контента.

4. Завершение

Если элемент виден не полностью, но он узнаваемый, пользователь считывает его как понятный. Этот закон реализован в иконках навигационного меню Телеграма.

5. Симметрия

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

6. Фигура — фон

Основную информацию на странице можно выделить, создав контраст между элементом, который эту информацию отображает, и фоном. Например, кнопка «Купить» обычно яркая и находится в центре экрана. А если возникают всплывающее окна, остальная часть экрана обычно оказывается в расфокусе.

ЭВРИСТИЧЕСКАЯ ОЦЕНКА

Тестирование приложений: описание и чек-лист

В этой статье изложен опыт компании Infoshell по тестированию приложений. Речь пойдёт о тестировании в спринте и в проектной работе, предрелизном тестировании и других вопросах.

Тестирование в спринте

В первый день спринта (выделенного на одну функцию или часть продукта периода) необходимо создать тест-кейсы и автотесты. Или отредактировать их, если текущий спринт не первый в цепочке.

Текст-кейс и автотест

Тест-кейс — это документация тестировщика. Это список действий, который нужно совершить, чтобы достичь поставленной цели. Он включает в себя, в среднем, 5 пунктов:

• уникальный ID, который необходим для оптимизации поиска и хранения кейса;
• название документа — предмет тестирования или основная тема теста. Раздел включает также краткое описание сути работ. Не пишите большие названия и всегда делайте их однотипными, так вам будет проще найти документ, если вы потеряете или забудете его ID;
• предусловия, или условия, которые не относятся к функционалу на проверке прямо, но обязательны для выполнения. Например, заполнение профиля доступно только зарегистрированному, авторизованному и подтверждённому пользователю. В таком случае в предусловиях тест-кейса «Заполнить профиль» должно быть: «пользователь зарегистрирован», «пользователь авторизован», «пользователь подтверждён»;
• список шагов — список действий, которые позволят достичь поставленной цели: протестировать разработку;
  результат — краткое описание наиболее вероятного, по мнению тестировщика, результата после совершения всех шагов тестирования. В заключении может быть три варианта: «положительный», «отрицательный» и «тест блокирован».

Положительный — фактический результат равен ожидаемому. Отрицательный — если не равен и была найдена какая-то ошибка. «Тест блокирован» — невозможность выполнения шагов. Это означает ошибку, которую необходимо найти и указать в результате.

По желанию в текст-кейс можно добавлять другие пункты. Например, историю редактирования, в которой нужно указывать, кем и когда этот кейс был изменён, что было убрано или добавлено.

При этом в тест-кейсе не должно быть нечётких формулировок, лишних деталей и описаний, умалчиваний или неточностей в описании шагов и результата. Ещё одно важное условие — каждый кейс должен быть независим от остальных. Держите это в голове, так как тест-кейсы и автотесты пишутся на каждую функцию, и начать связывать их автоматически очень легко.

Автотест — код, который пишет разработчик для проверки работоспособности приложения. Позволяет не только сэкономить время на поиск и исправления багов, но и увидеть конкретную строчку кода с ошибкой.

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

Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться.

Тестирование функциональности

В большинстве случаев это тестирование проводится вручную. Этапа три, они идут по порядку:

1. Дымовое тестирование. Цель — проверить базовую функциональность приложения. Продумайте поведение пользователя, затем начните тестировать приложение. Сделайте позитивный тест и выполните целевое действие. Пусть это будет подписка на email-рассылку.

2. После него начните тест негативный: попытайтесь «обмануть» программу, кликайте на разные кнопки, иконки, изображения и отслеживайте, как она реагирует на ваши действия. Продукт не должен открывать никаких лишних окон, картинок. Он также не должен давать никакой информации при нажатии «в пустоту».

3. Если всё прошло хорошо, переходите к следующему этапу. Если хотя бы в одном из этих тестов вы нашли ошибку, приложение нужно отправить на доработку с описанием обнаруженных багов в баг-репорте. Назначьте задачу на исправление и ждите устранения ошибки, после чего повторите дымовое тестирование.

Регрессионное тестирование

Необходимо для того, чтобы проверить, исправили ли разработчики найденные баги. Ещё одна цель регрессионного тестирования — отслеживание того, как внесённые изменения повлияли на работу других частей приложения и его поведение в целом.

Сэм Канер, профессор программной инженерии Технологического института, директор Образовательного и исследовательского центра тестирования программного обеспечения Флориды, выделяет три основных типа этого теста:

• регрессия багов. Цель тестировщика — увидеть и доказать, что найденная на более ранних этапах ошибка не была исправлена в полной мере или в принципе;
• регрессия старых багов. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что старые баги начали снова воспроизводиться;
• регрессия побочного эффекта. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что нетронутые части приложения сломались из-за этого (или приложение в целом вышло из строя).

Полное тестирование по тест-кейсам. На третьем этапе тестировщик проверяет все функции, которые описаны в его тест-кейсах. Когда результат по каждому из них будет положительным, тестирование можно считать оконченным.

Тестирование в проектной работе

В проектной работе применяют преимущественно регрессионное тестирование. Это обусловлено тем, что тест в данном случае проводят на заключительных этапах. Предположим, запланировано четыре спринта. Тогда тестировщик включается после третьего.

Особое внимание при тестах в проектной работе стоит уделить тестированию взаимодействия. Это функциональный тест, который проверяет способность продукта взаимодействовать с компонентами или системами: от одного и больше. Оно включает в себя тестирование совместимости и интеграционное тестирование.

Тестирование совместимости — нефункциональный тест, цель которого — проверить, корректно ли работает приложение в определённом окружении. Это может быть аппаратная платформа, различные ОС, браузеры и расширения.

Интеграционное тестирование — фаза теста ПО, где отдельные модули программы объединяют и тестируют в группе. Интеграционное тестирование можно автоматизировать с помощью систем непрерывной интеграции (например, Jenkins, TeamCity, Travis CI, Gitlab CI, Circle CI, GoCD или другие).

Предрелизное тестирование

Это особенный, наиболее важный спринт и тестирование. Перед релизом продукт необходимо «прогнать» ещё раз, чтобы убедиться в отсутствии багов (по крайней мере, больших) наверняка.

Сначала нужно провести регрессионное тестирование.

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

Также важно учитывать, чтобы возможные исправления не могли повлиять на другие части продукта и его поведение в принципе. Ведь исправлять всё перед релизом попросту некогда.

Если процесс был спланирован правильно, регрессионное тестирование ограничится проверкой случайных изменений в коде с прошлого спринта. Если нет — случиться может всё, что угодно. Но вероятность того, что вы спокойно завершите работу над приложением в срок, крайне мала.

После регрессионного начинайте тестирование внедрённых багфиксов (исправленных ошибок). Сейчас тестировщик должен проверить, есть ли какие-то негативные последствия от исправления багов, найденных с помощью регрессионного теста, или нет. А также были ли эти ошибки вообще исправлены разработчиками.

Затем идёт тестирование интеграции патча (код, который добавили разработчики для устранения ошибок). Фактически, это тест результата двух предыдущих этапов.

Тестировщик пытается понять, не вредит ли патч приложению, и насколько хорошо он «встал» в систему.

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

Юнит-тест — автотест для небольшой части кода, которая отвечает за конкретную функцию приложения. Юнит-тесты подают значения.

Тест считается пройденным, если программа обрабатывает их верно — так, как было задумано тестировщиком. Если реакция приложения не совпадает с запланированной, тест считается не пройденным.

Но разработчики понимают, в какой части кода находится ошибка, и исправляют её.

Это не вся польза юнит-тестов. Они могут очень помочь в борьбе с багами после обновлений. Ведь возвращение к старому коду требует много времени на разбор и сравнение его с новым, а юнит-тест покажет область проблемы сразу.

Последний этап — это финальное тестирование продукта. Оно включает в себя проверку всех функций приложения с учётом спецификации или бэклога, которую команда согласовала с заказчиком.

Начните изучать разработку с бесплатного курса «Основы современной вёрстки». Вы научитесь создавать статические веб-страницы, стилизовать элементы, использовать редакторы кода с полезными расширениями. В конце курса вы опубликуете свой первый сайт на GitHub Pages.

Тестирование на поддержке

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

Во время тестирования на поддержке нужно проверять сборку: основной функционал после обновлений. Когда тестировщик обнаружит баг, он должен описать его. Дальнейшая работа над проблемой будет происходить по принципу тестирования во время спринта.

Вывод и чек-лист

Важно придерживаться единообразия стандартов, так как это залог стабильной работы отдела тестировщиков. Мы используем описанные выше методики и принципы, чтобы оптимизировать все процессы, экономить время и силы сотрудников, упрощать разработку и не позволять багам проникать в пост-релиз.

Для удобства можно использовать в работе чек-лист.

• Этап 1: тестирование в спринте.
  • тест-кейс и автотест — создаётся документация тестировщика и автотесты;
  • тестирование функциональности — ручной тест (позитивный и негативный);
  • регрессионное тестирование — отслеживаются исправления;
• Этап 2: тестирование в проектной работе — регрессионное тестирование (проверка совместимости, интеграционный тест).
• Этап 3: предрелизное тестирование — регрессионные тесты, проверка багфиксов, интеграции патчей, юнит-тесты.
• Этап 4: тестирование на поддержке — выполняется при обновлении функциональности.

Статью подготовил Дмитрий Котенко, генеральный директор Infoshell. Мнение администрации «Хекслета» может не совпадать с мнением автора.