вторник, 8 октября 2013 г.

В требованиях должна быть проблема, цель, задача! Решение вторично

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



А, казалось бы, что еще надо то?
У Алана Купера в "Психбольнице" есть замечательный пример на тему того, почему это неправильно.

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

Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
  1. Двигатель внутреннего сгорания.
  2. Четыре колеса с резиновыми покрышками.
  3. Трансмиссия, связывающая двигатель с ведущими колесами.
  4. Трансмиссия и двигатель смонтированы на ходовой части.
  5. Рулевое колесо.
На этот момент времени каждый слушатель уже записал, что это автомобиль,


но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:

6. Быстро и легко срезает траву.
7. На этом удобно сидеть.

На основании 5 функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка.


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

Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?
Wink ;)

Но задумываемся ли мы об этом, когда привычно изучаем техническую документацию? Там же написано, как оно должно работать - значит, именно так и должно! А вот будет ли это самое "должно" нужно пользователям, уже дело десятое. Хотя должно бы быть первое. В конце концов, не для себя стараемся, а для потребителей.

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

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

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

Не додумывайте автомобиль, читая требования к газонокосилке!

2 комментария:

  1. "И когда мы тестируем документацию, особенно пользовательскую, надо обращать внимание именно на то, насколько она проста и понятна, а также очевидна для пользователя. Что он сразу может найти в ней свою проблему и оттуда уже перейти по ссылочке на решение. "

    Ну если не поможет, то во всяком случае улыбнет)))
    http://www.tdocs.su/1808

    в части выделения групп пользователей.

    ОтветитьУдалить