Agile-квадранты тестирования

Updated Jul 2026

Фреймворк

Agile-квадранты тестирования Брайана Марика организуют тестовые активности по двум измерениям: бизнес-ориентированные vs технологически-ориентированные и поддерживающие команду vs критикующие продукт. Квадранты помогают команде убедиться, что она инвестирует во все типы тестирования, а не только в те, которые легче всего автоматизировать.

                    Бизнес-ориентированные
                         |
    Q2: Функциональные|  Q3: Исследовательское
    тесты, тесты      |  тестирование, тестирование
    историй, прототипы |  юзабилити, UAT,
    (Поддержка         |  альфа/бета-тестирование
     команды)          |  (Критика
                       |   продукта)
    -------------------+------------------
    Q1: Юнит-тесты,   |  Q4: Тестирование
    компонентные тесты,|  производительности,
    интеграционные     |  безопасности,
    тесты              |  нагрузочное
    (Поддержка         |  тестирование
     команды)          |  (Критика
                       |   продукта)
                         |
                    Технологически-ориентированные

Квадрант 1: Юнит и интеграционные тесты (технологически-ориентированные, поддержка команды)

Что включает

Юнит-тесты
Компонентные тесты
Интеграционные тесты
API-тесты

Характеристики

Полностью автоматизированы: без ручного выполнения
Запускаются непрерывно: при каждом push и PR
Управляются разработчиками: пишутся преимущественно разработчиками, ревьюируются QA
Быстрая обратная связь: результаты за секунды или минуты

Роль QA в Q1

Ревьюировать тесты разработчиков на пробелы покрытия
Обеспечивать покрытие интеграционными тестами контрактов API и взаимодействий с базой данных
Мониторить надёжность тестов (уровень нестабильности)
Продвигать адекватное покрытие юнит-тестами в DoD

Пример

// Юнит-тест (Q1)
test('calculateTotal applies 10% discount for orders over $100', () => {
  const items = [{ price: 60 }, { price: 50 }];
  expect(calculateTotal(items)).toBe(99); // $110 - 10% = $99
});

// Интеграционный тест (Q1)
test('POST /api/orders creates order in database', async () => {
  const response = await request(app)
    .post('/api/orders')
    .send({ items: [{ productId: 1, quantity: 2 }] });
  expect(response.status).toBe(201);
  expect(response.body.orderId).toBeDefined();
});

Квадрант 2: Функциональные и тесты историй (бизнес-ориентированные, поддержка команды)

Что включает

Функциональные тесты (проверка критериев приёмки)
Тесты историй (автоматизация пользовательских историй)
Прототипы и макеты для верификации
BDD-сценарии (Given/When/Then)

Характеристики

В основном автоматизированы: автоматизированы где возможно, с некоторой ручной верификацией
Запускаются на PR и слияниях: контроль кода до попадания в main
Управляются QA: пишутся преимущественно QA-инженерами
Бизнес-язык: тесты выражают бизнес-правила, а не технические детали

Роль QA в Q2

Писать и поддерживать функциональные тестовые наборы
Переводить критерии приёмки в автоматизированные тесты
Верифицировать соответствие фич бизнес-требованиям
Сотрудничать с PO для определения ожидаемого поведения

Пример

// Функциональный тест (Q2) -- написан бизнес-терминами
test('user can complete checkout with a valid coupon', async ({ page }) => {
  await page.goto('/products');
  await page.click('[data-testid="add-to-cart-premium-plan"]');
  await page.click('[data-testid="go-to-checkout"]');
  await page.fill('[data-testid="coupon-input"]', 'SAVE20');
  await page.click('[data-testid="apply-coupon"]');
  await expect(page.locator('[data-testid="discount"]')).toHaveText('-$20.00');
  await page.click('[data-testid="complete-purchase"]');
  await expect(page).toHaveURL('/order-confirmation');
});

# BDD-сценарий (Q2)
Scenario: Apply valid coupon at checkout
  Given I have a product in my cart
  When I enter coupon code "SAVE20"
  And I click "Apply"
  Then I should see a $20 discount
  And the total should reflect the discount

Квадрант 3: Исследовательское и юзабилити-тестирование (бизнес-ориентированное, критика продукта)

Что включает

Исследовательское тестирование (креативное, неструктурированное расследование)
Юзабилити-тестирование (удобно ли использовать?)
Пользовательское приёмочное тестирование (UAT)
Альфа- и бета-тестирование
Тестирование доступности (ручной обзор)

Характеристики

Ручное по дизайну: автоматизация не может заменить человеческую креативность и суждение
Непрерывно в течение спринта: не только в конце
Управляется QA и пользователями: QA исследует, пользователи валидируют
Находит неизвестные неизвестные: обнаруживает проблемы, о которых никто не подумал при написании теста

Роль QA в Q3

