Тестирование ПО: UI, API, ручное и автоматизированное

Основа — руководство «Качество решает всё: полное руководство по тестированию ПО» (Роман Сурков). Всё, что помечено [вне книги], взято из других источников (список в конце) или общепринятой практики. Подавай это как дополнение, а не как позицию автора.

Когда применять

«Протестируй фичу / экран / приложение / API», «составь чек-лист / тест-кейсы», «оформи баг».
Проверка ТЗ, макета Figma или Swagger до разработки (shift-left).
Выбор, что и как автоматизировать; нагрузочный сценарий; отчёт о готовности релиза.
Для видеоигр бери скилл qa-game-testing, а отсюда — общую базу (тест-дизайн, артефакты).

Шаг 0. Определи режим работы

Запрос	Что выдать
Есть ТЗ / макет, кода ещё нет	Ревью требований (шаг 1) + чек-лист, написанный заранее
«Протестируй» без деталей	Разложение по «БЛУГИД с ПК» (шаг 2) → чек-лист → тест-кейсы на сложное
Живой сайт / приложение доступны	Прохождение проверок, баг-репорты, итоговый TRR
API / Swagger / cURL	BINMEN + POISED (шаг 6), коллекция запросов
«Что автоматизировать?», флейки, Playwright	План по пирамиде и правила автотестов (шаг 8)
Проверка безопасности API	Матрица OWASP API Top 10 (шаг 6)
Фича на LLM (чат-бот, генерация)	Слои проверок и эталонный набор (шаг 9)
Свободное тестирование новой фичи	Хартии сессий SBTM + SFDIPOT (шаг 2)

Сначала позитивные проверки (happy path), потом негативные. В позитивных проверки можно объединять, в негативных — один невалидный параметр на одну проверку.

Шаг 1. Тестирование требований (shift-left)

Ошибка дорожает по правилу 1–10–100: правка в ТЗ стоит 1, в коде — в 3–8 раз дороже, найденная QA — в 20–80 раз, на проде — в 100+ раз. Поэтому начинай с документа.

Критерии хорошего требования (на каждое нарушение — комментарий в документе): полнота (описаны крайние случаи и ошибки), непротиворечивость (текст не спорит с макетом), однозначность, корректность, тестируемость, атомарность (одна идея).

Слова-мусор — «быстрый», «удобный», «интуитивный», «гибкий», «адекватный», «при необходимости». Переписывай в измеримое: «поиск быстрый» → «выдача ≤ 1,5 с при 1000 одновременных запросов».

Если ТЗ нет, ожидаемый результат берётся из: макетов и прототипов → конкурентов → законов и регуляторов (GDPR, PSD2) → best practices и здравого смысла (валидация email, rate-limit, маски телефона) → разговора с разработчиком или аналитиком.

Как прожаривать требования: вопросы о границах (максимальная длина, запрещённые символы, обрыв связи, два пользователя жмут одновременно); блок-схема или mind map пути (стрелка, ушедшая в пустоту, — это неописанный сценарий); тест-кейсы прямо во время чтения (не получается написать кейс — нашёлся баг в ТЗ).

Оракулы FEW HICCUPPS [вне книги, М. Болтон и Дж. Бах] — чем ещё доказать, что поведение проблемное, если спецификации нет или она неполна. Продукт должен быть согласован с: Familiar problems (не повторяет известные типы багов), Explainability (поведение можно объяснить), World (не противоречит реальности), History (прошлыми версиями), Image (образом компании), Comparable products (аналогами), Claims (заявлениями: ТЗ, реклама, справка), User desires (разумными желаниями пользователя), Product (сам с собой: одно действие — одно поведение везде), Purpose (назначением), Statutes and standards (законами и стандартами). В баг-репорте называй оракул: «противоречит прошлой версии», «противоречит справке» — так спорить с «это не баг» проще.

Missing Feature: если функции нет и в ТЗ её нет — это не Bug, а Improvement / Feature Request. Споры снимает матрица функциональности: Web — есть, iOS — есть, Android — нет.

Шаг 2. Разложение задачи «Протестируй»

Функциональное тестирование отвечает на вопрос «ЧТО делает», нефункциональное — «КАК». Нефункциональные векторы перебирай по мнемонике «БЛУГИД с ПК»:

