Software 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, и делегировать ей власть, чтобы применять те действия, которые я описал.

Гарантия или Обеспечение качества (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» методы рекомендуют легкое решение этой проблемы: Не делайте единичный последующий анализ в конце проекта; делайте последующие анализы регулярно на всём протяжении проекта. Выгоды от этого включают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упущенное время. Итак, предположим у нас есть коллектив из 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 человека постоянно занята «процедурами» вместо работы. Не хотите уделить больше внимания тому, чем занимается эта часть?
У меня было еще столько замечательных идей. Кто не слышал от начальника что-то вроде: «Давайте вы в вашей команде буд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 часов.
А как правильно? Собственно, я не хочу сказать, что «процедуры» — это плохо и от них нужно избавляться. Это не так. Более того я считаю что «процедуры» — просто необходимы. Без них проект будет не управляем! Но лучше когда есть необходимость получить новый документ, отчет и т.п. «включить мозг» и оптимизировать уже существующие «процедуры», нежели добавить новых. Чем лучше?

Изменение как правило затрагивает уже существующую процедуру, а значит у сотрудников меньше вероятность что-либо забыть, перепутать и т.п.
Не потребуется или потребуется меньше дополнительного времени на выполнение (иногда — освободится время, если вы решите что какая-то процедура больше не нужна).
Список «процедур» будет всегда актуален — ясно чем занята команда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обеспечение Качества

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

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	Количество багов по приоритету

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

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

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

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

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

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

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

Что такое качество. Разбираемся в иерархии терминов «QA», «QC» и «тестирование»

Дискуссии вокруг терминологии в IT вечны, хотя по умолчанию считается, что термины отлиты в граните… Трактовка очень сильно зависит от того, кого спрашивать. А вокруг «качества» так много холиваров, что, если начать спрашивать коллег по цеху, что это такое, в ответ можно услышать разные версии: от довольных клиентов или отсутствия багов до абсолютной формальности. Но еще большая чехарда начинается, если спросить, как это качество обеспечить.

Если спросить коллег про обеспечение качества в энтерпрайзе, то с ними проблем обычно нет: тебя быстро посылают в группу обеспечения качества и дальше занимаются своими делами. А вот в не энтерпрайзе (например, в ритейле) начинается интересное. В зависимости от того, кого спрашивать, тебя будут посылать к разным людям, но в большинстве случаев всё сводится к «Не мешай работать, иди к тестировщикам, они вот как раз про качество». Не проблема, сходим.

Ниже результаты моего небольшого исследования, что же такое качество и как его обеспечить, чтобы не слушать в ответ: «Слушай, да что ты докопался, сходи на www.protesting.ru (далее – ПроТестинг), там специально для таких, как ты все написано». Поскольку про него (ПроТестинг) я слышу постоянно, я буду опираться на него.

Основные понятия и определения

Процитирую определения SQ с ПроТестинга:

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

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

Хочу обратить внимание на годы, которые я выделил жирным. Стандарты, откуда взяты определения были выпущены больше 20 (!) лет назад. А что есть сейчас?

Ответ: ГОСТ Р ИСО 9000—2015. Тут у многих возникает реакция «Эм, а номера-то стандартов не бьются!». Верно, рекомендую погуглить самостоятельно и потратить время на изучения того, как менялись номера стандартов и один стандарт поглощал другие.

Вернемся к «Качеству». ГОСТ нам говорит следующее:

Качество (Quality) – степень соответствия совокупности присущих характеристик объекта требованиям.

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

Приведу абзац из этого раздела:

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

Культура ест стратегию на завтрак? Да, но не только. Она «ест» всё, включая качество. Если вы не будете вкладываться в культуру, поощряющее качество, то можете забыть про него. Качество не может жить в отрыве от организации как системы.

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

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

И еще один абзац. Очень важный абзац:

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

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

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

Пойдем дальше и обсудим, что изменилось в определении: Обеспечение качества (Quality Assurance)

С сайта ПроТестинг:

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

Согласно ГОСТ Р ИСО 9000-2015:

Обеспечение качества (Quality Assurance): Часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.

Что мне нравится в определении ГОСТа: ушли от всей многословности про мероприятия, этапы и прочее, а сфокусировались на сути – на обеспечение уверенности. Если задуматься, то это единственное, что вы можете сделать. Гарантировать на 100% нельзя ничего. А как вы будете обеспечивать эту уверенность – напрямую зависит от корпоративной культуры и политики качества.

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

Quality Control – а вот тут начинается самое интересное! Смотрим и сравниваем, верхнее определение взято с ПроТестинга, нижнее из ГОСТа:

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

Управление качеством (Quality control) – часть менеджмента качества, направленная на выполнение требований к качеству.

Внимательные уже заметили, что поменялся перевод. Теперь это управление качеством!

Из нового определения также ушла многословность, и остался фокус на выполнение требований, что, на мой субъективный взгляд, сделало его сильно лучше, в старом варианте. В основном потому что в нем присутствовало «…для получения информации…».

Что потом со всей этой информацией делать не уточнялось… В новом определении четко прописано: надо выполнять требования. Опять же, как вы это будете делать зависит от корпоративной культуры.

Например, политика качества предписывает, что тест кейсы должны быть максимально полные – это обеспечение качества. А управление качеством это:

проверка, что эти тест кейсы полные и достаточные;
проверка, что тестирование по ним выполняется в полном объеме.

Если соотнести определения с циклом Деминга-Шухарта, то обеспечение качества = планирование, часть выполнения и часть корректировки. А управление качеством – это часть выполнения, проверка и часть корректировки.

Теперь мы поговорим о том, что такое тестирование. Ниже даны два определения, первое взято c ПроТестинга, ниже – из ISO/IEC TR 19759:2015, он же SWEBOK.

Тестирование программного обеспечения (Software Testing) – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004].

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

