QA Catchall

QA покрывает всё! /перевод редакции/

Автор: Alan S. Koch
Перевод с английского: Зиганшин Тагир Рустэмович

Годы назад, я провёл презентацию, которую я назвал “A is for Assurance: A Broad View of SQA.” Она исследовала разнообразие действий, которые являются необходимыми, чтобы фактически ручаться за качество. В течение периода “вопрос и ответ”, я имел следующую беседу:

Участник Презентации: Я бы с удовольствием хотел делать эти вещи, но я не знаю, как реализовать их в моем QA отделе.
Я: Какова ваша роль?
УП: QA аналитик.
Я: И что Вы делаете?
УП: Я разрабатываю тест планы и пишу тест кейсы, и я тестирую нашу продукцию.
Я: И какие ещё есть должности, связанные с качеством, в вашей компании?
УП: QA менеджер, он управляет тестированием.
Я: Вау, серьёзное разнообразие!

Тогда я не сказал участнику презентации того, что я бы сказал ему сегодня: “Вы не работаете в QA отделе, ваш менеджер не отвечает за QA, и вы не имеете никакого отношения к гарантированию качества”.

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

Тестирование это QA?
Нет, тестирование – это не гарантирование качества.

Чтобы получить некоторую ясность, давайте взглянем за программное обеспечение. В производстве тестировщики тестируют поступающие материалы, или они берут компоненты продукта и тестируют допустимое отклонение от нормы. В любом случае, они проверяют, чтобы убедиться, что эти изделия соответствуют написанным спецификациям. Производственные организации называют эту функцию тестирования quality control (QC – контроль качества), и, как я буду утверждать немного позже, это - полностью другой набор действий, чем quality assurance (QA – гарантирование качества).

Quality control деятельность начинается тогда, когда продукт создан, чтобы увидеть, насколько изделие соответствует уровню качества. Вы не можете делать QC над чем-то, пока оно не будет создано. И в таком случае у вас есть только два выбора: принять или отклонить. Вы не можете улучшить качество; вы можете только контролировать то, что уже сделано с продуктом и или разрешить ему двигаться дальше, или отправить назад на доработку. Как обычно указывается, “Вы не можете тестировать качество в продукте”.

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

Являются ли Технические Рецензии QA?
Нет, технические рецензии - не QA.

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

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

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

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

Почему я сталкивался так часто с членами “QA” отделов, которые не могли представить себе, как производить действия гарантии качества? Потому что они никогда не видели организацию разработки программного обеспечения, которая действительно занималась бы QA! Даже сегодня я редко встречаю настоящую QA группу программного обеспечения.

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

При старте QA организации, начните с этих шагов. Они относительно легки в осуществлении и обеспечении настоящих выгод качества:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сохраняйте последующие анализы проекта
Называйте их “изученные уроки”, “постпрограммы” или как угодно; вот некоторые из наиболее мощных инструментов для активного улучшения качества вашей работы. Последующий анализ – это определенное отложенное временное положение, чтобы оглянуться назад на проект и учиться на собственном опыте. Ключевые вопросы: “Что пошло хорошо, и как я могу воспроизвести это в будущем?” и “Что пошло не так, как надо, и как я могу предотвращать это в будущем?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая организация, которая занимается гарантированием качества - организация обучающаяся. Первый шаг – это изучение того, как сделать гарантирование качества неотъемлемой частью того, как вы ведёте свой бизнес. Тогда буква A будет действительно обозначать гарантию (QA).