Б — безопасность (XSS, SQL-инъекции, права доступа)
Л — локализация
У — удобство (usability)
Г — графический интерфейс (GUI)
И — инсталляция (только то, что устанавливается: десктоп, мобайл, консоли)
Д — доступность (a11y)
П — производительность (клиентская и серверная)
К — конфигурация и совместимость

Добавь исследовательские туры Уиттакера для свободного поиска: путеводитель (главные фичи), задворки (редкие настройки), курьер (один объект через все статусы), деньги (корзина и оплата), полуночник (фоновые задачи), мусорщик («Отмена», «Сброс»), навязчивый (100 повторов одного действия), плохой район (исторически проблемные модули), музей (старый, давно не трогавшийся код).

Что вообще есть в продукте — SFDIPOT [вне книги, HTSM Дж. Баха]: Structure (из чего состоит: файлы, модули, сборки), Function (что делает), Data (что вводят, хранят, выводят; пустое, огромное, битое), Interfaces (UI, API, импорт/экспорт, интеграции), Platform (ОС, браузер, железо, внешние сервисы), Operations (как реально используют: частые сценарии, неопытный и злонамеренный пользователь), Time (таймауты, параллельность, порядок событий, часовые пояса, долгая работа). Пройдись по семи словам — получишь карту покрытия, которую БЛУГИД не даёт.

Исследовательское тестирование сессиями (SBTM) [вне книги, Дж. и Дж. Бах]. Сессия 60–90 минут без отвлечений, у неё хартия: «Исследовать <область> с помощью <инструменты, приёмы, данные>, чтобы обнаружить <что хотим узнать>». По итогам — лист сессии: что покрыто, найденные баги, вопросы, риски, доля времени на тестирование / оформление багов / настройку окружения, и короткий разбор с лидом. Так свободное тестирование становится отчётным: видно, что проверено и что осталось.

Шаг 3. Техники тест-дизайна

Порядок: сначала каркас из EP + BVA + таблиц решений, потом усиление через Error Guessing.

Классы эквивалентности (EP): по одному значению из каждого валидного и невалидного класса.
Граничные значения — только 3BVA: на каждой границе брать min-1, min, min+1 (и так же для max). 2BVA пропускает опечатку оператора X == 10 вместо X >= 10: точки 9 и 10 проходят, а 11 ломается. Пример: доступ 18–100 лет → -1, 0, 1, 16, 17, 18, 99, 100, 101. Для денег шаг — минимальная единица (0,01 ₽).
Комбинаторика: 1-wise (≈50% багов, экспресс), pairwise — стандарт (70–90%), 3-wise для финтеха (≈95%), полный перебор только для критичных систем. Никогда не собирай pairwise-матрицу в голове: сгенерируй её инструментом (PICT, если установлен, иначе pip install allpairspy --break-system-packages) и проверь скриптом, что покрыты все пары. Где применять: фильтры каталога, калькуляторы, оплата × доставка, экспорт (формат × кодировка × разделитель). Для кросс-браузерности pairwise не использовать (см. шаг 5).
Таблицы принятия решений: когда в ТЗ много «если / и / или / кроме», 2–5 бинарных условий. Вычёркивай невозможные комбинации, а правила с одинаковым исходом склеивай в один кейс. Типовые места: скидки и промокоды, матрица ролей, зависимые поля формы (юрлицо → ИНН и КПП обязательны), статусы заказа.
Состояния и переходы: всё, у чего есть жизненный цикл и таймауты. Проверяй недопустимые переходы, истечение таймаута (бронь без оплаты возвращается в «Свободно»), одноразовость токенов (повторный сброс пароля по старой ссылке), обрыв на каждом шаге.
Error Guessing — каталог граблей:
- грязный ввод: только пробелы, пробелы по краям email, U+200B, эмодзи, кавычки, иероглифы, 10 000 символов из буфера;
- повторы и гонки: тройной клик «Оплатить», «Назад» после транзакции, последний товар покупают двое;
- прерывания: обрыв сети на 99%, закрытие вкладки во время эквайринга;
- даты и числа: 29.02 в невисокосный год, дата рождения в будущем, 00.00.0000, количество −1, 0, 999 999;
- окружение: сессия протухла за 3 часа простоя, .exe с расширением .jpg, файл на 500 МБ.

Шаг 4. Артефакты

Чек-лист (ID, проверка, статус) — по умолчанию. Тест-кейс — для сложной логики, онбординга и передачи в автоматизацию.

