Тестировщик / QA
Назад

Пример регламента · Тестировщик / QA

Регламент работы QA-специалиста

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

Паспорт регламента

Код
EXAMPLE-REG-QA
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
QA Lead
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

Цель регламента

Снижать риск дефектов в продакшене через раннюю проверку требований, системный тест-дизайн, понятные bug report и прозрачные критерии готовности.

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • Тестовые данные формируются синтетически или обезличиваются; копирование production-базы допускается только по утвержденной процедуре с ограничением доступа и срока хранения.
  • Скриншоты, видео, логи и сетевые трассы рассматриваются как потенциальные носители персональных данных и коммерческой тайны.

Что проверить до начала работы

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

Зона ответственности

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

Обязанности специалиста

  • Проверять требования на полноту, противоречия, edge cases и тестируемость.
  • Готовить тест-кейсы, чеклисты или тестовые сценарии под риск и сложность задачи.
  • Заводить дефекты с воспроизводимыми шагами, фактическим/ожидаемым результатом, окружением и доказательствами.
  • Проводить регрессию по зонам риска, а не механически по всему продукту.
  • Давать команде понятный статус качества перед релизом.

Рабочий порядок

  1. Изучить задачу, макеты, API-контракты, acceptance criteria и ограничения окружения.
  2. Задать вопросы до начала тестирования, если требование неоднозначно.
  3. Определить тип проверки: smoke, feature, regression, integration, exploratory.
  4. Провести тестирование, зафиксировать дефекты и перепроверить исправления.
  5. Перед релизом подтвердить готовность или явно описать остаточные риски.
  6. После инцидентов обновить тестовые сценарии и регрессионный набор.

Контрольные вопросы специалиста

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

  1. Какой пользовательский и бизнес-риск покрывает проверка?
  2. Какие требования неоднозначны, противоречат макетам, API или законодательным ограничениям?
  3. Можно ли проверить сценарий без production-данных и реальных идентификаторов?
  4. Какие роли и ограничения доступа должны быть проверены негативными сценариями?
  5. Что произойдет при повторной отправке, обрыве связи, просроченной сессии и частичном отказе?
  6. Не раскрывают ли ошибки, логи и интерфейс чужие данные или внутреннюю структуру системы?
  7. Какой дефект блокирует релиз, а какой риск может принять только владелец решения?
  8. Что не проверено и почему это допустимо?
  9. Какие доказательства можно безопасно сохранить в bug report?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Перед вложением в задачу маскировать персональные данные, токены, cookies, Authorization headers и внутренние URL.
  • Тестовые учетные записи не должны повторять реальные пароли и автоматически удаляются либо блокируются после проверки.

Обязательные артефакты

  • QA notes по требованиям.
  • Тест-кейсы или чеклист проверки.
  • Bug report.
  • Regression checklist.
  • Release QA summary.
  • Матрица рисков по функциональности.

Критерии качества

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

Контрольные точки

  • До тестирования требования проверены на тестируемость, противоречия, edge cases и недостающие acceptance criteria.
  • Для критичных сценариев есть чеклист, тест-кейсы или матрица трассировки требований.
  • Bug report содержит шаги, окружение, фактический и ожидаемый результат, доказательства и severity/priority.
  • Перед релизом есть QA verdict: что проверено, что не проверено, какие дефекты и риски остаются.

Антипаттерны

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

Рабочий ритм и периодический контроль

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

Метрики контроля

Дефекты по severityДефекты после релизаПокрытие критичных сценариевВремя перепроверкиДоля возвратов из QAСтабильность регрессии

Коммуникации и эскалация

  • Блокирующие дефекты эскалируются сразу в задаче и в рабочем канале.
  • Перед релизом QA дает короткое заключение: что проверено, что не проверено, какие риски остаются.
  • Спорные требования выносятся на уточнение до начала массового тестирования.

Матрица обязательной эскалации

  • Немедленно: утечка или подозрение на утечку данных, компрометация учетной записи, критическая уязвимость, недоступность ключевого сервиса или риск необратимой потери данных.
  • В течение рабочего дня: нарушение договорного срока, блокирующее противоречие требований, несанкционированное изменение production, юридический или репутационный риск.
  • До продолжения работы: отсутствует владелец решения, правовое основание обработки данных, согласованный критерий приемки либо полномочие на действие.
  • Эскалация содержит факты, влияние, затронутые системы и данные, уже выполненные безопасные действия, варианты решения и время следующего обновления.
  • Блокировать релиз и немедленно уведомлять ответственных при обходе авторизации, доступе к чужим данным, утечке секретов, необратимой порче данных или отсутствии безопасного rollback.

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • QA verdict содержит проверенные версии и окружения, покрытые сценарии, открытые дефекты, непроверенные области и имя лица, принявшего остаточный риск.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Доказательства дефекта хранить не дольше рабочей необходимости; после закрытия удалять локальные дампы, HAR-файлы и записи экранов с данными.

Нормативная основа и официальные материалы

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