Обеспечение качества. Фундаментальная теория

Содержание Toggle

Обеспечение качества — основные понятия и определения

1) Качество программного обеспечения (Software Quality) — это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology]
2) Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Обеспечение качества (Quality Assurance — QA) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.

Контроль качества (Quality Control — QC) — это совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску«, «соответствие зафиксированным требованиям«, «соответствие заявленному уровню качества продукта«.

Тестирование программного обеспечения (Software Testing) — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

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

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту – «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение «качества ПО» в контексте международных стандартов:

[1061-1998 IEEE Standard for Software Quality Metrics Methodology]
Качество программного обеспечения — это степень, в которой ПО обладает требуемой комбинацией свойств .

[ISO 8402:1994 Quality management and quality assurance]
Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Характеристики качества ПО

Функциональность (Functionality) — определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает за то, что ПО работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа.

Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.

Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями.

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

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.

Модель качества программного обеспечения

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

С чего начать обеспечение качества?

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

Договоритесь об общих шаблонах
Определите последовательность действий
Убедитесь, что стандарты и процессы используются
Проводите анализ выполненных проектов
Анализируйте и учитесь, используя данные дефектов
Используйте то, что вы изучили

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

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

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

Любая организация, вовлеченная в процесс Обеспечения Качества, постоянно обучается. Самый первый шаг – это сделать Обеспечение Качества неотъемлемой частью разработки продукта. И тогда «О» действительно будет для вас началом слова «Обеспечение».

Создание и Использование Шаблонов

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

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

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

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

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

Создание инструкций или определение последовательности действий

Заметьте, в заголовке не сказано, что вам необходимо использовать стандарты или процессы. Это потому, что каждый из нас уже используют какие-либо установленные процессы для повседневных задач. Хотя у вас наверняка уже и есть какие-либо наработанные процедуры, вы должны сами у себя спросить:

Отвечают ли они вашим нуждам?
Часто ли вы их используете в соответствующих ситуациях?

Первый вопрос обращает внимание непосредственно на качество самих процессов. Достигают ли они своей цели? В зависимости от цели вы можете задать такой вопрос: обеспечивают и стимулируют ли они необходимый уровень сотрудничества? Способствуют ли они достаточному взаимодействию между командой разработчиков и заказчиками? Поддерживают ли они лучшие наработки технических стандартов? Помогают ли они достичь целей по качеству?

Зачастую люди недостаточно хорошо знают процессы, которые сами и используют. Например, процессы могут мешать взаимодействию людей, совершенствованию технического мастерства или просто не отвечать нуждам команды. Человек, который говорит «Я никогда не встречал процесса, который был бы мне по душе» скорей всего использовал много хороших процессов, но был просто в них несведущ.

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

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

Использование Стандартов и Процессов

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

Интегрированная модель зрелости процессов программного обеспечения (CMMI — Capability Maturity Model Integration) реализует это при помощи аудитов (CMMI определяет аудит, как вид деятельности по Обеспечению Качества, потому что данная модель тестирует процессы, а не продукт). При использовании гибких (Agile) методик, например, Extreme Programming или SCRUM, для этой цели нанимают инструктора. Неважно, как происходит сама проверка и как вы это у себя называете – всё это приносит лишь качественную пользу.

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

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

Каждое нарушение стандарта или процесса – это возможность его изучить и улучшить, чтобы он соответствовал нуждам команды.

Анализ прошлых проектов

Изученные уроки (Lessons Learned) или постпрограммы (Post Programs or Post Project Analysis) — это один из самых мощных инструментов упреждающего улучшения качества вашей работы. Ретроспектива – это отдельно выделяемый отрезок времени, с целью обратить свой взгляд на проделанную работу, изучить полученный опыт и задать себе следующие вопросы: «Что было хорошо и как сделать так же в будущем?» и «Что было не так и как этого можно избежать?»

Несмотря на то, что ретроспективы относят к лучшим практикам (Best Practises), используются они крайне редко. Две основные причины этого: «Сложно собрать всю команду на семинар по ретроспективе» и «Мы когда-то это делали, но это не приносило никакой пользы».

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

Члены проекта всегда доступны, потому что они все еще закреплены за проектом
Ежемесячный семинар по итогам, например, одной фазы проекта гораздо легче запланировать и он займет всего около часа (вместо целого дня).
Весь полученный опыт и наработки все еще свежи в памяти, и вряд ли что-то будет упущено
И самое важное – полученные уроки можно применить к оставшейся части проекта.

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

Использование Данных Дефекта

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

Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы:

Что было не так? Решать нужно саму проблему, а не ее симптомы. Например, зацикливание — это симптом, а изменение индекса цикла — это проблема.
Когда была создана эта проблема? Какое именно действие при разработке явилось ее источником? Это была проблема в требованиях? Проектировании системы? Коде? Тестировании?
Когда проблема была выявлена? Может она и не была сразу же устранена, но что нас интересует, сколько она существовала до того, как мы ее обнаружили
Каким образом была найдена эта проблема? Способ обнаружения можно внедрить в постоянно используемую практику.
Можно ли было обнаружить ее раньше? Есть ли какой-либо процесс Контроля Качества, который мог бы ее выявить, будь он эффективнее?
Сколько стоило устранение этой проблемы? Этот момент очень легко недооценить. Убедитесь, что вы учли процесс диагностики проблемы и всю работу по ее устранению, которую вам пришлось сделать, включая ре-дизайн, переписывание кода, ре-компиляцию, переработку тестов, повторное тестирование, повторный релиз, выпуск заплатки, формирование отчета по дефекту, отчет по статусу проекта и т.д. (Не забудьте еще возможные затраты на исправление подпорченной репутации на рынке ПО)
Какого рода была эта проблема? Когда у вас огромное количество дефектов, их категоризация облегчает анализ и обучение.

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

Используйте полученные знания

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

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

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

Метрики по обеспечению качества

Согласно международному стандарту ISO 14598:

Метрика — это количественный масштаб и метод, который может использоваться для измерения.

От себя добавим, что введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования, который мы и будем рассматривать далее.

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

Создание, использование и анализ метрик

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

Метрики по тестовым случаям (Test Cases)
Метрики по багам / дефектам
Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

Название	Описание
Passed/Failed Test Cases	Метрика показывает результаты прохождения тест кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
Not Run Test Cases	Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены

Метрики по багам

Название	Описание
Open/Closed Bugs	Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs	Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs	Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity	Количество багов по серьезности
Bugs by Priority	Количество багов по приоритету

Хотим отметить, что метрики «Open/Closed Bugs», «Bugs by Severity» и «Bugs by Priority» хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики «Reopened/Closed Bugs» и «Rejected/Opened Bugs» направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

Требования к функции можно трактовать по разному
Тестировщик не точно описал проблему
Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика «Rejected/Opened Bugs»:
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

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

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

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

* * *

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

Материал взят тут