3. Понятие дефект и качество

Продукт не только должен приносить пользу заказчику, но и делать это корректно и безошибочно, т.е. качественно. Само по себе понятие качество является понятием неопределенным и расплывчатым, так как является неосязаемой и неизмеримой величиной, поэтому все интерпретируют качество по-разному. Такое неопределенное и расплывчатое представление не может быть использовано для улучшения процессов разработки программного обеспечения. Следовательно, необходимо дать четкое и удобное для работы определение. В 1979 году Crosby (с англ. «Кросиби») определил качество как «соответствие требованиям» (с англ. "conformance to requirements"), а Juran и Gryna в 1970 определили качество как «пригодность к использованию» (с англ. "fitness for use").

«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Любые несоответствия должны рассматриваться, как дефекты – отсутствие качества.

«Пригодность к использованию» принимает во внимание требования и ожидания конечных пользователей продукта, которые ожидают, что продукт или предоставляемый сервис будет удобным для их нужд. Однако разные пользователи могут использовать продукт по-разному, это означает, что продукт должен обладать максимально разнообразными вариантами использования. Каждый вариант использования это характеристика качества и все они могут быть классифицированы по категориям в качестве параметров пригодности к использованию [4].

Эти два определения качества («соответствие требованиям» и «пригодность к использованию») по существу одинаковы. Разница в том, что вариант «пригодность к использованию» указывает на важную роль требований и ожиданий заказчика. Роль заказчика, связанная с качеством, никогда не может быть переоценена. С точки зрения заказчика, качество продукта, который он приобрел, состоит из множества различных факторов, таких как: цена, производительность, надежность и т.д.

Так же термин «качество» можно показать немного с другой стороны, а именно:

• качество является атрибутом продукта;

• невозможно протестировать качество внутри продуктов/услуг;

• качество содержится внутри продуктов/услуг.

Так как качество является атрибутом продукта, то можно выделить и его атрибуты.

1. Функциональная пригодность:

• пригодностью для применения;

• корректностью (правильностью, точностью);

• способностью к взаимодействию;

• защищенностью.

2. Надежность:

• уровнем завершенности (отсутствия ошибок);

• устойчивостью к дефектам;

• восстанавливаемостью;

• доступностью;

• готовностью.

3. Эффективность:

• временной эффективностью;

• используемостью ресурсов.

4. Применимость:

• понятностью;

• простотой использования;

• изучаемостью;

• привлекательностью.

5. Сопровождаемость:

• удобством для анализа;

• изменяемостью;

• стабильностью;

• тестируемостью.

6. Переносимость:

• адаптируемостью;

• простотой установки (инсталляции);

• сосуществованием (соответствием);

• замещаемостью.

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

Более подробно следует рассмотреть понятие дефекта (на англ. «bug»). Что стоит считать дефектом, а что нет.

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

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

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