Поля тест-кейса: ID, название, приоритет, предусловие (заполняется всегда), шаги, тестовые данные, ожидаемый результат; после прогона — фактический результат и статус (Passed / Failed / Blocked / Skipped).

Правила: в шагах только действия тестировщика, реакции системы — в ожидаемом результате; шаги атомарные («ввести email», «ввести пароль», «нажать Войти» — три шага); один кейс = одна проверка; кейсы не зависят друг от друга (подготовка уходит в предусловие или делается через API); детализация разумная, без «подвинуть мышь»; приоритет High — деньги и авторизация, Low — косметика, остальное (≈80%) Medium.

Тест-свит — папка по модулю с вложенными свитами по фичам; общие проверки модуля лежат в корне свита. Тест-ран — прогон набора на конкретной сборке и окружении со статусами. Тест-план (по запросу): scope (in / out), стратегия и окружение, критерии входа, приостановки и выхода, ресурсы и сроки, риски с планом Б.

Баг-репорт

Заголовок:   [Где] Что происходит, при каком условии
             пример: [Окно промокода] ошибка 500 при вводе просроченного купона
Окружение:   Prod/Stage, браузер и версия, ОС; для мобайла модель и точная версия ОС; URL
Предусловие: роль пользователя, страница, подготовленные данные
Шаги:        1. … 2. … (только действия, минимальная цепочка)
Ожидаемый:   конкретно, со ссылкой на ТЗ или макет
Фактический: что произошло
Severity:    Blocker / Critical / Major (есть обход) / Minor / Trivial — техническая оценка, ставит QA
Priority:    High / Medium / Low — срочность для бизнеса (решает PO/PM)
Воспроизводимость: Always (10/10) или Intermittent (например, 1/10)
Workaround:  альтернативный путь, если есть
Вложения:    скриншот для статики, видео для динамики, логи консоли или HAR для бэкенда

Правила: 1 баг = 1 тикет; перед заведением поищи дубль; заводи сразу; нейтральный тон; не выдумывай фикс в тикете; пиши так, чтобы через месяц по описанию можно было проверить исправление. Severity и Priority независимы (опечатка в логотипе: Trivial / Immediate).

Отчёт о тестировании (TRR)

Минимум воды, максимум цифр и явная рекомендация Go / No-Go:

ОТЧЁТ О ТЕСТИРОВАНИИ СБОРКИ vX.Y
Запланировано N кейсов: Passed a (a%) · Failed b (b%) · Blocked c (c%)
Дефекты: BUG-… — суть (приоритет) [ссылка] …
Заблокировано: какой блок и из-за каких багов
Рекомендация QA: выпуск НЕ рекомендован / рекомендован с условиями …

Шаг 5. UI: формы, GUI, удобство, доступность, совместимость, локализация

Формы и поля ввода

Текст: валидное значение; пустое обязательное поле; ровно max; max+1; спецсимволы ' " < > / ; : @ # $ % ^ & * ( ) _ +; эмодзи (падение на utf8mb4); только пробелы, ведущие, хвостовые и внутренние пробелы (ожидается trim); смешение кириллицы, латиницы, иероглифов и RTL; F5 сохраняет ввод (кроме пароля и капчи); двойной клик «Отправить» не шлёт два запроса; U+200B.
Пароль: маскирование; очищается при перезагрузке и ошибке; проверка на слабый пароль и на совпадение с логином или email; вставка из буфера и менеджера паролей; «глазик» переключает password ↔ text.
Выбор и загрузка: разумные значения по умолчанию (согласие не отмечено заранее — GDPR); клик по лейблу переключает чекбокс; «выбрать все / снять все»; обязательная группа радиокнопок; запрещённые расширения (.exe, .php), файл 0 байт и 100 МБ+, прогресс-бар.
UX валидации: inline-проверка на blur, введённое не сбрасывается при ошибке, поле подсвечено и рядом причина с CTA; формат подсказан заранее («ДД.ММ.ГГГГ»); одно поле — одно значение; экран успеха с номером, статусом и следующим шагом; «Назад» в многошаговой форме сохраняет данные или явно запрещён.
Плюс БЛУГИД: Tab / Shift+Tab / Enter, Safari и мобайл, переводы ошибок, XSS, SQL, CSRF, rate limit.

GUI: сверка с макетом (Figma + DevTools)

