Обеспечение качества — основные понятия и определения
ADO в Delphi AJAX Android C++ CakePHP CMS COM CSS Delphi Flash Flex HTML Internet Java JavaScript MySQL PHP RIA SCORM Silverlight SQL UML XML Бази даних Веб-розробка Генетичні алгоритми ГІС Гітара Дизайн Економіка Інтелектуальні СДН Колір Масаж Математика Медицина Музика Нечітка логіка ООП Патерни Подання знань Розкрутка сайту, SEO САПР Сесії в PHP Системне програмування Системний аналіз Тестологія Тестування ПЗ Фреймворки Штучний інтелект
|
Обеспечение качества — основные понятия и определенияКачество программного обеспечения (Software Quality)
Обеспечение качества (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 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.Характеристики качества ПО
С чего начать обеспечение качества?Если ваша организация делает некоторые из вещей, о которых я говорил, то вы уже на вашем пути к становлению осознающей качество организации. Изучите те QA действия, которые вам нужны, и развивайте их применение там, где имеется возможность для выгоды. Если ваша организация еще не занимается действительно гарантированием качества, то вы имеете существенные возможности улучшить это с помощью ваших выполненных прошлых проектов. Но прежде, чем вы сможете получить любые выгоды, вы должны объяснить вашей организации её затраты из-за низкого качества. Вооруженная этими данными о расходах, ваша организация может установить человека или группу, которая будет ответственна за QA, и делегировать ей власть, чтобы применять те действия, которые я описал. Гарантия или Обеспечение качества (Quality Assurance) – это главным образом процесс изучения: изучения того, что работает плохо, и что вы можете сделать относительно этого; изучения того, что работает, окружения, в котором оно работает, и применения этого как установившейся практики; и изучения того, как работать лучше с каждым проектом, который вы берёте на свою ответственность. Создание и Использование ШаблоновДействительно ли вы нуждаетесь в пятидесяти способах назвать ваши переменные? Получение согласия группы разработчиков на использованию шаблонов или моделей (стандартов) сделать легче, чем это звучит. У каждого разработчика есть свой любимый способ делать любую работу, и большинство разработчиков приветствуют возможность обсудить стандарты, которые они используют. Общие шаблоны обеспечивают членов команды важным основанием, чтобы сотрудничать. Когда каждый подходит к определенной задаче различным способом, сотрудничество в лучшем случае затруднено. Разработчик может смущаться привлекать других, если он ожидает, что другой человек может не согласиться с его подходом. И когда сотрудничество достигается, эти различия могут препятствовать пониманию и извлечению выгоды из знаний и опыта друг друга. Действия по контролю качества (Quality Control), такие как рецензии и тестирование, могли бы быть лучше сфокусированы и более продуктивны, если изделие было бы построено, используя согласованные шаблоны. Без них, рецензенты и тестировщики должны пробовать найти баги в чём угодно, что разработчик мог сделать. Такой неорганизованный подход к контролю качества требует больших усилий и кончается меньшим охватом и более низким результатом обнаружения дефектов. Шаблоны также могут подтолкнуть лучшую техническую работу. Разработчик, который делает работу своим собственным способом, может легко пропускать важные шаги или просмотреть важную информацию. С имеющимся стандартом для работы, не имеется никаких вопросов относительно того, как должна выглядеть законченная работа, и что она должна в себя включать. Вы должны рассмотреть стандарты для планов, спецификаций, кода, интерфейсов пользователя, документов, руководств (обучающих материалов), и любой другой компонент работы, потому что согласие о том, как проект должен быть сделан, может помочь гарантировать его качество. Но наряду со стандартами, вы должны идентифицировать состояния, в которых они могут использоваться и обеспечить руководством для их воспроизведения, когда необходимо. Любой стандарт, с которым вы соглашаетесь, должен помочь вам выполнять работу наилучшим способом и не должен мешать ей. Создание ИнструкцийЗаметьте, что заголовок не говорит, что вы должны использовать инструкции или процессы. Это потому что каждый использует процессы для вещей, которые делает регулярно. Ваш отдел уже имеет инструкции по созданию программного обеспечения. Вот два главных вопроса, которые вы должны спросить сами себя относительно этих инструкций:
Первый вопрос сосредотачивается непосредственно на качество инструкций. Подходят ли они для их целей? В зависимости от цели, вы можете задать следующие вопросы: Поддерживают и поощряют ли они уровень сотрудничества, в котором вы нуждаетесь? Продвигают ли они достаточный обмен между командой разработчиков и клиентами? Поддерживают ли они использование лучших технических стандартов? Помогают ли они вам достичь ваших целей качества? Часто, когда люди знают свои процессы, это потому, что они глубоко понимают их. Например, процессы могут идти по пути сотрудничества, технического превосходства, или отношений заинтересованных сторон, или некоторым другим способом будут не в состоянии выполнять потребности команды. Человек, который говорит “Я никогда не встречал процесс, который бы мне нравился”, вероятно, использовал много хороших процессов, но не понимал их. В то время как высококачественные процессы не всегда невидимы, они заставляют выполнять работу более гладко. Они способствуют превосходству при обеспечении гибкости, чтобы приспособиться к уникальным требованиям каждого проекта. Короче говоря, они поддерживают потребности ваших проектов. Второй вопрос сосредотачивается на качестве вашего выполнения этих инструкций. Если вы не уместно и не последовательно делаете вещи, с которыми вы согласились, то выгоды от хороших процессов, вероятно, будут потеряны. Последовательное использование высококачественных процессов - вопрос уверенности в том, что каждый человек знает, когда и как следовать им и строгое соблюдение этих инструкций - ожидаемый результат для команды. “Это - то, как мы делаем вещи здесь”. Использование Стандартов и ПроцессовЧтобы извлекать полную выгоду из стандартов и процессов, которые вы устанавливаете, необходимо непрерывно проверять, что вы получаете предполагаемый результат. Поведения, которые регулярно не укрепляются, в конечном счете, угасают. Это особенность человеческой природы. Модель CMMI (Capability Maturity Model Integration) делает это через проверку процессов. (CMMI классифицирует эти проверки как обеспечение качества, потому что они проверяют процесс больше, чем продукт.) Гибкие технологии программирования (например, Экстремальное Программирование - Extreme Programming или XP) используют для этого метод коучинга (coaching). Независимо от того, как эта проверка сделана или как она называется, она заканчивается выгодами качества. Если вы обнаруживаете случай, где принятый стандарт или процесс игнорировались, это заслуживает расследования и разрешения, потому что для этого может быть множество причин. Например: Каждое "нарушение" стандарта или процесса – это возможность изучить и улучшать его так, чтобы он лучше соответствовал потребностям команды. Анализ выполненных проектовИзученные уроки (Lessons Learned), постпрограммы (Post Programs or Post Project Analysis) - вот некоторые из наиболее мощных инструментов для активного улучшения качества вашей работы. Последующий анализ – это момент, чтобы оглянуться назад на проект и попытаться научиться на собственном опыте. Ключевые вопросы: “Что пошло хорошо, и как я могу воспроизвести это в будущем?” и “Что пошло не так как надо, и как я могу предотвращать это в будущем?” Хотя последующие анализы широко признаны как “лучшая практика” (Best Practise) мы убедились в том, что они довольно редки. Две наиболее часто высказываемые причины для этого: “Трудно собрать всех вместе для обсуждения и последующего анилиза проекта” и ” Мы делали это, но это никогда не имело никакого эффекта”. Первая причина возникает, потому что собрания по последующим анализам проводятся в конце проектов. Многие из участников проекта перешли, и те, кто остались, заняты делом выпуска продукта и начальной поддержкой. "Agile" методы рекомендуют легкое решение этой проблемы: Не делайте единичный последующий анализ в конце проекта; делайте последующие анализы регулярно на всём протяжении проекта. Выгоды от этого включают:
Вторая причина, почему последующие анализы имеют тенденцию быть редкими – это то, что вы часто собираете много интересной практической информации, но у вас нет возможности использовать эту информацию в работе над будущими проектами. (Я предлагаю “Применяйте то, что вы изучили”.) Использование Данных ДефектаВаша база дефектов – это запись всех найденных упущений в качестве, анализ которых необходим для улучшения качества ваших будущих проектов. Если вы не документируете дефекты в ваших изделиях, то сегодня - хорошее время, чтобы начать. Если вы собираете некоторые данные о дефектах (например, только после выпуска или только на “больших” или только на поздних стадиях разработки), то вы можете захотеть расширить то, что вы собираете. Данные о дефектах, которые является полезными для усовершенствования качества, включают:
Сколько это стоило? Легко выполнить общий подсчёт. Убедитесь, что обдумали всю проверку и доработку, которую вы должны сделать, включая повторное проектирование, повторное кодирование, повторную сборку, восстановление, переделывание тестов, повторное тестирование, повторный выпуск, выпуск заплаток, управление сообщения о дефекте, статусом сообщения и т.д. Какая это была проблема? Когда у вас больше, чем несколько десятков дефектов, тогда распределение дефектов по категориям облегчает анализ и изучение. Когда вы анализируете ваши данные о дефектах, уделяйте больше внимания тем, которые случаются последовательно и которые имеют высокие затраты на исправление. Они - те, которых вы хотите избежать в будущем (или, по крайней мере, обнаружить раньше в процессе разработки), потому что это будет самым большим усовершенствованием качества. Используйте полученные знанияВаша база дефектов – это запись всех найденных упущений в качестве, анализ которых необходим для улучшения качества ваших будущих проектов. Если вы не документируете дефекты в ваших изделиях, то сегодня - хорошее время, чтобы начать. Если вы собираете некоторые данные о дефектах (например, только после выпуска или только на “больших” или только на поздних стадиях разработки), то вы можете захотеть расширить то, что вы собираете. Данные о дефектах, которые является полезными для усовершенствования качества, включают:
Сколько это стоило? Легко выполнить общий подсчёт. Убедитесь, что обдумали всю проверку и доработку, которую вы должны сделать, включая повторное проектирование, повторное кодирование, повторную сборку, восстановление, переделывание тестов, повторное тестирование, повторный выпуск, выпуск заплаток, управление сообщения о дефекте, статусом сообщения и т.д. Какая это была проблема? Когда у вас больше, чем несколько десятков дефектов, тогда распределение дефектов по категориям облегчает анализ и изучение. Когда вы анализируете ваши данные о дефектах, уделяйте больше внимания тем, которые случаются последовательно и которые имеют высокие затраты на исправление. Они - те, которых вы хотите избежать в будущем (или, по крайней мере, обнаружить раньше в процессе разработки), потому что это будет самым большим усовершенствованием качества. Используйте полученные знанияМногие действия по обеспечению качества (QA), обеспечат вас огромным резервом информации относительно ваших возможностей для улучшения качества того, что вы строите. Но одна эта информация не будет гарантировать качество любого будущего продукта. Вы должны использовать определенные действия, чтобы применить эти знания. Например, если ваш процесс проектирования слишком неудобен, чтобы использоваться эффективно для определенных типов проектов, то вы должны разработать альтернативный процесс и использовать его для всех будущих проектов данного типа. На регулярном основании (например, ежегодно, ежемесячно, ежедневно), останавливайтесь и определяйте ваши возможности для усовершенствования, затем вносите изменения в ваши стандарты, процессы, и методы, чтобы включить эти усовершенствования. Если это специально не запланировано и сделано, чьей-либо обязанностью, эта деятельность не будет реализована.В конечном счете, ваш процесс проектных нововведений должен включать шаги, чтобы учиться от предшествующих проектов. Смотрите на вашу базу данных последующих анализов и ваши отчёты о дефектах, чтобы определить, как этот проект должен работать в отличие от прошлых проектов. Какие действия вы можете использовать на сей раз, чтобы обеспечить (гарантировать) лучшее качество, чем было достигнуто прежде? Снова, это должна быть явная задача в течение проектных нововведений, или это будет пропускаться под натиском появления каждого нового проекта. Рекомендации по обеспечению качестваВы обязаны помнить, что обеспечение качества - это не тестирование, и оно не направлено на изменение только процесса тестирования. Вы должны понимать, что это понятие охватывающее все технологические этапы разработки, выпуска и эксплуатации программного обеспечения информационных систем, предпринимаемых на разных стадиях жизненного цикла, для обеспечения качества выпускаемого продукта. Поэтому любое неудачное изменение может повлиять на качество конечного продукта. Исходя из этого я предлагаю Вам следующий план проведения мероприятий по обеспечению качества:
Изменение процессов и процедурВ данной статье речь пойдет не совсем о тестировании, а точнее совсем не о тестировании, а скорее об организации любой работы в принципе. Не секрет, что в ходе разработки любого проекта в проектной команде существуют (иногда формируются произвольно, но чаще навязываются сверху) некоторые "процедуры" - это правила составления отчетов о работе, написания комментариев в код, документации, создания описаний по настройке продакшн систем, инсталляций продуктов (да, не все инсталляции интуитивно понятны. Если вы не сталкивались с такими продуктами, для инсталляции которых нужно читать доки - считайте вам повезло). У любых "процедур" помимо прямого положительного есть еще и побочное отрицательное действие - поглощение времени, которое можно было бы потратить на выполнение других задач. Собственно целью этой статьи является оценка времени, которое проектная команда теряет на выполнение таких "процедур" и некоторые выводы, которые из этого следуют.
Естественно, единого "правильного" рецепта для всех - нет. Здесь есть только некоторые грубые оценки затрат времени на рутинные задачи, не связанные напрямую с производством конечного продукта или услуги. И всегда полезно представлять "обратную сторону медали" Метрики по обеспечению качестваСогласно международному стандарту ISO 14598: Метрика - это количественный масштаб и метод, который может использоваться для измерения. От себя добавим, что введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования, который мы и будем рассматривать далее. Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования. Необходимую для контроля информацию собирают (как в ручную так и автоматически) и используют для оценки состояния и принятия решений, таких как покрытие (например, покрытие требований или кода тестами) или критерии выхода (например, критерии окончания тестирования). Метрики, так же могут быть использованы для оценки прогресса выполнения запланированных работ и освоению бюджета Создание, использование и анализ метрикНа наш взгляд, для большей наглядности имеет смысл сгруппировать метрики по типам сущностей, участвующих в обеспечении качества и тестировании программного обеспечения, а именно:
Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели. Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования. Пример первый: Допустим, мы имеем ситуацию, когда количество переоткрываемых после починки багов не уменьшается или даже растет. Это является сигналом к тому, что необходимо провести анализ причин, т.к. подобная ситуация может показать, что:
Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs": Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:
Все эти проблемы заметно дестабилизируют обстановку на проекте. Поэтому, при их возникновении, рекомендуется провести короткую беседу с руководителями проектных групп, чтобы в последствии уменьшить количество переоткрытых и отклоненных дефектов. Метрики по задачам могут разные, мы привели лишь 2 из них. Так же интересна может быть метрика по времени выполнения задач и многие другие. В заключении хотим отметить, что наличие необходимых метрик и графиков, отражающих изменение состояния проекта в течении времени, позволит вам улучшить не только процесс тестирования, но и разработки в целом, а также облегчит процедуру проведения анализа выполненного проекта, что позволит в дальнейшем не допускать прошлых ошибок. Источник
www.protesting.ru Зверніть увагу на додаткові посиланняЯкщо вас цікавить...Головний розділзагрузка...
|
Сторінки, близькі за змістом
|
Copyright © 2008—2024 Портал Знань.
При використанні матеріалів посилання, для інтернет-ресурсів — гіперпосилання, на Znannya.org обов'язкове.
Зв'язок
|
НТУУ "КПІ" Інженерія програмного забезпечення КПІ Лабораторія СЕТ |
|