Тестирование программного обеспечения. Базовый курс. 3-е издание
Стр: 64/301 Отметка того факта, что с требованием всё в порядке
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU
- Бұл бет үшін навигация:
- Описание одной и той же проблемы в нескольких местах.
- Написание вопросов и комментариев без указания места требования, к которым они относятся.
- Задавание плохо сформулированных вопросов.
|
Стр: 64/301 Отметка того факта, что с требованием всё в порядке. Если у вас не воз- никло вопросов и/или замечаний к требованию — не надо об этом писать. Любые пометки в документе подсознательно воспринимаются как признак проблемы, и та- кое «одобрение требований» только раздражает и затрудняет работу с документом — сложнее становится заметить пометки, относящиеся к проблемам. Описание одной и той же проблемы в нескольких местах. Помните, что ваши пометки, комментарии, замечания и вопросы тоже должны обладать свой- ствами хороших требований (настолько, насколько эти свойства к ним применимы). Если вы много раз в разных местах пишете одно и то же об одном и том же, вы нарушаете как минимум свойство модифицируемости. Постарайтесь в таком слу- чае вынести ваш текст в конец документа, укажите в нём же (в начале) перечень пунктов требований, к которым он относится, а в самих требованиях в коммента- риях просто ссылайтесь на этот текст. Написание вопросов и комментариев без указания места требования, к которым они относятся. Если ваше инструментальное средство позволяет ука- зать часть требования, к которому вы пишете вопрос или комментарий, сделайте это (например, Word позволяет выделить для комментирования любую часть тек- ста — хоть один символ). Если это невозможно, цитируйте соответствующую часть текста. В противном случае вы порождаете неоднозначность или вовсе делаете вашу пометку бессмысленной, т.к. становится невозможно понять, о чём вообще идёт речь. Задавание плохо сформулированных вопросов. Эта ошибка была по- дробно рассмотрена выше (см. раздел «Техники тестирования требований» {51} и таблицу 2.2.a {52} ). Однако добавим, что есть ещё три вида плохих вопросов: • Первый вид возникает из-за того, что автор вопроса не знает общепринятой терминологии или типичного поведения стандартных элементов интерфейса (например, «что такое чек-бокс?», «как в списке можно выбрать несколько пунктов?», «как подсказка может всплывать?»). • Второй вид плохих вопросов похож на первый из-за формулировок: вместо того, чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса пишет «что такое {что-то}?» То есть вместо вполне логичного уточнения по- лучается ситуация, очень похожая на рассмотренную в предыдущем пункте. • Третий вид сложно привязать к причине возникновения, но его суть в том, что к некорректному и/или невыполнимому требованию задаётся вопрос наподо- бие «что будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно не сделаем. И вопрос должен быть совершенно иным (каким именно — зави- сит от конкретной ситуации, но точно не таким). И ещё раз напомним о точности формулировок: иногда одно-два слова могут на корню уничтожить отличную идею, превратив хороший вопрос в плохой. Срав- ните: «Что такое формат даты по умолчанию?» и «Каков формат даты по умолча- нию?». Первый вариант просто показывает некомпетентность автора вопроса, то- гда как второй — позволяет получить полезную информацию. К этой же проблеме относится непонимание контекста. Часто можно увидеть вопросы в стиле «о каком приложении идёт речь?», «что такое система?» и им по- добные. Чаще всего автор таких вопросов просто вырвал требование из контекста, по которому было совершенно ясно, о чём идёт речь. Типичные ошибки при анализе и тестировании требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023 жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|