Как управлять качеством IT-проекта?

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

Управление качеством строится вокруг нескольких процессов: контроль требований → проверка разработки → code review → тестирование → управление дефектами → регрессионное тестирование → приемка → контроль качества релиза.

Что именно контролируют в IT-проекте

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

Объект контроля	Что проверяют
Требования	Полнота, однозначность, согласованность и проверяемость
Разработка	Соответствие реализации требованиям и техническим решениям
Код	Code review, архитектурные и технические ошибки
Функциональность	Работа предусмотренных сценариев
Интеграции	Корректность обмена данными между системами
Безопасность	Соблюдение установленных требований безопасности
Производительность	Соответствие заданным показателям нагрузки и скорости
Пользовательские сценарии	Возможность выполнить реальные рабочие операции
Релиз	Готовность функциональности к передаче пользователям

Главный принцип — качество нельзя полностью проверить в конце проекта. Чем раньше обнаружена проблема, тем меньше стоимость и влияние ее исправления.

Definition of Done

Definition of Done (DoD) — заранее согласованный набор условий, при выполнении которых задача считается завершенной.

Например, для разработки новой функции Definition of Done может включать:

• код реализован;
• code review завершен;
• автоматические проверки пройдены;
• функциональность протестирована;
• критические дефекты отсутствуют;
• критерии приемки выполнены;
• документация обновлена, если она затрагивается изменением;
• результат готов к передаче на следующий этап.

DoD помогает отделить «разработчик закончил писать код» от «задача действительно готова».

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

Критерии приемки

Критерии приемки позволяют объективно определить, соответствует ли реализованная функция требованиям.

Например, для функции восстановления пароля критериями могут быть:

1. пользователь может запросить восстановление;
2. система отправляет ссылку на зарегистрированный адрес;
3. ссылка имеет ограниченный срок действия;
4. пользователь может установить новый пароль;
5. после изменения пароля старый пароль больше не принимается.

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

QA и тестирование

QA (Quality Assurance) — обеспечение качества, то есть организация процессов, которые помогают предотвращать дефекты и обеспечивать соответствие результата установленным требованиям.

Тестирование — один из инструментов QA. Оно позволяет обнаружить несоответствия между фактическим поведением системы и ожидаемым результатом.

В зависимости от проекта проверяют:

• функциональность;
• интеграции;
• пользовательские сценарии;
• производительность;
• безопасность;
• совместимость;
• регрессионные сценарии.

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

Code review

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

В ходе проверки могут оцениваться:

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

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

Управление дефектами

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

Минимальный цикл выглядит так:

обнаружение → регистрация → классификация → приоритизация → исправление → повторная проверка → закрытие.

Для дефекта важно указать:

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

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

Регрессионное тестирование

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

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

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

Как определить готовность релиза

Релиз нельзя считать готовым только потому, что все запланированные задачи имеют статус «выполнено».

Перед выпуском необходимо проверить:

• выполнены ли критерии приемки;
• завершено ли необходимое тестирование;
• закрыты ли критические и блокирующие дефекты;
• пройден ли регресс;
• готовы ли необходимые интеграции;
• обновлена ли документация;
• подготовлены ли пользователи к изменениям;
• выполнены ли условия Definition of Done;
• согласован ли выпуск ответственными участниками.

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

Качество как часть управления проектом

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

Практичный контроль можно построить по цепочке:

Требование → критерии приемки → задача → разработка → code review → тестирование → дефекты → регресс → приемка → релиз.

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

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

Минимальный чек-лист качества перед релизом

• Требования согласованы.
• Критерии приемки выполнены.
• Definition of Done выполнен.
• Code review завершен.
• Основные тесты пройдены.
• Регресс выполнен в необходимом объеме.
• Критические и блокирующие дефекты устранены.
• Интеграции проверены.
• Необходимая документация обновлена.
• Релиз соответствует установленным критериям готовности.