Описание событий или процессов в качестве шагов или ожидаемых ре-
зультатов.
Например, в качестве шага сказано: «Ввод спецсимволов в поле X».
Это было бы сносным заглавием тест-кейса, но не годится в качестве шага, который
должен быть сформулирован как «Ввести спецсимволы (перечень) в поле X».
Куда страшнее, если подобное встречается в ожидаемых результатах.
Например, там написано: «Отображение скорости чтения в панели X». И что? Оно
должно начаться, продолжиться, завершиться, не начинаться, неким образом из-
мениться (например, измениться должна размерность данных), как-то на что-то по-
влиять? Тест-кейс становится полностью бессмысленным, т.к. такой ожидаемый
результат невозможно сравнить с фактическим поведением приложения.
«Выдумывание» особенностей поведения приложения.
Да, часто в тре-
бованиях отсутствуют самоочевидные (без кавычек, они на самом деле самооче-
видные) вещи, но нередко встречаются и некачественные (например, неполные)
требования, которые нужно улучшать, а не «телепатически компенсировать».
Например, в требованиях сказано, что «приложение должно отображать диа-
логовое окно сохранения с указанным по умолчанию каталогом». Если из контекста
(соседних требований, иных документов) ничего не удаётся узнать об этом таин-
ственном «каталоге по умолчанию», нужно задать вопрос. Нельзя просто записать
в ожидаемых результатах «отображается диалоговое окно сохранения с указанным
по умолчанию каталогом» (как мы проверим, что выбран именно указанный по
умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожидаемых ре-
зультатах писать «отображается диалоговое окно сохранения с выбранным ката-
логом “C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно,
т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно).
Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Достарыңызбен бөлісу: |
