Типичные ошибки при анализе и тестировании требований (Куликов)

Еще немного пиара бесплатной книги для начинающих тестировщиков от Святослава Куликова 

Хочу немного поцитировать его. Читать оригинал, начиная со стр 57. Итак, типичные ошибки анализа требований (курсивом отсебятина от меня, краткий пересказ оригинала):

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

Самое худшее, что можно сделать с документом, — это сохранить его в итоге
в некоем формате, предназначенном скорее для чтения, чем для редактирования
(PDF, набор картинок и тому подобное).


Отметка того факта, что с требованием всё в порядке. Если у вас не возникло вопросов и/или замечаний к требованию — не надо об этом писать. Любые пометки в документе подсознательно воспринимаются как признак проблемы, и такое «одобрение требований» только раздражает и затрудняет работу с документом — сложнее становится заметить пометки, относящиеся к проблемам.

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

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

Задавание плохо сформулированных вопросов. Эта ошибка была по-
дробно рассмотрена выше (см. раздел «Техники тестирования требований»{45} и
таблицу 2.2.a{46}). Однако добавим, что есть ещё три вида плохих вопросов:

1. Первый вид возникает из-за того, что автор вопроса не знает общепринятой терминологии или типичного поведения стандартных элементов интерфейса (например, «что такое чек-бокс?», «как в списке можно выбрать несколько пунктов?», «как подсказка может всплывать?»).
2. Второй вид плохих вопросов похож на первый из-за формулировок: вместо того, чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса пишет «что такое {что-то}?» То есть вместо вполне логичного уточнения получается ситуация, очень похожая на рассмотренную в предыдущем пункте.
3. Третий вид сложно привязать к причине возникновения, но его суть в том, что к некорректному и/или невыполнимому требованию задаётся вопрос наподобие «что будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно не сделаем. И вопрос должен быть совершенно иным (каким именно — зависит от конкретной ситуации, но точно не таким).

И ещё раз напомним о точности формулировок: иногда одно-два слова могут
на корню уничтожить отличную идею, превратив хороший вопрос в плохой. Сравните: «Что такое формат даты по умолчанию?» и «Каков формат даты по умолчанию?». Первый вариант просто показывает некомпетентность автора вопроса, тогда как второй — позволяет получить полезную информацию.

К этой же проблеме относится непонимание контекста. Часто можно увидеть
вопросы в стиле «о каком приложении идёт речь?», «что такое система?» и им по-
добные. Чаще всего автор таких вопросов просто  вырвал требование из контекста,
по которому было совершенно ясно, о чём идёт речь.

Написание очень длинных комментариев и/или вопросов. Описание см в книге :)

Критика текста или даже его автора. Описание см в книге :)

Категоричные заявления без обоснования. Как продолжение ошибки «критика текста или даже его автора» можно отметить и просто категоричные заявления наподобие «это невозможно», «мы не будем этого делать», «это не нужно»...

Указание проблемы с требованиями без пояснения её сути. Описание см в книге :)

Плохое оформление вопросов и комментариев. Старайтесь сделать
ваши вопросы и комментарии максимально простыми для восприятия. Помните не
только о краткости формулировок, но и об оформлении текста (см., например, как
на рисунке 2.2.7 вопросы структурированы в виде списка — такая структура воспри-
нимается намного лучше, чем сплошной текст). Перечитайте свой текст, исправьте
опечатки, грамматические и пунктуационные ошибки и т.д.

Описание проблемы не в том месте, к которому она относится. Классическим примером может быть неточность в сноске, приложении или рисунке, которая почему-то описана не там, где она находится, а в тексте, ссылающемся на соответствующий элемент. Исключением может считаться противоречивость, при которой описать проблему нужно в обоих местах.

Ошибочное восприятие требования как «требования к пользователю».
Ранее (см. «Корректность» в «Свойства качественных требований») мы говорили,
что требования в стиле «пользователь должен быть в состоянии отправить сообщение» являются некорректными. И это так. Но бывают ситуации, когда проблема намного менее опасна и состоит только в формулировке. Например, фразы в стиле «пользователь может нажать на любую из кнопок», «пользователю должно быть видно главное меню» на самом деле означают «все отображаемые кнопки должны быть доступны для нажатия» и «главное меню должно отображаться». Да, эту недоработку тоже стоит исправить, но не следует отмечать её как критическую проблему.

Скрытое редактирование требований. Эту ошибку можно смело отнести к разряду крайне опасных. Её суть состоит в том, что тестировщик произвольно вносит правки в требования, никак не отмечая этот факт. Соответственно, автор документа, скорее всего, не заметит такой правки, а потом будет очень удивлён, когда в продукте что-то будет реализовано совсем не так, как когда-то было описано в требованиях. Потому простая рекомендация: если вы что-то правите, обязательно отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё лучше отмечать правку как предложение по изменению, а не как свершившийся
факт, т.к. автор исходного документа может иметь совершенно иной взгляд на си-
туацию.

Анализ, не соответствующий уровню требований. При тестировании требований следует постоянно помнить, к какому уровню они относятся, т.к. в противном случае появляются следующие типичные ошибки:

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

**********************************************

Мне очень понравилась данная глава, все четко и по делу. Причем говорится о вещах, о которых ты мог бы и не подумать. Например, я в ворде раньше могла что-то заменить, не в режиме правки. А тут читаешь и так умно киваешь головой, «логично, да да».

Когда то у нас ворд и вместо баг-трекера был. Один проход по тестовому стенду = 1 документ ворда. Разработчица потом писала другим цветом «Пофикшено». Я снизу подписывала снова другим цветом «Испарвлено», так у нас был цикл, чтобы видеть комменты и не перетирать друг друга 

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

А вот задать вопрос так, что вас просто не поймут — уже проблема! И еще важный пункт — понятность комментариев. Сама графоман, но я хотя бы на абзацы стены текста делю  А, когда видишь нечитаельную простыню, ее даже читать не хочется, честное слово. Будет Заказчик такое читать? Максимум по диагонали. Тогда он что-то, да пропустит и будет всему проекту плохо потом =)

См также:

Примеры неправильных вопросов от Куликова — еще одна выдежка из книги.

Учитесь задавать вопросы! — как задавать вопросы.

Как появилось ДЗ6 в интенсиве? — немного о том, как студенты пробуют общаться с работодателем.