Начинай с Common Components — фикс в общем компоненте чинит десятки экранов. Размеры — расширение Pixel Measurement (ширина «меньше макета» при открытом DevTools — адаптив, а не баг). Шрифты и цвета — Elements → Computed (font-size, background-color → HEX). Отступы — Option/Alt в Figma против Box Model. Анимации — Command Palette → Show Animations, замедлить до 10–25%. Наложение — PerfectPixel при 50% opacity. Разница в 1 px — не баг (субпиксельное округление), если вёрстка не поплыла.

Удобство (usability)

Проверяй по 10 эвристикам Нильсена: статус системы, язык пользователя, контроль и Undo, стандарты платформы (HIG / Material), предотвращение ошибок, узнавание вместо запоминания, ускорители, минимализм, понятные ошибки, справка. Для взрослой аудитории: шрифт не мельче 12 pt, контраст, крупные цели. Не ломай нативные паттерны: двойной тап, системные жесты у края экрана. Отмена с «Undo» на 5 секунд лучше диалога «Вы уверены?».

Доступность (WCAG, POUR)

Быстрый прогон: Lighthouse (только Accessibility) → axe DevTools → IBM Equal Access → ANDI (порядок Tab и имена элементов) → контраст (AA ≥ 4.5:1, AAA ≥ 7:1). Текст поверх картинки или градиента перепроверяй пипеткой DevTools: сканеры берут цвет соседнего тега. Руками: вся работа без мыши, видимый и не перекрытый фокус, alt у информативных картинок, ничего не мигает чаще 3 раз в секунду, уважается prefers-reduced-motion, скринридер (NVDA / VoiceOver). Симуляции — Web Disability Simulator.

Совместимость

Матрицу строй по данным: своя аналитика → региональная статистика → StatCounter (и сообщи о риске недопокрытия). Смотри на выручку по платформам, а не только на трафик. Отбрось хвост < 0,5%. Группируй по движку: Chrome и Edge на Windows — один Chromium; все браузеры на iOS — WebKit, но Safari на iOS тестируй отдельно (свои баги вёрстки). Распредели регресс пропорционально долям (200 кейсов × доля группы), а не pairwise «браузер × кейс» (это 1400 прогонов). Нехватку устройств закрывай эмуляторами.

Локализация

Адаптация под язык и регион (даты, валюты, единицы, номера телефонов, адреса, написание имён)
Длина текста: немецкий на 30% длиннее английского → проверяй наложения и переносы
Склеивание в RTL-языках (арабский «5» и знак процента)
Встроенный контент (видео, реклама, FAQ) должен быть на целевом языке
Перевод ошибок должен быть осмысленным, не дословным

Шаг 6. API: BINMEN, POISED, OWASP API Top 10, контракты

Анализ API через BINMEN (тестовые сценарии)

Boundary — граничные значения
Interface — типы данных, форматы
Null/Empty — пустые и null-значения
Missing — пропущенные обязательные поля
Errors — обработка ошибок, коды ответов
Negative — негативные сценарии

Позитивные проверки POISED

Performance — время ответа, размер payload
Optimistic — успешные сценарии
Idempotency — повторные запросы не меняют состояние
Security — базовая безопасность
Exceptions — граничные случаи
Data — корректность данных

OWASP API Top 10 (проверки безопасности)

Broken Object Level Authorization (BOLA) — доступ к чужим объектам
Broken Authentication — слабая аутентификация
Excessive Data Exposure — избыточные данные в ответе
Lack of Resources & Rate Limiting — отсутствие ограничений
Broken Function Level Authorization — доступ к функциям
Mass Assignment — несанкционированное изменение полей
Security Misconfiguration — небезопасная конфигурация
Injection — SQL, NoSQL, OS command injection
Improper Assets Management — старые версии API
Insufficient Logging & Monitoring — недостаточное логирование

Контрактное тестирование

Consumer-Driven Contracts (CDC): потребитель определяет контракт
Pact или Spring Cloud Contract для автоматизации
Проверяй совместимость на каждом этапе CI/CD

Playwright для API-автотестов

const { test, expect } = require('@playwright/test');

test('POST /api/login возвращает токен', async ({ request }) => {
  const response = await request.post('/api/login', {
    data: { username: 'admin', password: 'password' }
  });
  expect(response.ok()).toBeTruthy();
  const body = await response.json();
  expect(body).toHaveProperty('token');
  expect(typeof body.token).toBe('string');
});

