На моем курсе в «том-самом-ДЗ-которое-нельзя-обсуждать» юные умы должны задать вопросы работодателю, выстающему в роли Заказчика. И ответы на вопросы «А какие хитрые требования не были указаны ранее и я их пропустил?» почему-то вызывают негодование =)
Мне понравились примеры Святослава, поэтому хочу привести их в блоге, заодно зародить у вас интерес к его книжке :)
========================================================
2.2.6. Техники тестирования требований
Стр: 47/287
Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение — задавайте вопросы. Можно спросить представителей заказчика, можно обратиться к справочной информации. По многим вопросам можно обратиться к более опытным коллегам при условии, что у них имеется соответствующая информация, ранее полученная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования. Поскольку здесь начинающие тестировщики допускают уйму ошибок, рассмотрим подробнее. В таблице 2.2.a приведено несколько плохо сформулирован- ных требований, а также примеров плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные ответы, не содержащие полезной информации.
Таблица 2.2.a — Пример плохих и хороших вопросов к требованиям
Плохое требование
|
Плохие вопросы
|
Хорошие вопросы
|
«Приложение должно быстро запускаться»
|
«Насколько быстро?» (На это вы рискуете получить ответы в стиле «очень быстро», «макси- мально быстро», «нууу… просто быстро»). «А если не получится быстро?» (Этим вы рискуете просто уди- вить или даже разозлить заказчика.) «Всегда?» («Да, всегда». Хм, а вы ожидали другого ответа?)
|
«Каково максимально допусти- мое время запуска приложения, на каком оборудовании и при ка- кой загруженности этого обору- дования операционной системой и другими приложениями? На до- стижение каких целей влияет скорость запуска приложения? Допускается ли фоновая загрузка отдельных компонентов приложения? Что является критерием того, что приложение за- кончило запуск?»
|
«Опционально должен поддерживаться экспорт документов в формат PDF».
|
«Любых документов?» (Ответы «да, любых» или «нет, только от- крытых» вам всё равно не помогут.) «В PDF какой версии должен производиться экспорт?» (Сам по себе вопрос хорош, но он не даёт понять, что имелось в виду под «опционально».) «Зачем?» («Нужно!» Именно так хочется ответить, если вопрос не раскрыт полностью.)
|
«Насколько возможность экспорта в PDF важна? Как часто, кем и с какой целью она будет использоваться? Является ли PDF единственным допустимым фор- матом для этих целей или есть альтернативы? Допускается ли использование внешних утилит (например, виртуальных PDF- принтеров) для экспорта документов в PDF?»
|
«Если дата события не указана, она выбирается автоматически».
|
«А если указана?» (То она указана. Логично, не так ли?) «А если дату невозможно вы- брать автоматически?» (Сам во- прос интересен, но без пояснения причин невозможности зву- чит как издёвка.) «А если у события нет даты?» (Тут автор вопроса, скорее всего, хотел уточнить, обязательно ли это поле для заполнения. Но из самого требования видно, что обязательно: если оно не заполнено человеком, его должен заполнить компьютер.)
|
«Возможно, имелось в виду, что дата генерируется автоматически, а не выбирается? Если да, то по какому алгоритму она гене- рируется? Если нет, то из какого набора выбирается дата и как генерируется этот набор? P.S. Воз- можно, стоит использовать текущую дату?»
|
2.2.7. Пример анализа и тестирования требований
Стр 48/287
Уровень бизнес-требований. Бизнес-требования изначально могут выглядеть так: «Необходим инструмент для ав- томатического приведения кодировок текстовых документов к одной».
Здесь мы можем задать множество вопросов. Для удобства приведём как сами вопросы, так и предполагаемые ответы клиента.
В каких форматах представлены текстовые документы (обычный текст, HTML, MD, что-то иное)? (Понятия не имею, я в этом не разбираюсь)
В каких кодировках приходят исходные документы? (В разных)
В какую кодировку нужно преобразовать документы? (В самую удобную и универсальную)
На каких языках написан текст в документах? (Русский и английский)
Откуда и как поступают текстовые документы (по почте, с сайтов, по сети, как-то иначе)? (Это неважно. Поступают отовсюду, но мы их складываем в одну папку на диске, нам так удобно)
Каков максимальный объём документа? (Пара десятков страниц)
Как часто появляются новые документы (например, сколько максимум доку- ментов может поступить за час)? (200–300 в час)
С помощью чего сотрудники просматривают документы? (Notepad++)
============================================================
Что мне особенно нравится в примерах ответов Заказчика? Они честные! И готовят к реальному миру.
Если вы задаете Заказчику (человеку из бизнес-мира) вопрос, в котором он не разбирается, он ответит «понятия не имею» и это будет не издевка, а честный ответ.
И если вы спросите «Как должно работать приложение», вам ответят «Быстро и удобно», а не так, как вы ожидаете — подробным набором требований, которые хорошо тестируются.
Учитесь задавать вопросы.
Учитесь задавать правильные вопросы. Вопросы в мире клиента.
См также:
