> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/engineering-practices/strategiya-kontrolya-kachestva.md). # Стратегия контроля качества > *"If you have a process that produces defects, then you have a defective process."* ### Глоссарий | Термин | Описание | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Сервис | Программа, которую можно развернуть как целостное решение и которая решает четко-определенные задачи одного или нескольких бизнес-доменов. К сервисам относятся также СУБД, брокеры сообщений, хранилища данных и др. софт, выполняющий какие-то действия по запросу. | | Зависимость | Внутренний или внешний сервис | | Внутренний сервис | Программное решение разрабатываемое или поддерживаемое нашей компанией или конкретной ее командой | | Внешний сервис | Программное решение, находящееся за пределами контура компании или зоны ответственности конкретной команды, функциональность, стабильностьность и производительность которого текущая команда не может контролировать | ### Основные принципы * Как команда, мы **разрабатываем продукт** и **решаем проблемы клиентов** * Контроль качества – зона ответственности **всей команды** и **каждого ее члена** * Повлиять на качество можно на **любом этапе** разработки продукта * Чем позже найдена ошибка, чем дороже она нам обходится: самую дорогую цену мы платим за **баги найденные на production**-окружении нашими пользователями, поэтому **стараемся не допускать** таких ситуаций * Мы тесно взаимодействуем с Поддержкой, Продуктом и другими направлениями, чтобы лучше понимать текущие проблемы, сложности пользователей и сам продукт * **Ручное тестирование** является неотъемлемой частью QA. Автоматизация требуется далеко не для каждого продукта. Мы понимаем, где и когда можем экономить время за счет автоматизации – в таких ситуациях предпочитаем такой подход **и авто-тесты.** * Сервисы, которые мы разрабатываем, готовы к развертыванию в локальной, тестовой и других средах с соблюдением приниципов [The Twelve-Factor App](https://12factor.net/ru/) * **Прагматичные подход** позволяет нам эффективнее двигаться вперед: * фокусируемся на критической для бизнеса функциональности и ключевых компонентах * убираем внутреннию бюрократию, устаревшие подходы и соглашения > *I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence \[…]. If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.* > > © Kent Beck Возможно – это все что нам нужно. Это, и люди, которым не все равно. ### Приоритетность в контроле качества От наиболее приоритетных к менее приоритетным: * Явные ошибки в логике ← несоответствие функциональным требованиям * Неожиданное поведение функциональности, которое может приводить к непониманию со стороны пользователей (UX), ошибкам в данных и др. серьезным последствиям * Проблемы с производительностью ← несоответствие нефункциональным требованиям * Неработающий интерфейс – невозможность выполнить необходимые пользователю действия, просмотреть данные, перейти из раздела в раздел * Несущественные ошибки в UI / UX, которые не влияют на функциональность изменений ### Точка старта После того, как `стори` или `задача` передана в производство, т.е. отправлена на доску в To Do, QA-инженеры совместно с командой предоставляют раннюю обратную связь заказчику, задают вопросы или подсвечивают моменты, которые не были указаны в требованиях и описании. На этапе установочных встреч по задаче внутри команды QA помогают определить: * будут ли изменения, предполагаемые в задаче, завтрагиваться при разработке в будущем * сколько ресурсов хочется инвестировать в тестирование * применяемые типы тестирования – ручное и/или авто * кто внутри кросс-функциональной команды что и как тестирует, на каком этапе * есть ли критическая функциональность для которой необходимы E2E-тесты сейчас или позже * необходим ли по итогу регресс ### Жизненный цикл изменений сервиса ```mermaid flowchart LR commit[Коммит] --> sa[Статический анализ] --> test[Тесты] --> build[Сборка] --> push[Публикация] ``` ### Статический анализ кода Несогласованность в стиле кода, ошибки, связанные с типизацией или утвержденными в команде правилами, deprecated warnings, отлавливаются автоматически на этапе статического анализа кода и линтинга за счет внедрения соответствующих инструментов: [.NET source code analysis](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-9), ESLint, etc. Исправление warnings является зоной ответственности разработчиков. Если на этапе статического анализа появляется предупреждение (warning), пайплайн падает ❌ и прогон тестов не выполняется. Разработчики обязаны исправить предупреждение. ### Авто-тесты Авто-тесты – это тоже код, который нужно поддерживать. Как и любой код, он может накапливать технический долг. 100% покрытие авто-тестами – это не показатель, к которому мы стремимся. Для нас важны другие метрики качества и разработки: количество ошибок, проскальзывающих на этапах разработки, повторяющиеся баги, скорость доставки изменений. Тесты, которые мы пишем, должны быть не сложнее тестируемой логики и **отражать намерения пользователя** (“кликнуть третий тег \