Проводить структурированные сессии исследовательского тестирования
Выявлять проблемы юзабилити, которые автоматизированные тесты пропускают
Координировать UAT с бизнес-заинтересованными сторонами
Тестировать граничные случаи, восстановление после ошибок и необычные пользовательские пути

Структура сессии исследовательского тестирования

Хартия сессии: "Исследовать новый поток оформления заказа с фокусом на восстановление после ошибок"
Длительность: 60 минут
Области фокуса:
  - Что происходит при сбое оплаты?
  - Что происходит при уходе пользователя в середине оформления?
  - Что происходит при медленной сети?
  - Что происходит при истечении сессии во время оформления?

Находки:
  - Баг: Кнопка "Назад" после сбоя оплаты показывает пустую корзину (SHOP-891)
  - Баг: Нет сообщения о таймауте при медленном ответе платёжного API (SHOP-892)
  - Наблюдение: Сообщения об ошибках используют технический язык ("HTTP 500") вместо понятного пользователю
  - Предложение: Добавить индикатор прогресса во время обработки платежа

Почему Q3 нельзя автоматизировать

Автоматизированные тесты проверяют известное, ожидаемое поведение. Исследовательское тестирование обнаруживает неизвестное, неожиданное поведение. Робот не подумает «а что если я вставлю email-адрес в поле телефонного номера?» и не заметит, что кнопка оформления заказа едва видна на тёмном фоне. Человеческая интуиция и креативность незаменимы в Q3.

Квадрант 4: Тестирование производительности, безопасности и нагрузки (технологически-ориентированное, критика продукта)

Что включает

Тестирование производительности (время отклика, пропускная способность)
Нагрузочное тестирование (поведение при большом трафике)
Стресс-тестирование (поведение за пределами ожидаемой нагрузки)
Тестирование безопасности (пентестирование, SAST/DAST)
Тестирование надёжности (хаос-инжиниринг, отказоустойчивость)

Характеристики

Автоматизировано с человеческим анализом: инструменты генерируют данные, люди интерпретируют результаты
Запускается перед крупными релизами: не на каждом PR (слишком дорого)
Специализированные навыки: часто требует выделенной экспертизы по производительности или безопасности
Нефункциональный фокус: не о работе фич, а о том, насколько хорошо они работают

Роль QA в Q4

Определять бюджеты производительности (LCP < 2.5s, API p95 < 500ms)
Запускать нагрузочные тесты и анализировать результаты
Координировать сканирование безопасности и триаж находок
Мониторить производительность продакшена как непрерывную активность

Пример

// Нагрузочный тест k6 (Q4)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,        // 100 виртуальных пользователей
  duration: '5m',  // Запуск на 5 минут
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% запросов быстрее 500мс
    http_req_failed: ['rate<0.01'],    // Менее 1% ошибок
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Баланс четырёх квадрантов

Ключевой инсайт: все четыре квадранта необходимы. Команды, которые автоматизируют только тесты Q1, пропускают пробелы бизнес-уровня. Команды, которые проводят только исследовательское тестирование Q3, пропускают структурные проблемы. Зрелая QA-стратегия покрывает все четыре квадранта с соответствующими инвестициями.

Руководство по инвестициям

Зрелость команды	Q1	Q2	Q3	Q4
Начальный этап	40%	30%	25%	5%
Растущая команда	30%	30%	20%	20%
Зрелая команда	25%	25%	25%	25%

Команды начального этапа должны активно инвестировать в Q1 (юнит-тесты), потому что они обеспечивают самую быструю обратную связь. Зрелые команды должны распределять усилия более равномерно, со значительными инвестициями в Q4 для производительности и безопасности.

Сводка по квадрантам

Квадрант	Когда происходит	Кто управляет	Автоматизировано?
Q1 (Юнит/Интеграция)	Во время разработки, непрерывно	Разработчики + QA	Полностью автоматизировано
Q2 (Функциональные/Истории)	Во время спринта, по мере завершения историй	QA + PO	В основном автоматизировано
Q3 (Исследовательское/Юзабилити)	Во время спринта и перед релизом	QA + Пользователи	Ручное (по дизайну)
Q4 (Производительность/Безопасность)	Перед крупными релизами, непрерывно	QA + DevOps	Автоматизировано с человеческим анализом

Практическое упражнение

Сопоставьте ваши текущие тестовые активности с четырьмя квадрантами. Какие квадранты хорошо покрыты? Какие недостаточно?
Определите одну тестовую активность в каждом квадранте и оцените время, которое ваша команда тратит на каждую
Проведите 30-минутную сессию исследовательского тестирования, используя формат хартии выше
Определите бюджет производительности для одного критического API-эндпоинта и напишите простой нагрузочный тест
Предложите план ребалансировки квадрантов, если ваша команда чрезмерно инвестирует в Q1 и недостаточно в Q3