→ Пошук по сайту       Увійти / Зареєструватися
Знання Тестування програмного забезпечення та контроль якості

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

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

  1. это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061—1998 IEEE Standard for Software Quality Metrics Methodology]
  2. это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [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] Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.

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

  • Функциональность (Functionality) — определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает за то, что ПО работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа.
  • Надежность (Reliability) — способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики — это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.
  • Удобство использования (Usability) — возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.
  • Эффективность (Efficiency) — способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями.
  • Удобство сопровождения (Maintainability) — легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к именующемуся окружению.
  • Портативность (Portability) — характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.
При старте QA организации, начните со следующих шагов. Они относительно легки в осуществлении и обеспечении настоящих выгод качества:
  • Договоритесь об общих шаблонах
  • Определите последовательность действий
  • Убедитесь, что стандарты и процессы используются
  • Сохраняйте последующие анализы проекта
  • Анализируйте и учитесь, используя данные дефектов
  • Используйте то, что вы изучили

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

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

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

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

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

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

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

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

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

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

Создание Инструкций

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

  1. Отвечают ли они вашим потребностям?
  2. Выполняете ли вы их последовательно в соответствующих средах

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

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

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

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

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

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

Модель CMMI (Capability Maturity Model Integration) делает это через проверку процессов. (CMMI классифицирует эти проверки как обеспечение качества, потому что они проверяют процесс больше, чем продукт.) Гибкие технологии программирования (например, Экстремальное Программирование - Extreme Programming или XP) используют для этого метод коучинга (coaching). Независимо от того, как эта проверка сделана или как она называется, она заканчивается выгодами качества.

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

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

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

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

    Хотя последующие анализы широко признаны как “лучшая практика” (Best Practise) мы убедились в том, что они довольно редки. Две наиболее часто высказываемые причины для этого: “Трудно собрать всех вместе для обсуждения и последующего анилиза проекта” и ” Мы делали это, но это никогда не имело никакого эффекта”.

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

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

    Вторая причина, почему последующие анализы имеют тенденцию быть редкими – это то, что вы часто собираете много интересной практической информации, но у вас нет возможности использовать эту информацию в работе над будущими проектами. (Я предлагаю “Применяйте то, что вы изучили”.)

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

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

    Данные о дефектах, которые является полезными для усовершенствования качества, включают:

    • Что было неправильно? Это - не признак, но проблема, которая должна была быть исправлена. Например: "бесконечная петля" является признаком; "поставить бороздку в указатель петли" - проблема.
    • Когда проблема была создана? Чья деятельность во время разработки была источником проблемы? Было ли это требованием к разработке? Дизайном системы? Кодирования? Тестирования?
    • Когда проблема была локализована? Она могла быть не исправлена сразу же, но что нас действительно волнует – это то, как долго дефект существовал, пока его не обнаружили.
    • Как проблема была найдена? Это может стать практикой, которую вы будете осуществлять постоянно.
    • Когда проблема должна быть обнаружена? Имеется ли процесс контроля качества (Quality Control - QC), который не столь эффективен, как это должно быть?

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

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

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

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

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

    Данные о дефектах, которые является полезными для усовершенствования качества, включают:

    • Что было неправильно? Это - не признак, но проблема, которая должна была быть исправлена. Например: "бесконечная петля" является признаком; "поставить бороздку в указатель петли" - проблема.
    • Когда проблема была создана? Чья деятельность во время разработки была источником проблемы? Было ли это требованием к разработке? Дизайном системы? Кодирования? Тестирования?
    • Когда проблема была локализована? Она могла быть не исправлена сразу же, но что нас действительно волнует – это то, как долго дефект существовал, пока его не обнаружили.
    • Как проблема была найдена? Это может стать практикой, которую вы будете осуществлять постоянно.
    • Когда проблема должна быть обнаружена? Имеется ли процесс контроля качества (Quality Control - QC), который не столь эффективен, как это должно быть?

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

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

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

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

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

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

    Рекомендации по обеспечению качества

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

    1. Исследуйте все процессы, с которыми работает организация. Составьте список всех стандартов и процессов, инструкций, шаблонов и отметьте те, которые нужно доработать или изменить. Так же напишите список того, что нужно добавить в существующий процесс. Каждое планируемое изменение должно быть тщательно продумано и обосновано. (смотрите пункт изменение процессов и процедур для получения более подробной информации)
    2. Устройте митинг с руководителями тех групп, где необходимо что-то изменить. Это очень важно в спокойной обстановке (без нервов) разъяснить то, что надо изменить, что надо убрать и что надо дописать, а главное зачем это надо. Не бойтесь признать, что какие-то изменения, запланированные вами, можно пересмотреть или отказаться от них, вообще, в случае если доводы сотрудников компании перевешивают ваши (возможно вы не очень хорошо обосновали вашу точку зрения или ваше предложение действительно не даст необходимой выгоды). Если вы это сделаете, то можете считать, что вы справились со начальной стадией своей работы.
    3. Все изменения проводите как можно аккуратнее, так как любое неловкое движение может повлечь за собой необратимые последствия. Люди свойственны привыкать к чему либо, поэтому любое изменение может доставить массу неудобств. Поэтому не начинайте менять сразу все, вводите новое постепенно, при необходимости разъясняя сотрудникам компании зачем это надо.
    4. Проверяйте, что предложенные вами изменения выполняются и приносят должный результат. Требуйте от руководителей групп четкого следования процессам, инструкциям, а также использования шаблонов.
    5. Не останавливайтесь на достигнутом. Продолжайте поиск того, что можно улучшить для создания более качественного продукта, на основании новых уже внедренных процессов, стандартов, инструкций, шаблонов.

    Изменение процессов и процедур

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

    1. Упущенное время. Итак, предположим у нас есть коллектив из N человек. У каждого есть некоторое среднее количество процедур k, которые он выполняет ежедневно сам (отчеты о работе, комментарии в код) и некоторое количество процедур l, которые он выполняет коллективно и еженедельно (митинги с командой, всяческие ревью и т.п.). На ежедневные процедуры он тратит t времени в день, а на еженедельные T*N времени (нужно повзаимодействовать с каждым участником). Если взаимодействовать каждому с каждым то это T*((N-1)!), но такое взаимодействие на митингах и в других групповых процедурах редкость (уходит слишком много времени), поэтому остановимся все-таки на оценке T*N. Итого, в неделю коллектив тратит k*5*N*t времени на индивидуальные процедуры и l*T*N*N на коллективные. А в месяц это будет (k*5*N*t + l*T*N*N)*4 (грубая оценка, но на то она и "оценка") или (k*5*t + l*T*N)*N*4. Т.е. в коллективе до 5 человек зависимость скорее линейна, а 5 и более - квадратична (это к вопросу об эффективном размере групп). Простой пример примера: 5 человек, 2 еженедельных митинга по 12 минут на человека, и 0,5 часа ежедневно на отчеты. Получаем (0,5*5*1+0,2*2*5)*5*4 = 90 часов. Неплохо, да? Но это только самое необходимое... для справки среднее количество отработанных сотрудником часов в месяц = 168. Т.е. в коллективе из 5 человек 0,5 человека постоянно занята "процедурами" вместо работы. Не хотите уделить больше внимания тому, чем занимается эта часть?
    2. У меня было еще столько замечательных идей. Кто не слышал от начальника что-то вроде: "Давайте вы в вашей команде будeте делать вот этот маленький отчетик каждый день (выкладывать результаты работы на шару, саппортить документ - нужное подчеркнуть) - это ведь займет у вас всего 5 минут", тот скорее всего сразу начал работать начальником и говорит это сотрудникам сам :) Давайте представим эти "+5 минут". Предположим, что процедура новая (рационально продуманное изменение, как правило, не требует дополнительного времени) - скорее всего уйдет не 5 а 10-15 минут (для оценки используем 15). И в месяц добавит 0,25*5*20=25 часов. Вроде не много - но уже 6 таких "процедур" это +1 непрерывно "процедурящий" сотрудник. Вариант номер 2: "Нам нужны ежедневные командные митинги!". т.е. добавим еще 3 митинга в неделю - 3*4*0,2*5*5=60 и оппа... один человек из 5-ти полностью "процедурит"... причем в этом варианте зависимость от количества человек в коллективе квадратична(!), т.к. нужно больше времени на митинг чтобы услышать каждого (и принять решение), а с другой стороны - больше людей принимают в митингах участие.В коллективе из 10-ти человек это было бы 3*4*0,2*10*10=240 часов.
    3. А как правильно? Собственно, я не хочу сказать, что "процедуры" - это плохо и от них нужно избавляться. Это не так. Более того я считаю что "процедуры" - просто необходимы. Без них проект будет не управляем! Но лучше когда есть необходимость получить новый документ, отчет и т.п. "включить мозг" и оптимизировать уже существующие "процедуры", нежели добавить новых. Чем лучше?
    • Изменение как правило затрагивает уже существующую процедуру, а значит у сотрудников меньше вероятность что-либо забыть, перепутать и т.п.
    • Не потребуется или потребуется меньше дополнительного времени на выполнение (иногда - освободится время, если вы решите что какая-то процедура больше не нужна).
    • Список "процедур" будет всегда актуален - ясно чем занята команда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Источник
    www.protesting.ru

    загрузка...
    Сторінки, близькі за змістом