Тест-драйв: формы карточек справочников и документов

– Нам нужно нарисовать семь красных линий. Строго перпендикулярных. И некоторые зелёным цветом. А некоторые – прозрачным.

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

(типичные требования заказчика к интерфейсу)

Всем привет.

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

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

Тестировать отображение формы карточки необходимо в два подхода:

• в первую очередь проверяется соответствие разработанной формы прототипу интерфейса, приведённому в проектной документации. Вы всё ещё не рисуете прототипы? Тогда я иду к вам  Возможно, мой материал MS Visio, как инструмент проектировщика: ненаглядная наглядность подтолкнёт вас к решению о включении раздела с прототипами в проектную документацию. Если же прототипы не ваш конёк, соответствие формы карточки придётся тестировать по описанию реквизитного состава;
• после проверки соответствия формы следует протестировать карточку на удобство использования – то самое «юзабилити».

Поговорим о каждом подходе поподробнее.

Тестирование соответствия формы карточки прототипу / описанию

В качестве входных данных для тестирования будем рассматривать:

• систему DIRECTUM с доступом к тестируемой карточке;
• проектную документацию, содержащую либо прототип, либо описание реквизитного состава карточки.

1. В первую очередь выясняем – предполагает ли наша карточка наличие нескольких закладок? Если да, то выполняем следующие проверки:

• проверяем количество закладок карточки;
• проверяем порядок следования закладок карточки;
• проверяем наименования закладок карточки.

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

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

2. Далее для каждой закладки или, в случае их отсутствия, для карточки в целом выполняем следующие проверки:

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

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

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

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

• проверяем количество действий карточки;
• проверяем расположение действий карточки (включая группы ленты);
• проверяем заголовки действий карточки;
• проверяем клавиши-акселераторы действий карточки (при их наличии).

На выходе получаем карточку, содержащую все нужные действия, расположенные и именованные корректно и грамотно.

Тестирование удобства использования карточки

В качестве входных данных для тестирования будем рассматривать:

• систему DIRECTUM с доступом к тестируемой карточке;
• проектную документацию, содержащую описание процесса, в рамках которого ведётся работа с карточкой.

1. Карточка должна помещаться в экран пользователя.

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

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

2. Карточка не должна быть излишне растянута в ширину или в высоту.

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

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

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

• заполнение карточки в рамках выполнения действий одним человеком по возможности должно осуществляться сверху вниз, слева направо;
• поля, обязательные для заполнения при создании новой карточки, по возможности должны быть расположены на одной закладке;
• фильтрующие поля по возможности должны быть расположены над фильтруемыми, ограничивающие / разрешающие – над ограничиваемыми / разрешаемыми;
• сообщения, выдаваемые пользователю, должны быть «дружественными». Например, если обязательные для заполнения поля находятся на разных закладках, в сообщении следует указать не только имя поля, но и наименование закладки, на которой оно расположено;
• и т.д.

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