Лекция
Привет, Вы узнаете о том , что такое обеспечение качества, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое обеспечение качества, качество по, качество программного обеспечения , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
На первый взгляд, « качество по » может показаться абстрактным понятием. Однако для менеджеров проекта, программистов, специалистов по тестированию, QA-инженеров и других участников процесса разработки продукта критерии качества прозрачны и измеримы. Сначала рассмотрим общее определение.
Качество ПО – комплекс характеристик программного продукта, определяющих способность выполнять возложенные на него функции.
В настоящий момент этот показатель регулируется международным стандартом ISO/IEC 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.
Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:
качество программного обеспечения " src="/th/25/blogs/id6118/d3978ac2bba658f7df71ad2a31b7e5a6.png" />
к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Тот же стандарт ISO 9126 [1,2,3,4] дает следующее представление качества.
Различаются понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания добротного ПО существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO 9126, показано на рис. 5.1.
Термины «тестирование» и «обеспечение качества», безусловно, связаны между собой, но не тождественны. В чем же различие?
Обеспечение качества отвечает за весь процесс разработки и интегрируется во все его этапы: от создания требований к будущему решению до тестирования, релиза продукта и его пострелизного обслуживания.
В задачи QA-специалистов входит:
Тестирование – проверка программного обеспечения на соответствие требованиям.
Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.
Тестирование может быть автоматизированным, а может проводиться вручную; может быть полного цикла или направленным на проверку отдельного аспекта качества (безопасность, производительность, удобства использования и т.д.).
Инженеры по тестированию подготавливают стратегии по тестированию и план, основанный на особенностях проекта и требованиям к решению, создают и в будущем оптимизируют набор тест-кейсов, осуществляют поиск дефектов, создают и направляют отчеты об обнаруженных дефектах разработчикам, проверяют устранение дефекта.
Функция обеспечения качества может выполняться внутренним отделом компании, а может делегироваться независимому подрядчику, который объективно оценит само решение, настроит процессы обеспечения качества и тем самым позволит выпустить на рынок продукт высокого качества, отвечающий бизнес-требованиям и ожиданиям пользователей.
Ответы в форме диалога:
Человек из аудитории (А): я бы с удовольствием использовал все то, о чем вы нам рассказали, но я не понимаю, как это можно внедрить в мой QA отдел.
Я: Какова ваша должность?
А: QA аналитик
Я: И что входит в ваши обязанности?
А: Я пишу тест планы и тест кейсы, а также тестирую наш продукт
Я: А какие еще QA должности есть в вашей компании?
А: QA менеджер – он управляет процессом тестирования
Я: Эх… (или что-нибудь в этом духе)
Тогда мне не хватило мужества сказать этому человеку то, что я скажу сейчас: «На самом деле вы не работаете в QA отделе, ваш менеджер им вовсе не руководит, и вообще все то, чем вы занимаетесь, не имеет ничего общего с обеспечением качества».
Тот диалог привел в замешательство моего собеседника и аудиторию в целом, потому что достижение качества становилось чем-то совершенно непонятным. Все QA специалисты, с которыми мне доводилось работать, всегда были нацелены на обеспечение качества, но зачастую все они занимали такие должности, на которых достижение данной цели было невозможно.
Нет, тестирование – это не обеспечение качества
Для того чтобы это объяснить, давайте выйдем за рамки программного обеспечения. В производственном процессе специалисты по тестированию изучают поступающее сырье или берут продукцию прямо со сборочного конвейера и проверяют ее на соответствие стандартам. Об этом говорит сайт https://intellect.icu . И в том и в другом случае, они проверяют продукцию на соответствие документированным спецификациям. Производственные организации называют этот процесс Контролем Качества (QC) и, как вы убедитесь позже, это абсолютно другой вид деятельности в сравнении с Обеспечением Качества
Виды деятельности по Контролю Качества используются либо в процессе производстве продукции, либо после ее изготовления для проверки соответствующего уровня качества. Невозможно осуществлять Контроль Качества того, что не существует. И после того, как продукт готов, у вас есть всего два возможных действия: принять его либо отклонить. Вы уже никак не можете повлиять на качество, вы лишь способны вынести вердикт готовому продукту: либо принять его, либо отослать назад. Еще раз обращаю ваше внимание: вы не можете влиять на качество готового продукта.
Сущность Контроля Качества можно назвать термином «реагирующий», т.е. его задача – проверить на соответствие спецификации после того, как компонент или продукт уже готов; а также принять решение, как с ним поступить. Контроль Качества не обеспечивает качество, он его проверяет.
Нет, Технический Анализ – это не Обеспечение Качества.
Технический анализ осуществляется еще до выпуска продукта, в то время как тестирование происходит в конце процесса разработки. Но Технический Анализ выполняет абсолютно ту же функцию Контроля Качества, что и специалисты по тестированию, проверяющие деталь со сборочного конвейера на соответствие стандартам. Несмотря на то, что сам продукт еще не готов, деталь, которая является его частью, уже проинспектирована и протестирована.
Разбор требований осуществляется до того, как финальная версия спецификации будет готова. Анализ архитектуры планируется тогда, когда архитектура приложения близка к своему финальному состоянию. Анализ дизайна происходит после окончания дизайна компонента. Анализ кода осуществляется после того, как код для компонента был написан. Каждый из этих видов анализа является этапом, на котором необходимо удостовериться, что над продуктом можно продолжать дальнейшую работу.
Технический анализ направлен на то, чтобы выявить дефекты в рабочих продуктах. Он предназначен для Контроля Качества путем проверок на соответствие стандартам, принятия продукта или его отправки на доработку. Технический анализ осуществляется раньше процесса разработки продукта и является важной частью Контроля Качества.
Возвращаясь к фразе: «вы не можете влиять на качество готового продукта» возникает вопрос: а как качество попадает в продукт? Ответ таков: вы должны его туда «внедрить».
В сравнении с Контролем Качества, виды деятельности Обеспечения Качества являются «упреждающими». Контроль Качества «оглядывается назад», чтобы убедиться, что качество соответствует установленным нормам. А Обеспечение Качества осуществляется еще до того, как продукт или компонент был разработан, чтобы убедиться, что конечный продукт будет соответствующего качества.
Почему же я встречаю так много специалистов по обеспечению качества, которые даже не представлюят себе что нужно делать для обеспечения качества продукта? Да потому что они никогда не работали в организации по разработке ПО, которая бы действительно этим занималась. Даже в наши дни очень сложно найти людей, которые бы действительно занимались Обеспечением Качества.
Итак, если бы вы участвовали в процессе Обеспечения Качества ПО, какие бы упреждающие шаги вы бы сделали, чтобы убедиться, что созданный продукт соответствует тем характеристикам качества, которые требовал Заказчик?
Создание организации по обеспечению качества начинается со следующих шагов. Их относительно легко реализовать и они приносят действительно ощутимую пользу:
Если ваша организация уже следует каким-либо из этих шагов, то поздравляю, у вас есть фора. Но чтобы получить максимальную пользу, все же продолжайте читать дальше.
Пол Саймон запросто споет вам песню «50 способов расстаться с любимой», но действительно ли вам нужны 50 разных способов названия переменных? Я обнаружил, что заставить группу разработчиков использовать общие шаблоны и стандарты намного проще, чем кажется. У каждого разработчика есть свой любимый способ выполнения задачи, и практический каждый с радостью согласится обсудить те стандарты, которые он использует.
Общие шаблоны предоставляют всем членам команды важную основу для сотрудничества. Когда каждый человек выполняет задачу своим способом, о сотрудничестве можно забыть. Часто разработчик боится попросить помощи другого человека, потому что он может не согласиться с его подходом. А когда сотрудничества нет, такие различия в подходах могут препятствовать общему пониманию и накоплению знаний и опыта.
Виды деятельности по Контролю Качества (анализ и тестирование) принесут больше пользы и будут более продуктивны, если продукт был сделан, используя общую модель. Без их использования рецензенты и специалисты по тестированию просто будут пытаться отловить проблемы везде, где касалась рука разработчика. Такой бессистемный подход к Контролю Качества требует больше усилий и приводит к плохому покрытию и слабому обнаружению дефектов.
Общие шаблоны также могут способствовать улучшению технической работы. Разработчик, выполняющий задачи своим собственным способом, может с легкостью пропустить важные детали или информацию. Когда работа стандартизирована, не возникает вопросов, что проделанная работа должна в себя включать.
Стандарты должны применяться при написании тест планов, спецификаций, пользовательских интерфейсов, документации, тренинговых материалов и других продуктов, т.к. общее видение того, как проект должен быть сделан, может помочь обеспечить его качество. Но наряду со стандартами, необходимо определить ситуации их использования и разработать руководство по адаптации стандартов под нужды организации, если это необходимо. Любой стандарт, который вы принимаете, должен помочь вам выполнять свою работу как можно лучше и не должен связывать вам руки.
Заметьте, в заголовке не сказано, что вам необходимо использовать стандарты или процессы. Это потому, что каждый из нас уже используют какие-либо установленные процессы для повседневных задач. Хотя у вас наверняка уже и есть какие-либо наработанные процедуры, вы должны сами у себя спросить:
Первый вопрос обращает внимание непосредственно на качество самих процессов. Достигают ли они своей цели? В зависимости от цели вы можете задать такой вопрос: обеспечивают и стимулируют ли они необходимый уровень сотрудничества? Способствуют ли они достаточному взаимодействию между командой разработчиков и заказчиками? Поддерживают ли они лучшие наработки технических стандартов? Помогают ли они достичь целей по качеству?
Зачастую люди недостаточно хорошо знают процессы, которые сами и используют. Например, процессы могут мешать взаимодействию людей, совершенствованию технического мастерства или просто не отвечать нуждам команды. Человек, который говорит «Я никогда не встречал процесса, который был бы мне по душе» скорей всего использовал много хороших процессов, но был просто в них несведущ.
Тем не менее, видимые высококачественные процессы способствуют более плавному течению вещей. Они стимулируют повышение мастерства, позволяя гибко адаптироваться к уникальным нуждам каждого проекта. Другими словами, они отвечают нуждам проектов.
Второй вопрос обращает внимание на качество следования установленным процессам. Если вы выполняете свои задачи ненадлежащим образом и непоследовательно, игнорируя договоренности, то никакой пользы даже от хороших процессов вы не получите. Что означает последовательное использование процессов Обеспечения Качества? Это когда каждый человек четко умеет им следовать, знает, когда и как это делать и строго их соблюдает. Естественно, что такое поведение ожидается от всей команды. «Вот как мы здесь работаем»
Чтобы получить пользу от использования внедренных стандартов и процессов, вы должны постоянно контролировать, что все делается согласно установленной договоренности, и вы получаете именно тот результат, который планировали. Все что регулярно не используется, рано или поздно перестает существовать. Это закон человеческого поведения.
Интегрированная модель зрелости процессов программного обеспечения (CMMI) реализует это при помощи аудитов (CMMI определяет аудит, как вид деятельности по Обеспечению Качества, потому что данная модель тестирует процессы, а не продукт). При использовании аджайл методик (экстремальное программирование, СКРАМ) для этой цели нанимают инструктора. Неважно, как происходит сама проверка и как вы это у себя называете – все это приносит лишь качественную пользу.
Если вы сталкиваетесь с ситуацией, когда принятый стандарт или процесс игнорируется, то необходимо выяснить, почему так происходит, потому что причины могут быть абсолютно разные. Например:
Каждое нарушение стандарта или процесса – это возможность его изучить и улучшить, чтобы он соответствовал нуждам команды.
Вы можете называть это «работа над ошибками», «постпрограмма» или как угодно – но это один из самых мощных инструментов упреждающего улучшения качества вашей работы. Ретроспектива – это отдельно выделяемый отрезок времени, с целью обратить свой взгляд на проделанную работу, изучить полученный опыт и задать себе следующие вопросы: "Что было хорошо и как сделать так же в будущем?" и "Что было не так и как этого можно избежать?"
Несмотря на то, что ретроспективы относят к лучшим практикам, я обнаружил, что используются они крайне редко. Две основные причины этого: «Сложно собрать всю команду на семинар по ретроспективе» и «Мы когда-то это делали, но это не приносило никакой пользы».
Первая причина возникает из-за того, что семинары по ретроспективе происходят в конце разработки проектов. Большинство членов команды уже работают на других проектах, а те, кто остались, заняты релизом проекта или его поддержкой. Аджайл методики решают эту проблему очень просто: не стоит делать всего лишь одну ретроспективу в конце проекта, необходимо делать ретроспективы на всем его протяжении. Преимущества:
Вторая причина непопулярности ретроспектив – очень часто удается собрать много интересной и полезной информации, но нет никакой возможности использовать полученные данные на практике в будущих проектах. (Это обсуждается в главе «Применяйте то, чему научились»).
Информация по дефектам – это просто золотая жила. Это записи о просчетах в качестве, а значит – список возможностей для улучшения качества на ваших будущих проектах. Если вы не документируете дефекты на ваших проектах, тогда сейчас самое время начать это делать. Если вы собираете некую информацию о дефектах (например, после релиза или только на больших проектах), тогда возможно вы захотите улучшить этот процесс.
Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы:
Когда вы анализируете информацию о дефектах, то ищите те дефекты, которые обнаруживаются регулярно, и те, затраты на устранение которых высоки. Вот как раз таких дефектов и нужно избегать в будущем (или по крайней мере устранять их на более ранней стадии разработки), именно такая тактика гарантированно будет способствовать улучшению качества.
Большинство видов деятельности по Обеспечению Качества, о которых я говорил, предоставят вам просто невероятный объем информации о ваших возможностях улучшить качество создаваемого продукта. Но эта информация сама по себе не гарантирует вам желаемого качества. Вы должны особым образом применять на практике все то, чему вы научились. Например, если ваш процесс разработки дизайна неэффективен для использования на определенных видах проектов, то тогда вы должны разработать альтернативный процесс и использовать его на всех будущих проектах такого типа.
На регулярной основе (ежегодно, ежемесячно, ежедневно) рассматривайте новые возможности улучшения ваших стандартов, процессов и методов и вносите необходимые корректировки. Планируйте для этого специальное время и назначайте ответственных людей, иначе данный вид деятельности просто не будет иметь смысла.
В конце концов, в начале разработки нового проекта просто обернитесь назад и извлеките уроки из предыдущих проектов. Просмотрите базу знаний накопленного опыта (LessonsLearned) и историю дефектов, и определите, что должно быть улучшено, основываясь на "уроках" прошлых проектов. Какие действия можно предпринять в этот раз, чтобы обеспечить лучшее качество продукта, чем то, которое было достигнуто до этого? Причем, это нужно делать при старте каждого нового проекта, иначе это будет пропускаться под натиском начала новых проектов.
Если ваша компания реализует что-либо из того, о чем я рассказал, тогда вы уже на пути к организации, действительно осознающей важность качества в процессе разработки ПО. Выделите такие виды деятельности у себя в компании и постоянно улучшайте их для получения пользы.
Если ваша организация все еще не вовлечена в процесс обеспечения качества, тогда у вас есть прекрасная возможность улучшить ситуацию, взяв за основу опыт ваших прошлых проектов. Но прежде чем вы начнете получать выгоду, вы должны осознать, что путь к хорошему качеству подразумевает некоторые затраты вашей компании. Но выбор человека или группы людей, которые будут нести ответственность за обеспечение качества, и делегирование им полномочий на проведение действий, описанных мной выше, полностью оправдывает эти затраты.
Обеспечение качества – это процесс обучения: изучение того, что работает не так и как это исправить; изучение того, что работает правильно и при каких обстоятельствах, а также как делать свою работу лучше с каждым новым проектом.
Любая организация, вовлеченная в процесс Обеспечения Качества, постоянно обучается. Самый первый шаг – это сделать Обеспечение Качества неотъемлемой частью разработки продукта. И тогда «О» действительно будет для вас началом слова «Обеспечение».
Выводы из данной статьи про обеспечение качества указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое обеспечение качества, качество по, качество программного обеспечения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.