Обнаружение и отслеживание дефектов

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

В связи со сказанным выше, следующие два вида деятельности считаются основ­ ными при выявлении дефектов. Первым из них является прогон тестов в соответст­ вии с планом проведения испытаний для выяснения, имеются ли какие-либо расхож­ дения между ожидаемыми и фактическими результатами тестирования. Вторым ви­ дом деятельности является качественное документирование в системе отслеживания дефектов всех отклонений, обнаруженных во время тестирования. Хорошее качество документации важно по двум причинам — во-первых, разработчикам нужна достовер­ ная и надежная информация для того, чтобы снять все порождаемые неисправностя­ ми проблемы, и, во-вторых, тестировщики должны иметь возможность воспроизве­ сти проблемы, чтобы убедиться, что внесенные изменения устранили дефект. Систе­ ма, применяемая для документирования и отслеживания дефектов, представляет со­ бой важное инструментальное средство тестирования программного обеспечения. Несколько последующих разделов посвящаются изучению системы отслеживания дефектов, анализу состояний дефектов, изменению состояний дефектов и изучению других важных аспектов документирования и отслеживания дефектов.

Определение состояний дефектов

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

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

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

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

В таблице 5.1 показан пример определения состояний дефекта. Названия состоя­ ний в каждой компании могут быть свои, возможны также дополнительные состоя­ ния, которые не указаны в этой таблице. В ней показан обобщенный набор названий и состояний, который, возможно, стоит использовать как отправную точку при соз­дании системы отслеживания дефектов " с нуля".

Таблица 5.1. Определение категории дефекта

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