Правила тестирования

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

1. Правила тестирования пользовательского интерфейса (взаимодействия программы с пользователем)

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

Тестеру необходимо помнить, что заказчик хочет видеть имплементированную в программном продукте функциональность через графический User interface (UI), а не через SELECT по базе, командную строку и т. п. Поэтому к тестированию UI надо подходить особенно серьезно и применять все нижеперечисленные правила без исключения.

UI – это «лицо» программного продукта.

Общие правила тестирования для всех окон UI:

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

Главное окно также должно содержать:

• Строку заголовка (с кнопками сворачивания, разворачивания и закрытия).

• Строку меню. Для удобства работы с меню уровень вложенности меню должен ограничиваться двумя уровнями.

• Инструментальную строку (кнопки вызова команд, помощи и т. п.).

• Строку сообщений или иной элемент, кратко информирующий о текущем состоянии программы, выполняемой операции и т. п.

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

Все элементы пользовательского интерфейса должны активизироваться как с помощью графического манипулятора (мышь, трекбол – у лэптопов и ноутбуков), так и с помощью только клавиатуры (функциональных клавиш и клавиш управления курсором). Если перемещение фокуса на заданный элемент управления с помощью клавиш невозможно, то это является ошибкой и подлежит занесению в баг-лист с приоритетом не ниже «medium». Проверка активизации всех элементов пользовательского интерфейса с помощью клавиш должна обязательно присутствовать в тестплане по данному программному продукту

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

В том случае, когда какое-либо окно программы после открытия не имеет выделенного по умолчанию элемента управления, то это является багой и подлежит занесению в баг-лист с приоритетом не ниже «medium». Если выделение объекта производиться нестандартным способом, то это должно быть обязательно отражено в документации.

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

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

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

3. Все окна продукта должны выглядеть одинаково, в едином «стиле».

4. В главном меню продукта обязательны пункты File, Help и Window.

5. Каждой кнопке инструментальной панели (toolbar) должна соответствовать команда в меню.

6. Важнейшие команды меню должны иметь последовательности кнопок ускоренного вызова.

7. Заголовки активных окон не должны содержать сокращений и аббревиатур. Это касается также и наименований экранных кнопок.

8. Кнопки Escape (выход) и Cancel (отмена) должны служить единой цели: откату операции и закрытию окна. Когда откат уже невозможен, кнопка Cancel должна переименовываться в Close (закрыть).

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

10. Пара кнопок ОК и Cancel должна располагаться в окне отдельно от других.

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

12. Все экранные кнопки управления, кроме ОК и Cancel, должны иметь соответствующие последовательности ускоренного вызова, которые не должны дублироваться.

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

14. Должен быть выдержан строгий логический порядок обхода полей по кнопке Tab.

15. Интерфейс графических систем (для Unix-систем) не должен имитировать символьный интерфейс терминалов.

16. Интерфейс графических систем (для Unix-систем) должен создаваться в стиле X-Windows или Motif, а не MS Windows.

17. Демон должен иметь команды install, uninstall, start, status и stop.