четверг, 8 октября 2015 г.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См также:
Примеры неправильных вопросов от Куликова — еще одна выдежка из книги.
Учитесь задавать вопросы! — как задавать вопросы.
Как появилось ДЗ6 в интенсиве? — немного о том, как студенты пробуют общаться с работодателем.

2 комментария:

  1. Оспади........одна вода. Как такое вобще можно читать? Советы КЭПа....

    ОтветитьУдалить
    Ответы
    1. Я рада, что вы никогда не сталкивались с проблемами КЭПа и не допускали "простых" ошибок :-)

      Удалить