Раздел: Обеспечение Качества > Статьи специалистов >Понятие Обеспечения Качества

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

Перевод: Алексей Лемешев

Несколько лет назад я делал презентацию, которую назвал «О – значит обеспечение (A is for Assurance): общий взгляд на Обеспечение Качества ПО» (SQA). В презентации рассматривались разнообразные виды деятельности, необходимые для обеспечения качества. По окончании доклада, я отвечал на вопросы из зала, и у меня состоялся следующий диалог:

Человек из аудитории (А): я бы с удовольствием использовал все то, о чем вы нам рассказали, но я не понимаю, как это можно внедрить в мой QA отдел.
Я: Какова ваша должность?
А: QA аналитик
Я: И что входит в ваши обязанности?
А: Я пишу тест планы и тест кейсы, а также тестирую наш продукт
Я: А какие еще QA должности есть в вашей компании?
А: QA менеджер – он управляет процессом тестирования
Я: Эх… (или что-нибудь в этом духе)

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

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

Является ли тестирование обеспечением качества?

Нет, тестирование – это не обеспечение качества

Для того чтобы это объяснить, давайте выйдем за рамки программного обеспечения. В производственном процессе специалисты по тестированию изучают поступающее сырье или берут продукцию прямо со сборочного конвейера и проверяют ее на соответствие стандартам. И в том и в другом случае, они проверяют продукцию на соответствие документированным спецификациям. Производственные организации называют этот процесс Контролем Качества (QC) и, как вы убедитесь позже, это абсолютно другой вид деятельности в сравнении с Обеспечением Качества

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

Сущность Контроля Качества можно назвать термином «реагирующий», т.е. его задача – проверить на соответствие спецификации после того, как компонент или продукт уже готов; а также принять решение, как с ним поступить. Контроль Качества не обеспечивает качество, он его проверяет.

Является ли Технический Анализ Обеспечением Качества?

Нет, Технический Анализ – это не Обеспечение Качества.

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

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

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

Тогда что такое Обеспечение Качества?

Возвращаясь к фразе: «вы не можете влиять на качество готового продукта» возникает вопрос: а как качество попадает в продукт? Ответ таков: вы должны его туда «внедрить».

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

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

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

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

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

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

Договоритесь об использовании общих шаблонов

Пол Саймон запросто споет вам песню «50 способов расстаться с любимой», но действительно ли вам нужны 50 разных способов названия переменных? Я обнаружил, что заставить группу разработчиков использовать общие шаблоны и стандарты намного проще, чем кажется. У каждого разработчика есть свой любимый способ выполнения задачи, и практический каждый с радостью согласится обсудить те стандарты, которые он использует.

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

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

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

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

Определите последовательность действий

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

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

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

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

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

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

Убедитесь, что все следуют установленным стандартам и процессам

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

Интегрированная модель зрелости процессов программного обеспечения (CMMI) реализует это при помощи аудитов (CMMI определяет аудит, как вид деятельности по Обеспечению Качества, потому что данная модель тестирует процессы, а не продукт). При использовании аджайл методик (экстремальное программирование, СКРАМ) для этой цели нанимают инструктора. Неважно, как происходит сама проверка и как вы это у себя называете – всё это приносит лишь качественную пользу.

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

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

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

Используйте опыт прошлых проектов

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

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

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

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

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

Анализируйте информацию о дефектах

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

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

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

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

Применяйте то, чему научились

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

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

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

Начинаем обеспечивать Качество

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

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

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

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

Наверх