Created by AIImproved by people
Riqli · living documents · updated continuously
Where AI knowledge meets human practice.
Share with friends
1. Общие положения
1.1. Назначение и область действия документа
Настоящий Регламент тестирования и контроля качества программного обеспечения (далее — «Регламент») устанавливает единые подходы, правила и процедуры для проведения тестирования и контроля качества на всех этапах жизненного цикла разработки программного обеспечения (ПО) в Компании. Регламент обязателен для исполнения всеми разработчиками ПО (Fullstack, Backend, Java, Go, .Net, 1С), инженерами по тестированию, аналитиками и менеджерами проектов, участвующими в процессе разработки и обеспечения качества продуктов.
1.2. Нормативные и правовые основания
Регламент разработан на основе: требований внутренней политики Компании в области управления качеством и ИТ-разработки; лучших отраслевых практик и стандартов в области тестирования ПО, таких как ISTQB (Международный совет по сертификации тестирования ПО), а также стандартов ISO 9001 и ГОСТ Р ИСО/МЭК 12207 в части, касающейся процессов обеспечения качества и тестирования. Настоящий документ является внутренним нормативным актом и имеет приоритет над устными инструкциями в вопросах, регламентированных настоящим Регламентом.
1.3. Основные термины и определения
В настоящем Регламенте используются следующие термины и определения:
- Тестирование ПО — процесс исследования, анализа и оценки программного обеспечения с целью выявления дефектов и обеспечения его соответствия установленным требованиям и ожиданиям заинтересованных сторон.
- Контроль качества (Quality Assurance, QA) — совокупность плановых и систематических мероприятий, направленных на обеспечение уверенности в том, что разрабатываемое ПО соответствует установленным требованиям и стандартам качества на всех этапах разработки.
- Дефект (ошибка, баг) — любое несоответствие фактического поведения или свойств программного продукта его ожидаемому поведению или свойствам, задокументированным в требованиях, спецификациях или иных нормативных документах.
- Валидация — процесс проверки того, что программное обеспечение соответствует реальным потребностям и ожиданиям конечных пользователей и решает поставленные бизнес-задачи.
- Верификация — процесс объективной оценки того, что программное обеспечение или его компонент соответствуют установленным на предыдущих этапах требованиям и спецификациям.
2. Цель и область ответственности
2.1. Миссия роли в процессе тестирования и контроля качества
Основной целью всех участников процесса тестирования и контроля качества в Компании является минимизация рисков поставки конечному пользователю некачественного, нестабильного или не соответствующего требованиям программного продукта. Каждый разработчик ПО (Fullstack, Backend, Java, Go, .Net, 1С) несет прямую персональную ответственность за качество написанного им кода и обязан активно участвовать в процессах обеспечения качества, начиная с этапа проектирования архитектуры и заканчивая поддержкой продукта в эксплуатационной среде.
2.2. Ожидаемые результаты деятельности
Эффективная реализация процессов, описанных в настоящем Регламенте, должна обеспечивать:
- Высокий уровень покрытия кода автотестами (не менее 80% для критических бизнес-логических модулей).
- Снижение количества критических дефектов, попадающих в продуктивную среду, не менее чем на 90% по сравнению с отсутствием регламентированных процессов.
- Сокращение времени на регрессионное тестирование за счет внедрения и поддержания обширной библиотеки автоматизированных тестов.
- Прозрачность состояния качества продукта для всех заинтересованных сторон в любой момент времени.
- Соответствие разрабатываемого ПО требованиям безопасности и производительности, зафиксированным в проектной документации.
3. Подчиненность и иерархия в процессах тестирования
3.1. Структура подчиненности при решении задач качества
В вопросах, касающихся стратегии, методологии и стандартов тестирования и контроля качества, все разработчики и инженеры по тестированию подчиняются руководителю отдела качества (или его заместителю), который осуществляет функциональное руководство. Административно и по оперативным вопросам управления проектами разработчики подчиняются своим прямым руководителям (тимлидам, менеджерам проектов), которые несут ответственность за выполнение командой плановых показателей по качеству.
3.2. Взаимодействие с другими подразделениями
Разработчики взаимодействуют с подразделением эксплуатации и технической поддержки для сбора информации о проблемах, возникающих в продуктивной среде. Взаимодействие с подразделением безопасности осуществляется для согласования и выполнения требований по безопасной разработке и проверке защищенности кода. Управление требованиями и их изменениями осуществляется совместно с бизнес-аналитиками в рамках процесса управления требованиями.
4. Должностные обязанности в области тестирования и качества
4.1. Участие в планировании и проектировании тестов
Разработчик ПО обязан участвовать в планировании мероприятий по тестированию и контролю качества на этапе анализа и проектирования, предоставляя информацию о технической сложности реализации и потенциальных «узких местах» (местах, критичных к производительности или безопасности). Он совместно с аналитиком и инженером по тестированию участвует в написании и рецензировании тест-планов, тест-кейсов и чек-листов для своего компонента или модуля.
4.2. Разработка и поддержка модульных (юнит) тестов
Обязанностью каждого разработчика является написание, выполнение и поддержка модульного тестирования для разрабатываемого им кода. Модульные тесты должны покрывать не менее 80% логики классов и методов, включая все ветвления условий, обработку исключений и граничные случаи. Тесты должны выполняться в рамках непрерывной интеграции (CI) при каждой сборке проекта, и падение любого модульного теста является критическим событием, требующим немедленного исправления до выполнения дальнейших операций с кодом.
4.3. Проведение интеграционного тестирования
Разработчик отвечает за разработку и выполнение сценариев интеграционного тестирования для проверки корректности взаимодействия своего модуля с модулями, разработанными другими членами команды, а также с внешними системами и базами данных. Это включает в себя тестирование API, протоколов обмена данными, асинхронных взаимодействий и корректности работы транзакций в распределенных системах. Результаты интеграционного тестирования должны документироваться, а выявленные проблемы — фиксироваться в системе отслеживания дефектов.
4.4. Подготовка и участие в нагрузочном тестировании
При необходимости, подтвержденной проектной документацией или архитектурным решением, разработчик обязан подготовить тестовые скрипты и данные для проведения нагрузочного тестирования. Он участвует в анализе результатов, выявлении «узких мест» в производительности (медленные запросы к базе данных, неэффективные алгоритмы, проблемы с кешированием, утечки памяти) и предлагает решения по их устранению. Разработчик также отвечает за корректную настройку и интеграцию инструментов профилирования для сбора метрик производительности.
4.5. Участие в приемочном тестировании
Разработчик принимает участие в проведении приемочного тестирования для демонстрации заказчику или ключевым стейкхолдерам готовности разработанного решения. Его задача — разъяснить технические особенности реализации, помочь в проведении тестовых сценариев, а также оперативно исправлять критические дефекты, обнаруженные в ходе этого этапа. Прохождение приемочного тестирования по всем критериям приемки является обязательным условием для передачи релиза в эксплуатацию.
4.6. Управление дефектами и работа с системой отслеживания ошибок
Разработчик обязан строго соблюдать процесс управления дефектами: заводить, комментировать, назначать и контролировать статус дефектов в корпоративной системе отслеживания ошибок (например, Jira, YouTrack, Mantis). Для каждого найденного дефекта он должен предоставить подробное описание шагов воспроизведения, ожидаемый и фактический результат, а также приоритет. Приоритеты дефектов определяются в соответствии с их критичностью для функциональности и бизнеса:
- Критичный (Blocker) — делает невозможным дальнейшее тестирование или использование ключевой функции; исправляется немедленно.
- Высокий (Critical) — функциональность работает с существенными нарушениями; исправляется в первую очередь.
- Средний (Major) — функциональность работает, но с ошибками, не нарушающими основной процесс; исправляется в текущем цикле разработки.
- Низкий (Minor/Trivial) — ошибки пользовательского интерфейса, опечатки, незначительные несоответствия; исправляются по мере возможности.
5. Права работника в области тестирования и контроля качества
5.1. Право на принятие решений
Разработчик имеет право принимать решения о необходимых доработках тестового покрытия в рамках своей зоны ответственности, если это ведет к повышению качества продукта и не требует значительных изменений архитектуры, выходящих за его компетенцию. Он вправе настаивать на выделении дополнительного времени в рамках спринта для устранения технического долга (рефакторинг, переписывание существующих тестов) для обеспечения соответствия критериям приемки по качеству.
5.2. Доступ к ресурсам и информации
Разработчик имеет право запрашивать и получать от менеджмента и всех вовлеченных сторон всю необходимую информацию, техническую документацию, данные и доступ к тестовым средам, инструментам и конфигурациям, которые требуются для выполнения его обязанностей по тестированию и контролю качества. Ему должен быть обеспечен доступ к системам мониторинга и логирования для анализа поведения системы в тестовых и продуктивных средах.
5.3. Право на остановку релиза
В случае обнаружения критического дефекта (Blocker), который делает невозможным выполнение бизнес-функций, является угрозой безопасности данных или приводит к катастрофической потери производительности, разработчик совместно с инженером по тестированию имеет право инициировать процедуру блокировки выпуска релизного кандидата в продуктивную среду до устранения дефекта. Принятие финального решения в этом случае лежит на руководителе отдела качества или менеджере продукта.
6. Ответственность и подотчетность
6.1. Меры дисциплинарной ответственности
За неисполнение или ненадлежащее исполнение обязанностей, предусмотренных настоящим Регламентом, включая, но не ограничиваясь: пропуск критических дефектов в релизе, отсутствие или неактуальность модульных тестов, нарушение сроков исправления дефектов в соответствии с их приоритетами, невыполнение плановых показателей по покрытию кода тестами — разработчик несет дисциплинарную ответственность в соответствии с Трудовым Кодексом РФ и внутренними локальными нормативными актами Компании. Меры могут варьироваться от замечания до выговора и лишения премии.
6.2. Компенсация ущерба
В случае если некачественное тестирование (в том числе пропущенные по вине разработчика дефекты) или отсутствие тестов привели к возникновению прямого материального ущерба для Компании или клиентов, разработчик может быть привлечен к материальной ответственности в порядке и размерах, установленных действующим законодательством РФ. Критерием для привлечения к ответственности является наличие доказанной причинно-следственной связи между нарушением и возникшим ущербом.
7. Квалификационные требования к разработчику для обеспечения качества
7.1. Образование и опыт работы
Для выполнения обязанностей в области тестирования и контроля качества разработчик должен иметь высшее профессиональное образование (предпочтительно в области информационных технологий, математики или физики) или эквивалентный практический опыт. Требуемый стаж работы по специальности — не менее 3 лет для позиций Middle/Senior, включая опыт написания и сопровождения модульных, интеграционных и приемочных тестов для enterprise-решений.
7.2. Профессиональные знания и навыки
Разработчик обязан владеть:
- Глубокими знаниями архитектуры и принципов работы программных систем, в разработке которых он участвует (стек технологий: Java, Go, .Net, 1С, включая фреймворки, библиотеки и инструменты сборки).
- Навыками написания эффективного и поддерживаемого тестового кода с использованием соответствующих фреймворков (например, JUnit/TestNG для Java, go test для Go, NUnit/xUnit для .Net).
- Знанием и умением применять на практике техники тест-дизайна: эквивалентное разбиение, анализ граничных значений, таблицы решений, попарное тестирование.
- Опытом работы с системами непрерывной интеграции (Jenkins, GitLab CI, TeamCity) и пониманием пайплайнов сборки, включающих прогон тестов и статический анализ кода.
- Пониманием принципов безопасной разработки и основных типов уязвимостей (OWASP Top 10) для реализации соответствующих тестов.
- Знанием базовых принципов SQL и навыками написания запросов для проверки целостности данных в тестовых средах.
7.3. Сертификация и повышение квалификации
Настоятельно рекомендуется и поощряется Компанией прохождение разработчиками курсов и получение сертификатов в области тестирования ПО (например, ISTQB Foundation Level, Certified Agile Tester) и безопасной разработки. Разработчик обязан регулярно (не реже одного раза в год) проходить внутреннее или внешнее обучение по новым инструментам и методологиям, связанным с контролем качества, и применять полученные знания в своей повседневной работе.
8. Условия труда для обеспечения процессов тестирования
8.1. Рабочее место и техническое оснащение
Работодатель предоставляет разработчику оборудованное рабочее место, удовлетворяющее требованиям эргономики и санитарно-гигиеническим нормам. Для выполнения обязанностей по тестированию и контролю качества разработчику выделяется персональный компьютер или ноутбук с параметрами, достаточными для запуска всех необходимых тестовых сред, инструментов мониторинга и профилирования. Компания обеспечивает наличие и доступность к тестовым базам данных, серверам приложений и инструментам автоматизации.
8.2. Доступ к информационным системам и документации
Разработчику предоставляется доступ к корпоративной wiki, системам управления проектами и требованиями (например, Confluence, Jira), репозиториям кода (Git, SVN), хранилищам артефактов и инструментам CI/CD для полноценного выполнения всех процессов, описанных в настоящем Регламенте. Критической является возможность доступа к документации, описывающей критерии приемки и функциональные требования для проверки в процессе тестирования.
8.3. Особые условия труда
В периоды интенсивных работ по подготовке релиза, включая этапы нагрузочного и приемочного тестирования, может устанавливаться особый режим рабочего времени, включая ненормированный рабочий день. Данные периоды согласовываются с работником и компенсируются в соответствии с трудовым законодательством и внутренними политиками Компании.
9. Ключевые показатели эффективности (KPI) в области тестирования и качества
9.1. Перечень и расчет KPI
Для оценки эффективности деятельности разработчика в области тестирования и контроля качества устанавливаются следующие количественные и качественные показатели, которые пересматриваются ежеквартально и заносятся в индивидуальный план развития:
- % покрытия кода модульными тестами: Целевое значение — >80% для критических модулей. Измеряется с помощью инструментов статического анализа (например, JaCoCo для Java, cover для Go).
- Плотность дефектов: Количество дефектов, найденных в его коде на этапах интеграционного, системного и приемочного тестирования, в расчете на 1000 строк кода (KLOC). Целевое значение — менее 2 критических/высоких дефектов на KLOC.
- Своевременность исправления дефектов: % дефектов, исправленных в соответствии с установленными сроками (SLAs) в зависимости от приоритета. Целевое значение — 100% для критических и высоких приоритетов.
- Время выполнения регрессионных тестов: Для автоматизированных тестов — время прогона всего набора. Целевое значение — не более 30 минут для бэкенд-части.
- Количество отклоненных баг-репортов: Количество отправленных разработчиком на доработку баг-репортов из-за неполноты или неверного описания. Целевое значение — менее 5% от общего числа.
Все KPI рассчитываются автоматизированным способом на основе данных систем CI, Jira и инструментов статического анализа. Результаты оценки доводятся до сведения работника в рамках регулярных ревью производительности.
10. Бизнес-процессы, чек-листы и сценарии рабочего процесса тестирования
10.1. Жизненный цикл дефекта (процесс управления ошибками)
Процесс управления любым выявленным дефектом строго регламентирован и состоит из следующих этапов, обязательных для исполнения разработчиком:
- Обнаружение и регистрация: Дефект заводится в Jira с заполнением всех обязательных полей (краткое описание, шаги воспроизведения, фактический/ожидаемый результат, среда, приоритет). Статус: «Новый» (New).
- Анализ и назначение: Менеджер проекта или тимлид проводит триаж (Triage), подтверждает дефект, уточняет приоритет и назначает разработчика, ответственного за исправление. Статус: «Принят в работу» (Assigned / To Do).
- Исправление: Разработчик создает ветку в репозитории, пишет код, исправляющий дефект, и добавляет/обновляет соответствующие тесты, которые должны валидировать исправление и предотвращать регресс. Статус: «В работе» (In Progress).
- Code Review и интеграция: Изменения проходят процесс ревью кода (Pull Request). После успешного ревью и прохождения всех CI-проверок (сборка, модульные тесты, статический анализ) изменения мержатся в основную ветку разработки. Статус: «Готово к тестированию» (Ready for QA).
- Верификация: Инженер по тестированию (или сам разработчик, если это предусмотрено процессом) перепроверяет исправление в тестовой среде, выполняет регрессионные тесты и убеждается в отсутствии регресса. Статус: «Закрыт» (Closed), если дефект успешно исправлен и проверен, или «Переоткрыт» (Reopened) с комментариями, если проблема не решена или возникли новые проблемы. В случае переоткрытия, разработчик начинает процесс сначала.
10.2. Чек-лист для модульного тестирования (пример процедуры)
Перед тем как отправить код на ревью, разработчик должен убедиться, что для его изменений выполнены все пункты следующего чек-листа:
- Созданы или обновлены модульные тесты для всех новых методов и измененной логики.
- Тесты покрывают все возможные сценарии: позитивный путь (happy path), негативные сценарии (ошибки, исключения), граничные условия (null, пустые коллекции, макс/мин значения).
- Тесты изолированы и не зависят от внешних систем (баз данных, сети) — используются моки (mock-объекты) и стабы (stubs).
- Имена тестовых методов описывают, что именно они проверяют, следуя шаблону given_when_then.
- Все тесты успешно проходят на локальной машине разработчика в той же конфигурации, что и в CI.
- Время выполнения всех модульных тестов для его модуля не превышает установленного лимита (например, 2 минуты).
- Покрытие кода его изменений составляет не менее 80% (проверено в IDE или отчете JaCoCo/Coverage).
- Отсутствуют закомментированные тесты или тесты с игнорированием (@Ignore, @Disabled).
10.3. Сценарий выполнения интеграционного тестирования
После успешного прохождения этапа модульного тестирования, изменения интегрируются в общий стенд. Разработчик вместе с командой выполняет обязательный сценарий интеграционного тестирования:
- Подготовка среды: Разработчик проверяет, что его изменения были успешно развернуты на интеграционном стенде вместе с изменениями других разработчиков. Проверяет версии зависимостей и состояние миграций базы данных.
- Запуск авто-интеграционных тестов: Выполняется прогон всех автоматизированных интеграционных тестов, которые проверяют взаимодействие между компонентами (REST API, SOAP, очереди сообщений, вызовы БД).
- Ручная проверка ключевых связей: Разработчик вручную выполняет ключевые бизнес-процессы, которые зависят от его модуля: создание заказа, изменение статуса, поиск данных и т.д., проверяя консистентность данных в нескольких связанных системах.
- Анализ логов и ошибок: Разработчик просматривает логи интеграционного стенда на предмет ошибок уровня ERROR и WARN, возникших в его компоненте за время прогона тестов, и анализирует их причины.
- Фиксация результата: В случае успеха, в чек-листе к задаче или в системе Jira ставится соответствующая отметка. В случае неуспеха — задача по дефекту переходит в статус «В работе» для исправления.
10.4. Процедура проведения приемочного тестирования для релизного кандидата
Перед выпуском нового релиза в продуктивную среду проводится обязательное приемочное тестирование, в котором участвует разработчик:
- Подготовка релизного кандидата: Разработчик участвует в сборке и развертывании релизного кандидата на предпродуктивном стенде (Staging).
- Smoke-тестирование: Проводится быстрая дымовая проверка (smoke test) основных критических функций продукта (например, авторизация, создание ключевого объекта, запуск основного процесса) для подтверждения стабильности сборки.
- Выполнение сценариев приемки: Совместно с бизнес-аналитиком и заказчиком (если он участвует) разработчик демонстрирует и проверяет работу продукта по заранее согласованным критериям приемки (Acceptance Criteria), описанным в User Stories. Каждый сценарий маркируется статусом: «Успешно», «Успешно с замечаниями», «Провален».
- Регрессионное тестирование: Запускается полный или выборочный набор регрессионных автотестов для подтверждения, что новый код не сломал существующую функциональность.
- Формирование отчета и подписание акта: Разработчик готовит отчет о результатах приемочного тестирования, включающий список проверенных сценариев и их статусы. Отчет подписывается руководителем отдела качества и/или заказчиком. Акт приемки является основанием для начала процедуры релиза.
10.5. Чек-лист качества перед релизом (обязательный этап)
Перед финальным решением о выпуске релиза, ответственный разработчик (или дежурный по релизу) обязан проверить соответствие продукта следующим критериям приемки, задокументированным в виде чек-листа:
- Code Freeze: Все запланированные на релиз изменения слиты в релизную ветку и код заморожен.
- Автотесты: Все этапы CI для релизной ветки успешно пройдены (сборка, модульные, интеграционные автотесты). Покрытие кода соответствует целевому (>80%).
- Нагрузочное тестирование (если применимо): Проведены тесты производительности и стабильности; система выдерживает пиковые нагрузки (N пользователей, N транзакций в секунду) с допустимым временем отклика. Отчет утвержден.
- Тестирование безопасности: Выполнены обязательные проверки безопасности (статический анализ кода на уязвимости, динамический анализ, проверка зависимостей); критические уязвимости отсутствуют.
- Приемочное тестирование: Все критические сценарии, определенные заказчиком, успешно пройдены. Имеется письменное подтверждение.
- Управление дефектами: Открытых критических и высокоприоритетных дефектов, блокирующих релиз, нет. Для остальных дефектов утверждено решение о переносе или признании их незначительными для данного релиза.
- Документация: Обновлена техническая и пользовательская документация в соответствии с изменениями в релизе.
- Процедура отката: Разработана и протестирована процедура отката релиза в случае возникновения критических проблем в продуктивной среде.