Часть I. Процесс быстрого тестирования. требующих его исправления, то группа анализа дефектов может принять решение не обращать на него внимания

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

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

Если вы не обладаете опытом тестирования или работаете в компании, которая не использует мощных промышленный средств отслеживания дефектов, возможно, воз никнет впечатление, что методология отслеживания дефектов, в основе которой ле­ жит состояние дефекта, чересчур избыточна и громоздка. Если вы занимаетесь раз­ работкой программного продукта, выпуски которого редко когда содержат более 40 или 50 дефектов, то вы, скорее всего, правы. Однако в условиях разработки множест­ ва различных проектов количество дефектов, требующих отслеживания, достигае i многих сотен и даже тысяч. Если система отслеживания неэффективна, или если х< > тя бы всего лишь несколько заметных серьезных дефектов просочатся в поставляв мый программный продукт, руководству вашей испытательной лаборатории прел стоят довольно-таки неприятные объяснения с заказчиком.

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