Шаг 7. Load & Performance

Определи сценарии (наиболее частые или дорогие)
Инструменты: k6, JMeter, Locust
Метрики: latency (p50, p95, p99), throughput, error rate
Тестируй на stage, не на prod
Начинай с smoke test (1 виртуальный пользователь), потом ramp-up
Мониторь серверные метрики (CPU, RAM, DB connections)

Шаг 8. Автоматизация: Playwright + правила

Что автоматизировать (пирамида тестирования)

Unit (60–70%) — бизнес-логика, утилиты, математика
Integration (20–25%) — API, база данных, внешние сервисы (через моки)
E2E (5–10%) — критические сценарии (логин, покупка, оплата)
Visual — скриншотные тесты на регрессию

Не автоматизируй:

Часто меняющийся UI (ранний этап разработки)
Косметику (смещение на 1 px)
Тесты, требующие человеческой оценки (юзабилити)
Тесты с недетерминированным поведением (флейки)

Правила для надёжных тестов

Не используй sleep() — всегда жди элемент (waitForSelector, waitForResponse)
Test isolation — каждый тест сам готовит данные (через API или setup)
Data-driven — вынеси тестовые данные в фикстуры или JSON
Retry flaky tests — Playwright: retries: 2 в конфиге
POM (Page Object Model) — разноси логику по страницам

Playwright best practices

import { test, expect } from '@playwright/test';

test.describe('Login Page', () => {
  test('успешный вход', async ({ page }) => {
    await page.goto('/login');
    await page.fill('#email', '[email protected]');
    await page.fill('#password', 'securePass123');
    await page.click('button[type="submit"]');
    await expect(page.locator('.welcome')).toHaveText('Добро пожаловать!');
  });
});

Рекомендуемые настройки playwright.config.ts:

const config: PlaywrightTestConfig = {
  retries: 2,
  workers: 4,
  timeout: 30000,
  use: {
    baseURL: 'https://staging.example.com',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
};

Флейки (flaky tests): как бороться

Если тест падает на CI, но проходит локально → flaky
Причины: race condition, асинхронность, внешние API, state leakage
Решения:
- Увеличь таймауты для стабильности
- Исправь порядок тестов (isolation)
- Используй waitFor* вместо waitForTimeout
- Отключай внешние вызовы (mock/stub)
- Если не лечится — помечай @flaky и пиши баг на инфраструктуру

Шаг 9. LLM-фичи: чат-боты, генерация, RAG

Слои проверок

Input layer: валидация промпта, безопасность (prompt injection, jailbreak)
Processing layer: качество генерации, соответствие fact, тональность
Output layer: безопасность ответа, запрещённые темы, галлюцинации
Integration layer: API-контракты, таймауты, rate limits
User experience: скорость, диалоговый поток, персонализация

Эталонный набор тестов

Промпт-атаки: «Ignore previous instructions», «Act as DAN»
Факт-чекинг: проверь ответы на точность и актуальность
Консистентность: один и тот же вопрос → один ответ (или вариации в допустимом диапазоне)
Токены: не превышает ли ответ лимит токенов, не усечён ли
Конфиденциальность: не выводит ли личные данные (PII) в ответ
Toxic content: мат, дискриминация, насилие, сексуальный контент

Полезные источники (вне книги)

OWASP API Security Top 10 — https://owasp.org/www-project-api-security/
HTSM (Heuristic Test Strategy Model) — Дж. Бах
Session-Based Test Management — Дж. и Дж. Бах
FEW HICCUPPS — М. Болтон и Дж. Бах
SFDIPOT — из HTSM Дж. Баха
Playwright Documentation — https://playwright.dev/
WCAG 2.2 — https://www.w3.org/TR/WCAG22/
Эвристики Нильсена — 10 Usability Heuristics for User Interface Design
Пирамида тестирования — Mike Cohn, "Succeeding with Agile"
Contract Testing — Pact.io

TODO (по желанию)

Мобильные жесты и прерывания (звонок, push)
Работа с реальными устройствами (Device Farm)
Конфигурация для CI (GitLab CI, GitHub Actions)
Security: OAuth2, JWT, SSRF, XXE
Database: миграции, роллбэки, шардинг
Chaos engineering: потеря пакетов, DNS down
Coverage: branch coverage, mutation testing

在你喜欢的 AI 中提问

文档