Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Юзабилити-тестирование API
11.10.2017 10:25

Автор: Юлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/api-usability-testing/

Юзабилити-тестирование… API?! Да, именно так. В своей предыдущей статье я говорила, что юзабилити является одной из ключевых характеристик хорошего API. Пришло время рассмотреть ряд важных вопросов: зачем, как и, главное, с помощью каких методов можно оценить эту характеристику для API.

Когда говорят о графических пользовательских интерфейсах (GUI), уже ни у кого не вызывает сомнения то, что юзабилити тестировать необходимо. Но давайте вспомним, что согласно международному стандарту ISO 9241-11 юзабилити – это степень, с которой продукт может быть использован определенными пользователями при определённом контексте использования для достижения определённых целей с должной эффективностью, продуктивностью и удовлетворенностью. Проще говоря, это та степень удобства использования продукта, с которой пользователь может без затруднений применить продукт и достичь своей цели. Как видим, в определении нет ни слова о менюшках, цвете кнопочек и размере шрифта. Мы можем оценить юзабилити для любого продукта, будь то мобильное приложение, утюг, или, в нашем случае, API.

В тестировании юзабилити API используются методы, относящиеся к техникам, разработанным в рамках направления под названием HCI (Human-Computer Interaction, человеко-компьютерное взаимодействие); они же применяются и для оценки GUI. В данной статье я расскажу об основных и самых распространенных техниках. В целом, их можно разделить на два типа: аналитические и эмпирические (экспериментальные).

Аналитические методы

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

1. Эвристическая оценка (Heuristic evaluation)

Простейшим методом проверки юзабилити является эвристическая оценка. Суть метода заключается в том, что существует некий набор критериев («эвристика»), которым продукт должен отвечать. Для оценки API можно определить абсолютно разный набор критериев: он будет зависеть от того, что из себя представляет ваш API (библиотека или REST сервис).

Например, в статье «Methods towards API Usability: A Structural Analysis of Usability Problem Categories» исследователи использовали для оценки юзабилити библиотеки большой набор эвристик:

  • сложность – API не должен быть слишком сложным, гибкость и сложность должны быть сбалансированы;
  • именование – используемые имена должны быть самодокументируемыми и логичными;
  • читаемость – код должен быть читаемым (makeTV(Color) понятнее, чем makeTV(true));
  • документация – она должна существовать и при этом содержать примеры;
  • последовательность и общепринятые соглашения – дизайн должен быть последовательным и не разниться от метода к методу (порядок параметров, семантика);
  • параметры методов и возвращаемые значения – параметров не должно быть слишком много, а возвращаемое значение должно четко обозначать результат выполнения метода;
  • типы данных – используйте корректные типы, не заставляйте пользователя «приводить» типы (casting), избегайте использование строк;
  • параллельный доступ – API должен корректно обрабатывать его;
  • обработка ошибок и исключения – сообщения об ошибках должны содержать максимум необходимой информации, а исключения должны обрабатываться как можно ближе к тому месту, где они произошли;
  • минимальный объем рабочего кода – чем меньше кода нужно писать пользователю, тем лучше;
  • способ сделать правильно должен быть единственно-верным – API не должен позволять достичь цели несколькими способами.

Давайте подробнее рассмотрим некоторые из этих критериев на реальных примерах.
Критерий именования. В своей практике я постоянно встречаюсь с грустной ситуацией, возникающей при «погружении» нового тестировщика в тестирование системы: каждый раз джун приходит и говорит, что при использовании кода ФИАС произошла ошибка «Дома с таким-то кодом нет в системе». Я рекомендую использовать внутренний код дома в системе, на что джун делает большие глаза: «Нет такого параметра в запросе!» Приходится объяснять, что нужно использовать параметр FIASHouseGUID. Почему-то на заре проектирования сервисов параметр, содержащий GUID дома, обозвали FIASHouseGUID (код дома по ФИАС). При этом фактически можно использовать не только код ФИАС, но и внутренний код дома в системе. К сожалению, сервисы давно опубликованы и широко используются – следовательно, исправлять этот недочет уже слишком поздно.

Другой пример касается обработки ошибок. В одном из сервисов, который я тестирую, при изменении объекта распространена ошибка «Доступ запрещен для поставщика данных». Причин у этой ошибки может быть множество: нет правоустанавливающего документа, необходимого для операций над объектом; этот документ не находится в статусе «Размещен»; другая организация с привилегированными правами уже создала этот объект (а значит, организация пользователя не может его изменять). Причины разные, но текст ошибки одинаковый, и поэтому пользователь не имеет возможности понять, какая из причин «виновна» в этот раз.

Есть и более «суровые» эвристики оценки API. Чаще всего они специализированы на ко