Очевидность и понятность. Описывайте дефект так, чтобы у читающего
ваш отчёт не возникло ни малейшего сомнения в том, что это действительно де-
фект. Лучше всего это свойство достигается за счёт тщательного объяснения фак-
тического и ожидаемого результата, а также указания ссылки на требование в поле
«Подробное описание».
Сравните:
Плохое подробное описание Хорошее подробное описание Приложение не сообщает об обнаруженных
подкаталогах в каталоге SOURCE_DIR.
Приложение не уведомляет пользователя об
обнаруженных в каталоге SOURCE_DIR подка-
талогах, что приводит к необоснованным ожи-
даниям пользователями обработки файлов в
таких подкаталогах.
Act: приложение начинает (продолжает) ра-
боту, если в каталоге SOURCE_DIR находятся
подкаталоги.
Exp: в случае если в каталоге SOURCE_DIR
приложение при запуске или в процессе работы
обнаруживает пустой подкаталог, оно автома-
тически его удаляет (
логично ли это? ), если же
обнаружен непустой подкаталог, приложение
прекращает работу с выводом сообщения
«Non-empty subfolder [имя подкаталога] in
SOURCE_DIR folder detected. Remove it manu-
ally or restart application with --force_file_opera-
tions key to remove automatically.
»
Req: UR.56.BF.4.c.
В первом случае после прочтения подробного описания очень хочется спро-
сить: «И что? А оно разве должно уведомлять?» Второй же вариант подробного
описания даёт чёткое пояснение, что такое поведение является ошибочным со-
гласно текущему варианту требований. Более того, во втором варианте отмечен
вопрос (а в идеале нужно сделать соответствующую отметку и в самом требова-
нии), призывающий пересмотреть алгоритм корректного поведения приложения в
подобной ситуации: т.е. мы не только качественно описываем текущую проблему,
но и поднимаем вопрос о дальнейшем улучшении приложения.
