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

Составные части аудита качества:

· Текущее качество продукции

· Качество тестирования

· Качество разработки

· Требования к качеству

· Готовность к производству

· Опасные области

· Состояние процессов по проекту

· Автоматизация + Рентабельность инвестиций

· Удовлетворенность клиентов

Когда:

· У вас нет четкой видимости качества программного обеспечения или узких мест в процессе работы

· Рабочая нагрузка вашего проекта увеличивается, но ваш текущий процесс контроля качества не позволяет масштабировать ресурсы

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

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

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

Для чего:

· Изучить, с чего начинается процесс, как он поддерживает развитие и где он эффективно заканчивается

https://habr.com/ru/post/699248/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699248

Когда мы слышим термин "Quality Gates" (QGS), мы склонны думать о них довольно недальновидно на уровне проекта как об этапах и предпосылках для перехода к следующему этапу реализации проекта. На проектах, особенно на тех, которые работают с использованием любой гибкой методологии, часто можно обнаружить что показатели качества более низкого уровня (например, критерии входа и выхода из теста, а также определение Definition of Done) часто обсуждаются/документируются, но затем упускаются из виду или вообще не используются.

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

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

https://habr.com/ru/post/694618/?utm_source=habrahabr&utm_medium=rss&utm_campaign=694618

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

Сегодня мы рассмотрим одну из best practices, которая может помочь в такой ситуации – Quality Gates.

https://habr.com/ru/post/690296/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690296