Software testing consists of the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain».

Официальный перевод отсутствует, поэтому ниже я приведу свой перевод. Альтернативные версии пишите в комменты под постом.

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

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

А из всего вышесказанного получается вот такая картинка.

Пример

Про определения можно говорить много, долго и красиво. А как в жизни? Она же сложная, многогранная. Рассмотрим на простом примере, чем отличается тестирование от управления качеством и обеспечения качества.

Дисклеймер: пример, представленный ниже, является полностью вымышленным. Все совпадения случайны.

Знакомьтесь, компания Икс

Компания занимается продажей продуктов, дела у нее все хорошо. Сквозной процесс доставки ценности показан ниже:

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

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

Процесс поставки ценности приобрел следующий вид:

Теперь на выходе два артефакта: дистрибутив и тесты. Но возник вопрос от коллеги из ИБ: что у нас с персональными данными? В дистрибутиве их понятно нет, а в тестах? Как мы соблюдаем 152-ФЗ? А вдруг кто-то использовал свои ФИО или ФИО коллег для тестирования?

Согласно закону фамилия, имя и отчество трактуются как персональные данные. Я понимаю, что юристы тут много что могут сказать, но помните – у нас упрощенный пример.

Понятно, что можно попросить сотрудников подписать документы на передачу ПД, но мы сейчас чуть про другое. Мы рассматриваем кейс как нам обеспечить уверенность в том, что персональных данных в тестах нет. В качестве ПД рассматриваем только фамилию имя и отчество, сильно упрощаем под формат статьи. Что это все означает? В политику качества компании добавлено требование «В поставляемых тестах отсутствуют персональные данные». Реализуем его.

Тестирование

Идем от частного к общему. Подход к тестированию очень простой: нужно проверить, что в наших тестах нет ФИО сотрудников. Хороший тестировщик скажет, что неплохо бы пропустить ФИО через морфер, чтобы получить их в различных падежах.

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

Дешево и быстро. Если нашли ПД, то убрали их в выходном артефакте, и в тестах в системе управления тестированием. Кстати последнее уже больше про QC. Вопросов к такому подходу нет, проверили, молодцы, но выполняются ли требования к качеству? Нет. Например, в компанию устроился новый сотрудник, как он попадет в это список?

Здесь переходим на следующий уровень. Рассматриваем решение нашего кейса уже с точки зрения управления качеством.

Управлением качеством

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

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

Сотрудник поменял ФИО. Всякое бывает;
В компанию пришел новый сотрудник.

Сразу возникает вопрос: почему не обновлять и когда информация удаляется из списка? Ответ на них один – никогда. Информация не удаляется и не обновляется, а только добавляется, таким образом мы гарантируем отсутствие ПД. Лучше, как говорится, перебдеть.

Процесс создания ценности становиться вот таким:

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

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

Обеспечение качества

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

Какие плюсы мы получаем от такого подхода:

Обеспечиваем уверенность, что в созданных для тестирования данных не будет ФИО сотрудников. В самой процедуре реализованы проверки на то, что созданные ФИО отсутствуют в списке ФИО сотрудников;
Гарантируем, что они не будут похожи на «человеческие». Очень хорошая практика + еще одна ступень уверенности. Например, ФИО могут быть созданы в эльфийском стиле;
Гарантируем, что в них будут внедрены сигнатуры для быстрой скриптовой идентификации. Например, в начало и в конец вставлять букву «й»;
Обеспечиваем единую точку поставки тестовых данных;
Всё есть код! Обеспечивается прозрачный контроль над алгоритмом создания тестовых данных;
Приятный бонус: мы можем использовать наши процессы для обеспечения качества кода. Например, любые изменения возможно только после одобрения ИБ запроса на изменение.

Все эти меры обеспечивают нам уверенность в том, что требование «В поставляемых тестах отсутствуют персональные данные» будет выполнено. Но важно понимать, что это никак не отменяет тестирования выходных данных на наличие ПД.

Заключение

Определения не отлиты в граните, они меняются. То, что было справедливо в 1999 году, в 2022 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.

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

Качество программного обеспечения
software quality
гост
качество по
обеспечение качества
quality assurance
управление качеством
quality control
тестирование по
software testing

Блог компании Ростелеком
Тестирование IT-систем
Терминология IT

Software quality assurance что это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обеспечение Качества

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое качество. Разбираемся в иерархии терминов «QA», «QC» и «тестирование»

Основные понятия и определения

Пример

Тестирование

Управлением качеством

Обеспечение качества

Заключение

Добавить комментарий Отменить ответ