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

Содержание

Обеспечение качества ПО и тестирование: что в них общего и различного?

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

Статья приводит примеры и доводы, которые способны развеять некоторые распространенные заблуждения, касающиеся роли тестирования и обеспечения качества ПО (SQA), а также выработать рекомендации для успеха SQA-команд.

Условия тестирования и обеспечения качества ПО (QA) часто используются в IT-индустрии профессионалами тестирования (часто классифицируемыми как профессионалы по обеспечению качества).

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

Чтобы оценить различия между тестированием и QA, важно сначала понять тесно связанные с ними понятия — контроль качества (QС) и обеспечение качества (QA).

Контроль Качества (QС)  

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

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

Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом, тестирование является неотъемлемой частью контроля качества.

FIGURE 1

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

ISO9000 определяет обеспечение качества ПО как часть менеджмента качества, ориентированную на создание уверенности в том, что требования к устранению багов будут выполнены. Целью QA является обеспечение гарантии того, что продукт будет соответствовать ожиданиям качества заказчика.

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

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

В то время, как QA является активной деятельностью, QC – наоборот, пассивной. Примеры деятельности по обеспечению качества включают установление стандартов и процессов, проверки качества и выбор инструментов.

FIGURE 2

Отличия между обязанностями QA команд и тестировщиков:

Тестировщики выполняют планирование тестирования, анализ результатов испытаний, проверку тестов, проверки и тестирования отчетности через различные уровни испытаний.

В отличие от этого, QA-команды выполняют следующие функции:

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

 Ведут контроль за:

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

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

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

Отличия между планированием испытаний и документацией в тестировании и QA:  

Тестировщики подготавливают тестовые стратегии и планы, основанные на базовых тест-документах, таких как бизнес-требования и проектные решения.

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

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

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

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

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

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

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

Кто выполняет функцию обеспечения качества в организации

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

Некоторые организации имеют функцию QA, встроенную в их предприятия отдельным звеном — Офисом управления проектами. Это отвечает критериям независимости, однако, организации, что следуют этой модели, необходимо убедиться, что эта команда состоит из обученных и/или специализированных аналитиков по обеспечению качества.

Наблюдения и рекомендации для успешных QA-команд

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

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

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

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

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

QA-команде будет намного легче работать с проектными группами, если они держат в уме «пригодный для целей» принцип. Предоставление помощи и содействия проектных команд формирует основу для поддержания хороших отношений, что является важным аспектом успешного тестирования.

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

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

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

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

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

  • Постоянное совершенствование

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

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

Преимущества

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

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

Недостатки

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

Выводы

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

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

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

Источник: http://www.planit.net.au/resource/software-quality-assurance-is-it-the-same-as-testing/

Источник: https://itvdn.com/ru/blog/article/software-quality

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

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

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

Давайте рассмотрим вместе с вами, что представляет собой обеспечение и контроль качества программного обеспечения.

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

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

Обеспечение контроля и качества программного обеспечения определяется в соответствии с различными требованиями в зависимости от особенностей проекта. Основными требованиями, часто определяемыми для любой программы, являются:

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

Обеспечение качества программного обеспечения достигается за счет создания определенных процессов.

Стандарты к разработке программного обеспечения

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

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

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

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

Инструкции с последовательными действиями

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

Опыт предыдущих проектов

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

Предыдущие ошибки

Абсолютно в каждой программе разработчики допускают ошибки.

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

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

Улучшение подходов в разработке и тестированию

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

В заключение

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

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

Источник: http://unetway.com/blog/obespecenie-i-kontrol-kacestva-programmnogo-obespecenia/

Разница между тестированием программного обеспечения и обеспечением качества

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

Попробуем разобраться и понять, в чем состоит существенная разница между тестированием ПО (Testing) и обеспечением его качества (QA).

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

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

И мы потихоньку начали наступать на все грабли начинающего стартапа.

«Разработчики все безответственные… Этот тестировщик неквалифицированный… Я нахожу баги через минуту использования продукта… Да вы кроме чаепитий там вообще что-то делаете?!» – выслушивали мы от директора после каждого релиза. Дальше последовало решение руководства о наборе команды опытных тестировщиков вместе с руководителем отдела. Всё это сопровождалось многочисленными разговорами о том, каким должен быть качественный продукт.

Ребята-тестировщики оказались профессионалами: заводили понятные баги, которые было приятно читать, бесконечно разговаривали с менеджером проекта, выясняя нужные и важные детали поведения продукта.

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

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

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

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

В соответствии с глоссарием ISTQB, Тестирование – это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ, с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. Только вдумайтесь! Оценка продукта и результатов работ… Разве может оценка улучшить качество? Качество же – это способность ПО при заданных условиях удовлетворять установленным или предполагаемым потребностям.

Что делает тестировщик:

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

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

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

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

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

Что делает QA-специалист:

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

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

Что могут сделать тестировщики для улучшения качества продукта

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

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

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

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

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

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

В чем проблема? Разработчики не успевают – их оценка на разработку всегда оказывается на 2-3 дня меньше фактического времени на реализацию. Почему? Допустим, менеджер подбрасывает незапланированные задачи в середине итерации.

Зачем? Заказчик требует – он не видит разницы между разработкой сайта-каталога и сайта-магазина.

Всё, корень проблемы ясен, и можно действовать.

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

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

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

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

Влияние процесса тестирования на качество ПО

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

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

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

Источник: https://quality-lab.ru/the-difference-between-testing-and-quality-assurance/

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

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

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.