Какие активности входят в систему обеспечения качества программного продукта

Обновлено: 04.07.2024

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

7.1. Подходы к качеству программного обеспечения

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

ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик;
"усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;
ISO 9000 [ISO 9000 1992] - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" [ISO 9001 1992];

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

модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);
определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).

Таблица 3.2. Подходы к качеству

Объект качества	Соответствие	Усовершенствование
Продукт	ISO 9126	"Усовершенствование практики"
Процесс	ISO 9000, процесс обеспечения качества	CMM, SPICE, .

Качество начинается с удовлетворения потребностей разработчиков.
Качество доказывается удовлетворением потребностей пользователей.

Подходы к достижению качества таковы:

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

7.2. Характеристики качества программного обеспечения

В настоящее время не существует общепринятых критериев качества программного обеспечения.
Стандарт ISO 9000-3, п. 6.4.1

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

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

Две наиболее интересные характеристики рассмотрим подробнее.

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

предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.

Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик. *
- Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.
- Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.
- Оценка модульного разбиения программы. Такая оценка должна состоять из множества критериев. Например, сложность модуля оценивается совокупностью сложности определяемых в нем процедур и сложности связей модуля с другими модулями по импорту и экспорту определяемых сущностей.
7.3. Оценка качества процесса разработки

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

7.3.1. Модель зрелости процесса разработки программного обеспечения
- Начальный уровень. На этом уровне процесс разработки характеризуется практическим отсутствием процессов управления. Успех проекта зависит от индивидуальных усилий, личных качеств и даже героизма участников проекта.
- Повторяемый уровень. На этом уровне зрелости в компании должны быть внедрены основные процессы управления для отслеживания стоимости, графика проекта и его функциональности. Уровень характеризуется тем, что управление проектами основывается на накопленном опыте и ранее достигнутые успехи будут повторены на подобных приложениях.
- Определенный уровень. Процесс разработки программного обеспечения (как на уровне управленческой, так и инженерной деятельности) документирован, стандартизован и интегрирован на уровне всей организации. Процесс перестает зависеть от индивидуальных качеств отдельных разработчиков и не может скатиться на более низкие уровни в кризисных ситуациях.
- Управляемый уровень. В компании устанавливаются детальные количественные показатели на процесс разработки и качество продукта. И процесс разработки, и продукты - понимаемы и контролируемы.
- Оптимизирующий уровень. Продолжающееся совершенствование процесса разработки на основе анализа текущих результатов процесса и применения инновационных идей и технологий.
7.3.2. Определение возможностей и улучшение процесса создания программного обеспечения
- Уровень 0. Процесс не выполняется.
- Уровень 1. Выполняемый процесс.
- Уровень 2. Управляемый процесс.
- Уровень 3. Установленный процесс.
- Уровень 4. Предсказуемый процесс.
- Уровень 5. Оптимизирующий процесс.
- Сравнение процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов дает возможность определить сильные и слабые стороны процесса, его внутренние риски.
- Оценка возможности улучшения данного процесса на основе определения текущих возможностей.
- Техническая реализация поставленных задач на основе сформулированных целей совершенствования процесса. После этого весь цикл работ начинается сначала.
7.4. "Достаточно хорошее" программное обеспечение

Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии
новой программы компании Microsoft произошло землетрясение.
Пользователи с ужасом ждут объявления о выходе финальной версии продукта.
Анекдот по мотивам землетрясения и выступления Б. Гейтса 23-го февраля 2001 г.

Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.
- Часто качество стремятся определить только в терминах дефектов (ошибок). С точки зрения пользователя не менее важны такие стороны, как готовность к определенной дате.
- Предполагается, что малое количество ошибок равносильно лучшему качеству, и пользователь предпочитает именно такое качество. Однако иногда пользователь готов идти на компромиссы и примириться с некоторыми ошибками в обмен на более скорое выполнение работы.
- Игнорирование таких факторов, как моральное состояние команды разработчиков и адекватные условия для работы.
- утилитарная стратегия - искусство количественного анализа и максимизации чистого выигрыша в неопределенных ситуациях;
- эволюционная стратегия - рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам;
- героические команды - не могучие гениальные программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству;
- динамическая инфраструктура - противоположность бюрократии и засилию политики;
- динамические процессы - процессы, поддерживающие работу в эволюционной среде.
К сожалению, "достаточно хорошее" программное обеспечение редко бывает действительно достаточно хорошим. Никлаус Вирт отмечает, что это "следствие грустного проявления духа нашего времени, в котором исчезает личная гордость за свою работу". По его мнению, "нельзя ожидать качественно выполненной работы, если не отдавать ей себя полностью, если нет личного удовлетворения, более того - удовольствия от нее".

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

