Глава 6: Система отслеживания проблем 177

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

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

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

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

Несколько замечаний о форме отчета о проблеме

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

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

178 Часть II: Приемы и технологии тестирования

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

• При вводе отчета в систему она должна автоматически присваивать полю Резолюция значение Рассматривается.

• Никто, кроме тестировщика, не должен иметь право вводить значе­ние Закрыто в поле Состояние. По умолчанию этому полю должно присваиваться значение Открыто.

Терминология

В этом разделе определяются некоторые ключевые термины организа­ции баз данных.

Система управления базами данных (СУБД) представляет собой набор компьютерных программ, позволяющих определить структу­ру базы данных, вводить и редактировать данные и генерировать от­четы. Скорее всего, вы выберете для разработки системы отслеживания проблем одну из имеющихся на рынке современных СУБД или средств разработки приложений, обладающих возможно­стями работы с базами данных (это может быть Oracle, MS Access, Delphi и т.п.). По отношению к выбранному инструментальному средству ваша система будет приложением, но для пользователей, считая и вас, ее можно назвать СУБД.

Файл — это набор информации, которую операционная система хранит вместе под одним именем. База данных может состоять из множества файлов. Вот упрощенный пример организации данных для системы отслеживания проблем.

• В главном файле данных хранятся все отчеты о проблемах. Если их очень много, можно разделить их на несколько файлов, воз­можно, по типам или датам.

• В индексных файлах хранится информация о местоположении каждого отчета в главном файле данных. В одном индексном файле эта информация может быть отсортирована по датам отче­тов, в другом по функциональным областям и т.д.