Эта статья ставит очень важный вопрос «Чего здесь нет, что должно бы быть?». Для выявления «дыр проектирования и требований» применяется идея, похожая на выявление черных дыр. Например, часто существуют зависимости между количеством ошибок, относящихся к определенной области, и тем была ли эта область полностью протестирована. Также дыры могут быть в том, что показывают типы ошибок. Хендриксон подготавливает почву для поиска и советует как «искать там, где ничего нет».

Я задала этот вопрос много лет назад во время прогулки с моим отцом ясной зимней ночью, очарованная звездами. Отец посмотрел на меня, его руки были засунуты в карманы, наше дыхание было видно в холодном воздухе, и улыбнулся. «В самом деле, детка, так как они не могут видеть то, чего нет, они ищут там, где много пустоты (ничего)».

Идея такова: поиск чего либо путем просмотра пустоты.

Эта статья о том, как я искала дыры в проектировании и требованиях. Если при проектировании ничего не говорится о безопасности, никто не подумает о ней. Если нет требований от организатора, то, вероятно, организатор не задействован в процессе формирования требований.

Первый способ — это наблюдение за результатами тестирования. Если с определенной областью не сопоставлены ошибки, это говорит о том, что данная область не была протестирована. Конечно, если с некоторой областью сопоставлено много ошибок, это не означает, что она хорошо протестирована. Так что я также смотрю на тип ошибок. Достигают ли они сердца функциональности или они все поверхностные и несерьезные. Относятся ли ошибки к входным данным, переполнению буфера или длине пути? Я ищу указание на то, что в нашем тестировании существуют дыры — виды ошибок, которые еще не найдены.

Искать отсутствие информации не легко. Вы должны знать, что вы ожидаете увидеть, до того как сообщите, что что-то пропущено. Это означает, что вам необходим интеллектуальный список категорий ошибок, которые вы можете ожидать найти в тестируемом приложении: проблемы совместного доступа, ошибки искажения данных, временные вопросы и т.д. Ваш список зависит от тестируемого приложения.

Вам также необходимо в подробностях знать то, что уже просмотрено. Если вы просматривает ошибки, найденные ранее — читаете их прежде чем считать — вы можете искать шаблоны в тестировании, которые ведут к поиску ошибок. Только подсчет недостаточен.

По мере развития проекта поиск шаблонов пропущенных ошибок становится более трудным. Чем больше привязанных к областям ошибок, тем трудней помечать области, в которых наблюдается недостаток ошибок. И еще это время, когда оно становится критическим. Вы почти закончили. Вскоре, кое — кто из Исполнительного уровня начнет спрашивать вас, почему вы до сих пор не закончили. Следующая вещь, о которой вы знаете, это то, что ПО выложена и/или не выложено на Web. Это не подходящее время для выяснения, что никто не пытается пополнять каталог из двух браузеров совместно.

Сведите ошибки в матрицу, как они хранятся в системе отслеживания ошибок. Вдоль одной стороны разделите тестируемое приложение на области. Далее сверху для всех областей разместите список всех категорий тестов. Например, если вы тестируете программу для редактирования, то вдоль стороны могут размещаться Средство Рисования, Средство ввода Текста, Вставка Картинок, Печать и т.д.

Категории сверху могут включать Отмену ввода, Drag and Drop, Международные Символы, Недостаток памяти и т.д. Вы можете иметь несколько десятков элементов на сторону, желательно, не больше тридцати. (Если ячеек будет слишком мало, вы не сможете получать необходимую информацию. Если слишком много, матрица станет слишком громоздкой). Все время кто — то добавляет ошибки, делайте отметки в соответствующих ячейках вашей матрицы. Вы ищите ячейки без отметок.

Эта матрица легкое средство для вашего собственного поиска черных дыр. Не пытайтесь занести слишком много информации в каждую ячейку. Даже попытка сжатия числа ошибок может оказаться слишком большой. Если вы пытаетесь отслеживать больше информации, чем одна отметка, поддержание матрицы в актуальном состоянии становится затруднительным и, вероятно, вы не сможете это сделать. Если вы используете отметки в ячейке только для хранения количества ошибок, пяти или десяти минут в день для чтения ошибок и пометок о них в ячейках будет достаточно.

Месяцы на проекте, и у вас есть карта, которая показывает количество ошибок по областям ПО и категории тестов. Сейчас вы можете находить дыры. Дополнительный бонус: Когда проект закончен, матрица может также обеспечивать информацию о слабых областях ПО, так что эти области могут быть улучшены в будущих проектах. Каждая особенность имела проблемы с граничными значениями?

Поиск чего — либо, путем просмотра пустоты — трудные и время поглащающие, но стоящие усилия. Области, где мы оставили не залатанные дыры, это то, что заставляет нас бегать кругами с огненной отдышкой, отчаянно пытаться загрузить патч для разгневанных пользователей, которые (патчи) раздуваются до апгрейда, яростно выкладывать Web сайт, который работает с различными браузерами.