7.5. Стандартизация информационных технологий

Стандарт - общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль - набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи [Козлов 1999].
- по типу установления требований:
  - устанавливающие требования к объекту;
  - устанавливающие требования к процессу;
  - международные;
  - государственные;
  - отраслевые;
  - предприятий;
  - принятые юридически;
  - действующие фактически.
  - Международные организации, входящие в структуру ООН.
    - International Organization for Standardization (ISO) - международная организация по стандартизации.
    - International Electrotechnical Commision (IEC) - международная электротехническая комиссия.
    - International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.
    - Institute of Electrical and Electronic Engineers (IEEE) - институт инженеров по электротехнике и электронике.
    - Internet Activity Board (IAB) - совет управления деятельностью Интернета.
    - Object Management Group (OMG) - группа управления объектами.
    - Х/Open - консорциум, организованный группой поставщиков компьютерной техники.
    - Open Software Foundation (OSF) - фонд открытого программного обеспечения.
    В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий. Об абсолютной стандартизации
    Идеальный подход мог бы состоять в разработке исчерпывающего набора стандартов. Однако для некоторых современных направлений в области информационных технологий это нереально, учитывая скорость (а также стоимость) происходящих изменений. Ко времени внесений очередной порции изменений может появиться новая версия, или программистское сообщество может вообще начать двигаться в другом направлении. Абсолютная стандартизация - это мираж.
    
    Знаете ли Вы, что аспектно-ориентированное сборочное программирование - это разновидность сборочного программирования, основанная на сборке полнофункциональных приложений из многоаспектных компонентов, инкапсулирующих различные варианты реализации.
    
    Качество программного обеспечения (Software Quality) - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств.
    
    Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
    
    Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта.
    
    Контроль качества (Quality Control - QC) - это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта".
    
    Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
    
    Верификация (verification) - это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, которые были определены в начале текущей фазы.
    
    Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.
    
    План Тестирования (Test Plan) - это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
    
    Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования.
    
    Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
    
    Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата.
    
    Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
    
    Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.
    
    Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала прохождения шагов тест-кейса до получения результата теста.
    
    Качество программного обеспечения
    
    Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств.
    
    Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
    
    Характеристики качества ПО
    
    Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа.
    
    Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.
    
    Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.
    
    Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями.
    
    Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов для реализации новых требований, для облегчения дальнейшего обслуживания и адаптирования к имеющемуся окружению.
    
    Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое.
    
    Модель качества программного обеспечения
    
    На данный момент, наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.Рис.1. Модель качества программного обеспечения (ISO 9126-1)
    
    Кто такой тестировщик и что он делает
    
    В начале карьеры любой специалист (и тестировщик не является исключением) является исполнителем и учеником. Достаточно хорошо понимать, что такое тест-кейсы, отчёты о дефектах, уметь читать требования, пользоваться парой инструментальных средств и хорошо уживаться в команде.
    
    Постепенно тестировщик начинает погружаться во все стадии разработки проекта, понимая их всё полнее и полнее, начинает не только активно использовать, но и разрабатывать проектную документацию, принимать всё более ответственные решения.
    
    Так какие же технические навыки нужны, чтобы успешно начать работать тестировщиком? Прежде чем приступить к самому перечислению, оговорим особо: этот список рассчитан, в первую очередь, на тех, кто приходит в тестирование из не технических профессий (хотя часто его же приходится озвучивать и студентам технических вузов).
    
    Надеюсь, Вы обратили внимание на то, что самого тестирования в списке нет. Всё верно, ведь ему посвящена вся эта книга целиком, так что позволим себе не копировать её сюда.
    
    Также отметим личностные качества, позволяющие тестировщику быстрее стать отличным специалистом:
    1. Повышенная ответственность и исполнительность;
    2. хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли;
    3. терпение, усидчивость, внимательность к деталям, наблюдательность;
    4. хорошее абстрактное и аналитическое мышление;
    5. способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.
    Да, сложно найти человека, который бы в равной мере обладал всеми перечисленными качествами, но всегда полезно иметь некий ориентир для саморазвития.
    
    Откуда берутся ошибки в ПО?
    
    Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, то это может привести к проблеме в работе программы – она используется неправильно, значит, может повести себя не так, как ожидалось.
    
    Ошибка (error) – это действие человека, которое порождает неправильный результат.
    
    Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.
    
    Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.
    
    При исполнении кода программы дефекты, заложенные еще во время его написания, могут проявиться: программа может не делать того, что должна или наоборот делать то, чего не должна – происходит сбой.
    
    Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).
    
    Сбой в работе программы может являться индикатором наличия в ней дефекта.
    
    Таким образом, баг существует при одновременном выполнении трех условий:
    - известен ожидаемый результат;
    - известен фактический результат;
    - фактический результат отличается от ожидаемого результата.
    Важно понимать, что не все баги становятся причиной сбоев – некоторые из них могут никак себя не проявлять и оставаться незамеченными (или проявляться только при очень специфических обстоятельствах).
    
    Причиной сбоев могут быть не только дефекты, но также и условия окружающей среды: например, радиация, электромагнитные поля или загрязнение также могут влиять на работу как программного, так и аппаратного обеспечения.
    
    Всего существует несколько источников дефектов и, соответственно, сбоев:
    - ошибки в спецификации, дизайне или реализации программной системы;
    - ошибки использования системы;
    - неблагоприятные условия окружающей среды;
    - умышленное причинение вреда;
    - потенциальные последствия предыдущих ошибок, условий или умышленных действий.
    Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и когда, будет напрямую зависеть качество системы.
    
    Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.
    
    Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.
    
    Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.
    
    В первом случае все было сделано правильно и мы получили продукт, полностью соответствующий ожиданиям заказчика и удовлетворяющий критериям качества.
    
    В четвертом случае дефекты были заложены еще на этапе формирования требований; вся дальнейшая разработка и даже тестирование пошли по изначально неправильному пути. Во время тестирования мы не найдем багов – программа пройдет все тесты, но может быть забракована заказчиком.
    
    Условно можно выделить пять причин появления дефектов в программном коде.
    1. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но, если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО.
    2. Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек.
    3. Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества.
    4. Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро, а это сказывается на качестве продукта.
    5. Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте.
    Принципы тестирования
    
    Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом.
    
    1. Тестирование показывает наличие дефектов
    
    Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
    
    2. Исчерпывающее тестирование невозможно
    
    Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
    
    3. Раннее тестирование
    
    Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения и его усилия должны быть сконцентрированы на определенных целях.
    
    4. Скопление дефектов
    
    Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
    
    5. Парадокс пестицида
    
    Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
    
    Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
    
    6. Тестирование зависит от контекста
    
    Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
    
    7. Заблуждение об отсутствии ошибок.
    
    Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будет не важным, если система окажется неудобной в использовании и не будет удовлетворять ожиданиям и потребностям пользователя.
    
    И еще несколько важных принципов:
    - тестирование должно производиться независимыми специалистами;
    - привлекайте лучших профессионалов;
    - тестируйте как позитивные, так и негативные сценарии;
    - не допускайте изменений в программе в процессе тестирования;
    - указывайте ожидаемый результат выполнения тестов.
    Верификация и валидация
    
    Эти два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
    
    Верификация (verification)– это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта.
    
    Валидация (validation)– это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.
    
    Следующая таблица поможет выделить ключевые отличия между этими понятиями:
    
    На практике отличия верификации и валидации имеют большое значение:
    - заказчика интересует, в большей степени, валидация (удовлетворение собственных требований);
    - исполнителя, в свою очередь, волнует не только соблюдение всех норм качества (верификация) при реализации продукта, а и соответствие всех особенностей продукта желаниям заказчика.
    QA, QC и тестирование
    
    Так в чем же разница между QA и тестированием и что такое Quality Control?
    
    Многие люди до сих пор путают эти понятия, что, в общем, и не удивительно, принимая во внимание, что в нашей стране они зачастую могут использоваться для описания одних и тех же процессов. Но с формальной точки зрения, а именно она нас, как специалистов, и интересует, эти три понятия имеют существенно отличающиеся значения.
    
    Можно оформить их соотношение в виде таблицы:
    
    Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.
    
    Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.
    
    Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:
    
    Статья приводит примеры и доводы, которые способны развеять некоторые распространенные заблуждения, касающиеся роли тестирования и обеспечения качества ПО (SQA), а также выработать рекомендации для успеха SQA-команд.
    
    Условия тестирования и обеспечения качества ПО (QA) часто используются в IT-индустрии профессионалами тестирования (часто классифицируемыми как профессионалы по обеспечению качества).
    
    Несмотря на то, что оба понятия видят общей целью качество продукта, принципиальное различие между ними состоит в том, что тестирование проводится после того, как продукт был создан или в случае статических испытаний после того, как документ был написан. В отличие от этого контроль качества подразумевает деятельность, которая обеспечивает качество продукта на всех этапах его создания.
    
    Чтобы оценить различия между тестированием и QA, важно сначала понять тесно связанные с ними понятия - контроль качества (QС) и обеспечение качества (QA).
    
    Контроль Качества (QС)
    
    ISO9000 определяет Контроль Качества (QС) как часть менеджмента самого качества, сосредоточенную на выполнении требований по отношению к оценке количества багов (при их наличии) в продукте. Контроль качества представляет собой набор процессов/действий, направленных на оценку разработанного продукта (проекта документа, системы развития и т. д.) и показатель соответствия требованиям заказчика. Это гарантирует проверку поставляемой продукции на качество и определяет, насколько хорошо она продумана и создана. Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом, тестирование является неотъемлемой частью контроля качества.
    
    Обеспечение качества (QA)
    
    ISO9000 определяет обеспечение качества ПО как часть менеджмента качества, ориентированную на создание уверенности в том, что требования к устранению багов будут выполнены. Целью QA является обеспечение гарантии того, что продукт будет соответствовать ожиданиям качества заказчика. Она состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки, и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование. В то время, как QA является активной деятельностью, QC – наоборот, пассивной. Примеры деятельности по обеспечению качества включают установление стандартов и процессов, проверки качества и выбор инструментов.
    
    Отличия между обязанностями QA команд и тестировщиков:
    
    Тестировщики выполняют планирование тестирования, анализ результатов испытаний, проверку тестов, проверки и тестирования отчетности через различные уровни испытаний.
    
    Тема связана со специальностями:
    - Реализация организационной политики касаемо качества, стандартов и процессов;
    - Оказание помощи с подготовкой в области обеспечения качества и планов обеспечения качества проекта;
    - Проверка соответствия процессов проекта планам качества;
    - Проведение регулярных проверок проектных продуктов и процессов, а также представление регулярных оценок для высшего руководства;
    - Эскалация ситуации, когда есть отклонения от руководящих принципов или стандартов.
    - Выполнением независимых обзоров;
    - Наличием процедур управления изменениями проектов;
    - Наличием процедур управления конфигурациями проектов;
    - Наличием ретроспективы того, что процессы планируются и воплощаются;
    - Обеспечением уверенности в качестве путем развития системы жизненного цикла;
    - Проведением непрерывных улучшений в процессе контроля качества и воплощением рекомендаций, основанных на усвоенных ранее уроках.
    Эти атрибуты определяются как QA-обязанности команды, но следует отметить, что это не означает их развитие командой QA, а, скорее, обеспечение их реализации в манере, которая является "пригодной для целей".
    
    В рамках своей роли по контролю качества тестировщики могут выдвигать требования по проверке образцов документов проекта, деятельности по управлению конфигурациями программного обеспечения, дизайна, кода и т.д.
    
    Отличия между планированием испытаний и документацией в тестировании и QA:
    
    Тестировщики подготавливают тестовые стратегии и планы, основанные на базовых тест-документах, таких как бизнес-требования и проектные решения. Эти документы планирования тестирования являются основой испытания процессов на различных запланированных испытательных уровнях. Эти уровни и есть тест приемки, вход и критерии выходов между уровнями, подробные графики испытаний, экологические требования, управление дефектами, управление тестированием и ведение отчетности.
    
    В отличии от этого, обеспечение качества программного продукта или планы качества включают более широкий набор действий на протяжении всех этапов разработки. Это играет свою роль в разработке методологий управления проектами, например Prince2, которая поощряет использование планов по качеству проекта и журналов качества, которые были разработаны в начале жизненного цикла, при инициировании проекта.
    
    Типичный проект плана качества включает в себя ожидания клиентов, критерии приемки, плановый контроль качества и аудита процессов, планы управления конфигурациями и процедуры управления изменениями. Планы по качеству для проектов используют политику самой организации в этой сфере, стандарты или руководящие принципы, являющие собой основы обеспечения качества.
    
    Мониторинг плана обеспечения качества проекта в ходе создания проекта осуществляется беспрерывно и обновляет результаты планируемого качества деятельности в журнале.
    
    Существуют различные точки пересечения между управлением рисками и качеством, и поэтому реестр рисков может сделать весомый взнос в подготовку планов по качеству.
    
    Кто выполняет функцию обеспечения качества в организации
    
    Потребность в команде по обеспечению качества программного обеспечения растет с размером организации и уровнем ее политики в области качества. Там, где требуется такая команда, очень важно, чтобы функция QA оставалась независимой от проекта и оперативных групп. Их линия связи, однако, должна предоставлять им мощную поддержку именно в том виде, в каком это требуется.
    
    Видео курсы по схожей тематике:
    
    Web Testing automation on Java
    
    TDD - Разработка через тестирование
    
    Некоторые организации имеют функцию QA, встроенную в их предприятия отдельным звеном - Офисом управления проектами. Это отвечает критериям независимости, однако, организации, что следуют этой модели, необходимо убедиться, что эта команда состоит из обученных и/или специализированных аналитиков по обеспечению качества.
    
    Наблюдения и рекомендации для успешных QA-команд
    
    Чтобы быть успешными, QA-команды должны быть независимыми от проекта и оперативных групп. Это обеспечивает команде возможность проведения объективной оценки проектов.
    
    Возникает вопрос: следует ли функциям тестирования и QA находиться в одной команде? Это может хорошо работать в небольших организациях, однако появляется недостаток в виде создания возможного конфликта интересов при мониторинге деятельности тестирования. Это и подчеркивает заблуждение в том, что тестирование и QA являются синонимическими понятиями.
    
    Если аналитики обеспечения качества слишком процессно-ориентированные и настаивают на процессах или документации, которые могут не иметь особого значения, это может ухудшать отношения с руководителями проекта.
    
    Стандартные контрольные списки являются полезным механизмом для проведения аудита проектов, особенно если они разработаны в соответствии с фазами жизненного цикла разработки. Например, на этапе проектирования в перечень вопросов может быть снесено: "Есть ли прослеживаемость между дизайном и требованиями элементов?"
    
    Хотя регулярная отчетность для высшего руководства очень важна, разработка правильных шаблонов и показателей, обеспечение топ-менеджеров требуемой информацией гарантирует, что этим отчетам уделяется должное внимание. Это лучше всего достигается путем проведения встреч с соответствующими представителями высшего руководства, предоставления им отчетов и получения от них отзывов и комментариев.
    - Постоянное совершенствование
    Уроки, извлеченные из проектов, обеспечивают QA-команду основой для оценки процессов и рекомендациями по обеспечению качества, включая постоянные улучшения. Это включает разработку перечней, гибкость, поддерживаемость хороших отношений с заинтересованными сторонами и внесения улучшений в управленческую отчетность.
    
    Так, непрерывные усовершенствования могут также потребовать внесения изменений в методологии разработки системы, потому QA-командам рекомендуется сохранять методологию разработки ИТ-отдела.
    
    Преимущества
    
    Успешная QA-команда может добавить значительную ценность для организации. Некоторые из этих преимуществ включают в себя:
    
    Бесплатные вебинары по схожей тематике:
    
    Selenoid или Selenium Grid - что лучше?
    
    QA практикум. Техники тест дизайна. Часть 1
    
    Scrum на 24 команды? Масштабируем Agile, используя LeSS!
    - Повышение качества производимой продукции
    - Последовательность в процесах, используемых для доставки
    - Продолжение совершенствования организации процессов
    - Снижение общих расходов на доставку
    - Увеличение приложений для документаци по поддержке продукта
    Недостатки
    - Первоначальные затраты в штатном расписании аналитиков обеспечения качества ПО
    - Усложнение процессов, которые могут генерировать разочарование в некоторых сотрудниках
    Выводы
    
    Сопоставление различий в деятельности и ответственности между контролем качества и обеспечением качества дает им хорошую оценку в различных условиях. QC подтверждает, что конкретные результат отвечают стандартам и спецификациям. В отличие от этого, QA является более широкой функцией, что охватывает планирование и контроль на протяжении всего жизненного цикла разработки. Тестирование, с другой стороны, является неотъемлемой частью контроля качества. Для того, чтобы организация эффективно осуществляла процессы управления качеством, эти потоки должны работать в тандеме.
    
    Тема качества программного обеспечения сегодня весьма популярна, однако на фоне разнообразного толкования качества трудно получить целостное представление о проблеме и основных принципах управления качеством. Возможно, предлагаемый в статье обзор методов повышения качества и подход анализа качества поможет по-иному взглянуть на эту задачу.
    
    Итак, качество программного продукта— это степень соответствия функциональных, технических, эксплуатационных характеристик разработанного программного продукта целям, которые были поставлены перед началом разработки этого продукта. Его качество— некая функция от многих переменных, в том числе следующих:
    
    Другие критерии можно найти, например, в [1]. Компания-разработчик определяет свои стандарты качества для каждого критерия и для каждого программного проекта. При оценке качества необходимо иметь возможность количественно оценить каждый из критериев. В таблице приведена зависимость конкретного вида деятельности и критериев качества.
    
    На качество конечного продукта влияют все фазы и виды деятельности проекта, и от того, насколько хорошо и качественно мы работаем на каждой фазе проекта (а не только, например, на фазе тестирования), зависит, насколько качественным получится разрабатываемый продукт. Другими словами, качество процесса разработки определяет качество продукта [1, 2].
    
    Для анализа качества введем обобщенный критерий— дефект, определяющий любое отклонение от установленных для проекта стандартов качества. Например, недостаток функциональности или лишняя функциональность— дефект; неудобный интерфейс— дефект; плохой дизайн или грязный код, который негативно скажется на сопровождаемости,— дефект; неприемлемая производительность— дефект; некорректная работа программы— частный случай дефекта; орфографическая ошибка в документации— дефект.
    
    Дефекты можно классифицировать по следующим параметрам:
    
    Имея подобный обобщенный показатель, становится проще оценивать и анализировать качество разрабатываемого программного продукта, а также качество самого процесса разработки. Можно считать количество дефектов или сумму их весов (по какому-либо параметру), можно оценивать плотность дефектов на единицу объема продукта, анализировать, какие фазы процесса являются наиболее проблемными для нас и т.д., сведя борьбу за качество к борьбе с дефектами.
    
    Управление качеством программного продукта
    
    Можно нарисовать график изменения количества дефектов в проекте с течением времени. На рис. 1 приведен график для случая водопадной модели жизненного цикла проекта и традиционного подхода к качеству программного продукта, где основной упор делается на тщательное тестирование.
    
    Верхняя линия (рис. 1)— примерное количество внесенных дефектов на текущий момент времени, а нижняя— количество найденных и исправленных дефектов на текущий момент времени (предполагается, что дефекты исправляются практически сразу после обнаружения). Разница между линиями в каждый момент времени отображает количество имеющихся на данный момент дефектов. Чем меньше будет эта разница в конце проекта, тем качественнее продукт.
    
    Эффективность поиска дефектов
    
    Рассмотрим, например, фазу системного тестирования, в ходе которой обнаруживается некое количество дефектов Dfound, но сколько-то дефектов остается ненайденным на момент завершения фазы Dmissed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно Dfound + Dmissed.
    
    Отношение найденных дефектов к их общему числу, выраженное в процентах, назовем эффективностью поиска дефектов [2]— это одна из основных характеристик качества процесса разработки, которую необходимо постоянно контролировать. Для каждой фазы, в ходе которой находятся и исправляются дефекты, при стабильном и предсказуемом процессе и прочих равных условиях эту величину можно считать приблизительно постоянной, что позволяет количественно оценивать уровень качества (выраженный в количестве ненайденных дефектов) для текущего и для планируемых проектов.
    
    Эффективность поиска дефектов можно рассматривать как для отдельных фаз, так и для всего жизненного цикла разработки. При этом эффективности отдельных фаз определяют эффективность для всего жизненного цикла. Каждую фазу поиска дефектов можно рассматривать как своего рода фильтр, который удерживает некую часть дефектов, а весь жизненный цикл— как систему фильтров [2]. Если на ранних этапах жизненного цикла стоят плохие фильтры, которые пропускают много дефектов, то эти дефекты накапливаются, и, чтобы их хорошо отфильтровать, в конце жизненного цикла (фаза тестирования) будет необходим очень хороший фильтр.
    
    Дефекты со временем имеют тенденцию не только накапливаться, если не предпринимать ранних мер по их устранению, но и увеличивать стоимость их исправления, причем часто эта зависимость— экспоненциальная. Для водопадной модели жизненного цикла эта зависимость хорошо иллюстрируется графиком из рис. 3. Для итерационной модели жизненного цикла картина будет похожая, изменятся только надписи: вместо названий фаз будут номера итераций.
    
    Комплексный подход к управлению качеством
    
    Полагаясь только на одно, даже и очень тщательное, тестирование, проблему качества не решить. Если не предпринимать никаких мер по борьбе с дефектами вплоть до этапа тестирования, то к началу тестирования в проекте может накопиться слишком много дефектов, поэтому дефекты надо искать и исправлять постоянно, на протяжении всего жизненного цикла проекта. Кроме того, надо принять все меры по предотвращению или недопущению дефектов.
    
    Применение методов поиска дефектов на протяжении всего жизненного цикла проекта поднимает кривую найденных дефектов вверх, а применение методов предотвращения дефектов опускает кривую вносимых дефектов вниз (рис. 4). Таким образом, количество ненайденных дефектов на протяжении всего жизненного цикла уменьшается, и как результат уменьшается количество ненайденных дефектов в конце проекта.
    
    Методы поиска и предотвращения дефектов
    
    Известно немало методов поиска дефектов.
    
    Ручной анализ, или обзор разрабатываемых артефактов. Персональные проверки (personal review) [2], формальные инспекции [2, 3], групповые обзоры (walkthrough), парное программирование [4], групповое проектирование и т.п.
    
    Автоматическая статическая проверка. Компиляция (помимо явных дефектов компилятор умеет находить неявные), статический анализ кода с помощью специальных анализаторов, проверка на соблюдение принятого код-стандарта и стиля.
    
    Автоматизированное тестирование. Модульное или блочное тестирование (unit testing) [4, 5], функциональное (комплексное) тестирование, тестирование графического интерфейса пользователя, тестирование производительности, стресс-тестирование, использование утверждений (asserts) [6] и т.д.
    
    Эффективная стратегия поиска дефектов состоит в применении комбинации нескольких методов, каждый из которых будет иметь свой собственный уровень эффективности, выраженный в процентах. Согласно данным [1], тестирование имеет сравнительно низкую эффективность поиска дефектов (30-40%), а для того, чтобы сделать ее высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестировщиков более 1000 составляет около 75%).
    
    Вряд ли возможно разрабатывать ПО вообще без дефектов, но попытаться уменьшить число вносимых дефектов стоит попробовать. Перечислим наиболее известные методы предотвращения дефектов.
    
    Прототипирование. Создание и опробование модели разрабатываемой системы с целью проверить ее характеристики и выявить неверные предположения и решения, которые могли бы привести к серьезным дефектам (и переделкам) при разработке [6].
    
    Использование стандартов на все виды продуктов, производимых в ходе разработки ПО (требования, дизайн, код, различная документация и т.д.).
    
    Использование готовых компонентов— чем меньше приходится разрабатывать новых решений, тем меньше ошибок.
    
    Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать ее. Частный случай этого подхода— Test-Driven Development, при котором модульные тесты разрабатываются не после, а до кодирования.
    
    Регулярный анализ причин появления наиболее серьезных дефектов и поиск путей устранения этих причин. Это может происходить на периодических собраниях команды разработчиков [3], или можно проводить такой анализ для каждого серьезного дефекта, найденного на этапах системного тестирования или после внедрения. Результатом такого анализа должны быть модификации процесса разработки, направленные на устранение причин появления дефектов или, как минимум, способствующие более раннему обнаружению подобных дефектов.
    
    Стоит также упомянуть человеческий фактор— никакие методы не заменят профессионализм и опыт разработчиков и менеджеров. Опытные профессионалы, как правило, делают меньше ошибок, что дает хороший задел для качественной разработки.
    
    Итерационный жизненный цикл
    
    Рассмотрим итерационный жизненный цикл, состоящий из пяти итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 5).
    
    Предположим, эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций? После первой итерации эффективность будет равна 50%; после второй— 62,5%; после третьей— 70,8%; после четвертой— 76,6%; после пятой эффективность поиска дефектов всех пяти итераций будет равна 80,6%.
    
    В реальной жизни эффективности поиска дефектов на разных итерациях, скорее всего, будут отличаться, что связано с неоднородностью деятельностей на разных итерациях, но в любом случае налицо явный прогресс в качестве перед простым водопадным жизненным циклом. На каждой последующей итерации находятся дефекты не только текущей итерации, но и оставшиеся дефекты предыдущих итераций. В результате общая эффективность поиска дефектов увеличивается.
    
    Таким образом, получается, что добиться улучшения качества можно не только введением дополнительных методов раннего поиска дефектов (таких, как инспекции, обзоры и т.п.), но также и путем перехода от водопадного к итерационному жизненному циклу разработки ПО.
    
    Цена качества
    
    Может показаться, что применение множества различных методов повышения качества ПО увеличит стоимость разработки, однако это верно лишь в краткосрочной перспективе (пока процесс их использования не стабилизировался) либо при неграмотном использовании методов. В долгосрочной же перспективе комплексное применение методов повышения качества не только не удорожает разработку, но может удешевить ее.
    
    Во-первых, чем раньше был найден дефект, тем дешевле обходится его исправление. Поэтому эффективное применение методов раннего поиска дефектов способствует снижению стоимости проекта.
    
    Во-вторых, методы поиска дефектов помимо эффективности характеризуются также средней скоростью нахождения дефектов. Согласно статистическим данным, например из [1], этот показатель у методов тестирования в несколько раз хуже, чем у методов раннего поиска дефектов. Это означает, что, тратя время на поиск дефектов на ранних фазах, мы экономим больше времени на предстоящем тестировании.
    
    Процесс управления качеством
    
    Для управления качеством недостаточно простого использования различных методов его повышения— необходимо их осознанное систематическое применение, которое стало бы неотъемлемой частью процесса разработки ПО, ориентированного на качество. Необходим постоянный контроль качества разрабатываемого ПО через метрики качества (плотность дефектов, размер переделок, среднее время между отказами и др.), а также контроль качества отдельных подпроцессов, составляющих целостный процесс разработки.
    
    Методы, которые хорошо работали вчера, сегодня могут представлять собой пустую трату времени. У каждого проекта может быть своя специфика, требующая иного набора методов повышения качества. Например, одни проекты (особо критичные) могут потребовать тщательнейшего тестирования всех тест-кейсов, в других (когда тестирование очень трудоемко) больше внимания следует уделять инспекциям, третьи (инновационные) потребуют предварительного прототипирования, четвертые (критичные к ресурсам) потребуют стресс-тестирования и т.д.. Если постоянно не контролировать эффективность методов, то со временем она может значительно снизиться.
    
    Литература
    
    Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Addison-Wesley Longman, 1995.
    
    Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Addison Wesley Longman, 2005.
    
    Пример управления качеством ПО
    
    Компания CQG является одним из поставщиков биржевой информации и программных продуктов для биржевой торговли. В компании используются следующие методы повышения качества ПО.
    
    Обязательные формальные инспекции всех артефактов (требования, архитектура, проектные модели, тест-планы, код).
    
    Регулярные собрания команд разработчиков с целью анализа причин появления наиболее серьезных дефектов и поиска путей устранения этих причин.
    
    Контроль качества процесса и проектов осуществляется регулярно с помощью следующих метрик.
    
    Плотности дефектов на 1000 строк кода, найденных на разных стадиях, таких как инспекции кода, интеграционное, системное, релиз-тестирование.
    
    Эффективность инспекций (плотность найденных замечаний, скорость проверки, процент найденных дефектов, покрытие кода инспекциями).
    
    Процент переделок (размер кода для исправления дефектов по отношению к общему числу разработанного кода).
    
    При планировании каждого проекта обязательно составляется план качества, отражающий особенности проекта с точки зрения обеспечения качества. В этом плане приводится перечень необходимых методов контроля качества, определенные параметры этих методов и ожидаемые характеристики качества будущего продукта, которых следует достигнуть.
    
    Использование разнообразных методов повышения качества и регулярный контроль качества процесса позволяет CQG обходиться довольно малым количеством тестировщиков по отношению к количеству разработчиков. При этом основной целью работы отдела тестирования является не поиск дефектов в разработанном ПО, а проверка его высокого качества.
    
    Все новые разработчики, приходящие в компанию, проходят через обязательные тренинги по процессам, методам и стандартам, принятым в компании, а также по используемым инструментам автоматизации управления разработкой программного обеспечения.
    
    Читайте также: