Приёмочное тестирование: что это, кто делает и как

Приёмочное тестирование означает как минимум три разные вещи в зависимости от того, кто его проводит и когда. UAT: бизнес-стейкхолдеры подтверждают требования перед финальным одобрением. ATDD: исполняемые тесты написаны до начала разработки. Функциональное приёмочное тестирование: QA проверяет что спецификация полностью реализована. Типичные сбои: слишком поздно начать, привлечь не тех людей, написать критерии достаточно размыто чтобы потом о них спорить.

Что такое приёмочное тестирование

Этот термин охватывает несколько связанных понятий.

На практике «приёмочное тестирование» означает одно из двух: UAT, проводимое бизнес-пользователями, или функциональное приёмочное тестирование, проводимое QA по формальным требованиям.

Критерии приёмки: основа

Приёмочное тестирование начинается с критериев приёмки: конкретных условий которым функция должна соответствовать чтобы считаться готовой.

Плохие критерии приёмки

Страница входа должна нормально работать.

Хорошие критерии приёмки

- Пользователи могут войти с корректным email и паролем и перенаправляются на dashboard

- При неверном email или пароле появляется сообщение «Invalid email or password»

- После 5 неудачных попыток за 10 минут аккаунт блокируется и появляется сообщение «too many attempts»

- Успешный вход создаёт сессию которая истекает через 24 часа неактивности

- Ссылка «Forgot password» на странице входа отправляет письмо для сброса в течение 2 минут

Хорошие критерии: конкретные, проверяемые, однозначные.

Gherkin: критерии в формате Given/When/Then

Gherkin позволяет писать критерии приёмки в формате Given/When/Then. Его читают нетехнические стейкхолдеры, а инструменты вроде Cucumber могут выполнять его как код:

Feature: User Login

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter "user@example.com" as email
    And I enter "ValidPass1" as password
    And I click the "Sign In" button
    Then I should be redirected to the dashboard
    And I should see "Welcome, Test User" in the header

  Scenario: Login with invalid credentials
    Given I am on the login page
    When I enter "user@example.com" as email
    And I enter "WrongPassword" as password
    And I click the "Sign In" button
    Then I should see "Invalid email or password"
    And I should remain on the login page

  Scenario: Account lockout after failed attempts
    Given I am on the login page
    When I enter "user@example.com" with wrong password 5 times
    Then I should see "Too many failed attempts. Try again in 10 minutes."
    And the Sign In button should be disabled

Процесс UAT: шаг за шагом

1. Определи область тестирования

Какие функции входят в этот цикл UAT? Обычно привязывается к релизу или спринту.

2. Напиши сценарии вместе с бизнес-пользователями

Вовлеки реальных пользователей или product owner-ов в написание сценариев. Они знают как выглядит «правильно» с точки зрения бизнеса.

3. Подготовь окружение

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

4. Подготовь тестовые данные

Пользователям нужны реалистичные данные, отражающие их реальные сценарии использования. Не просто «test@test.com» с паролем «test123».

5. Выполни тесты

В идеале тесты прогоняют реальные пользователи. Если нет, QA. Но критерии приёмки должны определять бизнес-стейкхолдеры, а не QA.

6. Задокументируй результаты

Каждый тест получает статус: пройден или нет. По каждому провалу составляется баг-репорт с шагами для воспроизведения.

7. Исправь и перепроверь

Баги найденные в UAT уходят к разработчикам. QA перепроверяет после исправления.

8. Финальное одобрение

Бизнес-стейкхолдеры формально согласовывают релиз. Без согласования не выпускать.

QA-тестирование vs UAT

| Аспект | QA-тестирование | UAT |

|--------|----------------|-----|

| Кто проводит | QA-инженеры | Бизнес-пользователи / product owners |

| Цель | Найти баги | Подтвердить выполнение требований |

| Фокус | Техническая корректность | Бизнес-ценность |

| Когда | В процессе разработки | Перед релизом |

| Критерии | Тест-кейсы | Критерии приёмки |

| Согласование | QA lead | Бизнес-стейкхолдер |

Оба необходимы. QA ловит баги до UAT чтобы бизнес-пользователи не занимались базовым поиском дефектов.

Типичные сбои в приёмочном тестировании

Слишком поздно начали

UAT запланирован за 2 дня до релиза без буфера на исправления. Каждый найденный баг превращается в кризис.

Не те участники

Если UAT проводят разработчики, смысл теряется. Они знают как устроен код и не будут тестировать его как пользователь.

Размытые критерии приёмки

«Checkout должен быть удобным» приводит к спорам о том что такое «удобный» когда находят баги.

Неправильное окружение

UAT на dev-сервере с данными не отражающими реальные объёмы и интеграции пропустит реальные баги.

Нет регрессии после исправлений

Баг найден в UAT, исправлен, задеплоен. Никто не проверяет не сломало ли исправление что-то ещё.

Автоматизированное приёмочное тестирование

Приёмочные тесты можно автоматизировать с Playwright:

// acceptance/login.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Login: Acceptance Criteria', () => {
  test('AC1: Valid credentials redirect to dashboard', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');

    await expect(page).toHaveURL('/dashboard');
    await expect(page.getByTestId('welcome')).toContainText('Welcome');
  });

  test('AC2: Invalid credentials show error message', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'WrongPassword');
    await page.click('[data-testid="submit"]');

    await expect(page.getByTestId('error-message')).toHaveText('Invalid email or password');
    await expect(page).toHaveURL('/login');
  });

  test('AC3: Session expires after 24h inactivity', async ({ page }) => {
    // Обычно тестируется через mock времени или манипуляцию API
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');

    // Симулируем истечение сессии через API
    await page.request.post('/api/auth/expire-session');
    await page.reload();

    await expect(page).toHaveURL('/login');
  });
});

Чеклист приёмочного тестирования

Перед началом UAT:

• [ ] Критерии приёмки написаны и проверены бизнесом
• [ ] Функция задеплоена в UAT-окружение (не в dev или staging)
• [ ] Тестовые данные подготовлены (реалистичные, не упрощённые)
• [ ] Бизнес-пользователи ознакомлены с тем что тестировать
• [ ] Установлен процесс для фиксации багов
• [ ] В расписании есть время на исправления и перепроверку
• [ ] Определён тот, кто даёт финальное одобрение

В процессе UAT:

• [ ] Тесты выполнены по критериям приёмки
• [ ] Все провалы задокументированы с шагами воспроизведения
• [ ] Для сложных проблем есть скриншоты или записи экрана
• [ ] Каждому выявленному дефекту присвоена серьёзность

После UAT:

• [ ] Все баги P1/P2 исправлены и перепроверены
• [ ] Финальное одобрение бизнеса получено письменно
• [ ] В release notes отмечены известные P3/P4 проблемы

Итог

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

• Критерии приёмки пишут бизнес-стейкхолдеры, не QA
• UAT проводят реальные пользователи; функциональное приёмочное тестирование проводит QA по требованиям
• Gherkin (Given/When/Then) делает критерии читаемыми для технических и нетехнических участников
• Запускается в окружении близком к продакшену с реалистичными данными
• Требует формального одобрения перед релизом
• Поддаётся автоматизации с Playwright, что особенно ценно для регрессии при будущих изменениях

Разница между одобрением QA и одобрением бизнеса принципиальна: QA говорит что код работает; бизнес говорит что функция решает их задачу.