Совещания аналитиков

Тестирование на этапе проектирования

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

• Действительно ли проект хорош? Будет ли на его основе создан эффективный, компактный, хорошо тестируемый и легкий в сопровождении и модернизации продукт?

• Соответствует ли проект требованиям? Проект должен быть формализованным выражением требований, представленных в документации этапа планирования.

• Полон ли проект? Описывает ли проект все взаимосвязи между модулями и данными, передачу данных между модулями, условия работы каждого модуля и их реализацию.

• Достаточно ли он реалистичен? Удовлетворяют ли имеющиеся системные ресурсы (как аппаратные, так и программные) потребностям проекта? Сможет ли программный продукт работать достаточно быстро, достаточно быстро извлекать информацию из баз данных и ее обрабатывать? Удачно ли выбраны инструментальные средства
разработчиков?

• Хорошо ли описана в проекте подсистема обработки ошибок? При нисходящем проектировании особенно велико искушение оставить вопросы обработки ошибок на потом — как самые незначительные. И когда наступает это "потом", о подобных элементах часто вооб­ще забывают, или же из-за нехватки времени они проектируются наспех, поверхностно и в результате — плохо. Все возможные усло­вия возникновения ошибок должны быть самым тщательным обра­зом продуманы и описаны в проекте. Важно правильно определить уровень, на котором обрабатывается каждая из ошибок, чтобы ее возникновение в одном модуле не вело к ошибкам в других.

Обычно целью совещаний, проводимых при анализе проектных доку­ментов, является не решение проблем, а прежде всего их выявление.

В совещании должна участвовать небольшая группа сотрудников — около семи человек. В эту группу не должны входить авторы проекта. Аналитики заранее читают документы и на совещании критикуют их и задают друг другу вопросы. Во многих компаниях проект вообще не считается завершенным, пока на него не будет составлена формальная рецен­зия (разумеется, одобрительная). Таким образом, проект перерабатывает­ся и снова анализируется до тех пор, пока он не будет одобрен группой аналитиков. Совещания этой группы могут быть трех типов: обзорные, ин­спекционные и рецензионные.

• Обзорное совещание. На таком совещании проектировщики демонстрируют модель программы. Шаг за шагом они показывают, что делает программа с тестовыми данными, предложенными аналитиками. Такая демонстрация позволяет увидеть, как взаимодействуют между собой различные части системы, и выявить ее недостатки: неудобные режимы, избыточность функций или пропущенные детали.

• Инспекционное совещание. На таком совещании специалисты подробно анализируют каждый элемент проекта или его отдельный аспект: обработку ошибок, соответствие ранее выработанным стандартам, эффективность реализации конкретной функции и т.д.

• Рецензионное совещание. К этому совещанию аналитики готовят список возникших у них вопросов. Они делятся своими соображениями и выделяют элементы проекта, которые показались им неточными или сомнительными. Цель этого совещания — сформировать список всех выявленных проблем и убедиться, что каждую из них проектировщики правильно поняли. Решение выявленных проблем в задачи совещания не входит.

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

Специальный персонал записывает все важные замечания и с помощью проекторов или другой аналогичной техники выводит их на большой экран, где они видны каждому участнику совещания. Любой, кому покажется, что записывающий упустил нечто важное, может попросить отобразить эту ин­формацию. Обязательно должно фиксироваться каждое достигнутое согла­шение. Записаны должны быть и все вопросы, которые остались открытыми до следующего совещания. Такая техника проведения совещаний исключительно способствует их продуктивности, особенно когда мнения аналитиков очень сильно расходятся.

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

28. Тестирование проекта на стадии кодирования. Методы стеклянного ящика и черного ящика.

Дата добавления: 2015-04-24