QA Engineer: тестирование ПО с нуля до уверенного уровня

Роль QA и жизненный цикл разработки ПО (SDLC/STLC)

Качество в ПО — это не «проверка в конце», а управляемый процесс, который начинается с идеи продукта и заканчивается поддержкой в эксплуатации. В этой статье разберём:

кто такой QA Engineer и чем он отличается от «тестировщика»

что такое жизненный цикл разработки ПО SDLC

что такое жизненный цикл тестирования STLC

где именно QA создаёт ценность на каждом этапе

Кто такой QA и чем QA отличается от тестировщика

QA (Quality Assurance) — это обеспечение качества: система практик, процессов и договорённостей в команде, которая помогает выпускать продукт с предсказуемым уровнем качества.

Тестирование (Quality Control) — это контроль качества: проверка продукта (или его части), чтобы найти дефекты и дать информацию о текущем состоянии.

На практике роль QA Engineer часто объединяет оба направления:

помогает команде строить процесс качества (QA)

выполняет проверки и организует тестирование (QC)

Полезный ориентир терминов: ISTQB Glossary.

Зачем вообще нужен жизненный цикл

ПО создаётся шагами: от идеи до релиза и дальнейшей поддержки. Если эти шаги не согласованы, возникают типичные проблемы:

требования поняты по-разному, из-за чего делают «не то»

дефекты обнаруживаются слишком поздно (дорого исправлять)

тестирование превращается в хаос из-за отсутствия критериев готовности

релизы становятся непредсказуемыми по срокам

Жизненные циклы SDLC и STLC дают структуру: что делаем, в каком порядке, с какими входами и выходами.

SDLC: жизненный цикл разработки ПО

SDLC (Software Development Life Cycle) — модель этапов, через которые проходит продукт/функция от задумки до эксплуатации. Сами названия этапов могут отличаться в компаниях, но смысл обычно одинаковый.

Типовые этапы SDLC

Инициирование и анализ потребностей

Сбор и уточнение требований

Проектирование решения

Разработка (код)

Тестирование и проверка качества

Релиз и внедрение

Поддержка и улучшения

!Схема показывает основные этапы SDLC и то, какие результаты (артефакты) обычно появляются на каждом этапе

Модели SDLC: как это бывает организовано

Один и тот же набор этапов может быть организован по-разному.

Waterfall (каскадная модель): этапы идут последовательно, изменения дорогие. Часто встречается в проектах с жёсткими регламентами.

Agile (гибкие подходы): работа короткими итерациями, регулярная поставка ценности, постоянная обратная связь. Основа ценностей: Agile Manifesto.

V-model: развитие каскада, где каждому этапу разработки соответствует уровень тестирования (например, требованиям соответствует приёмочное тестирование, дизайну — системное и т.д.).

Важно: модель SDLC не «хорошая» и не «плохая» сама по себе. Она должна подходить под продукт, риски, регуляторные ограничения и зрелость команды.

Базовое определение жизненного цикла процесса разработки: Software development process.

STLC: жизненный цикл тестирования

STLC (Software Testing Life Cycle) — этапы работ по тестированию, которые помогают сделать проверки управляемыми и повторяемыми.

STLC не живёт отдельно от SDLC: он «встроен» в разработку и начинается задолго до появления готового функционала.

Типовые этапы STLC

Анализ требований

Планирование тестирования

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

Подготовка тестовых данных и тестовой среды

Выполнение тестов

Управление дефектами и повторные проверки

Завершение тестирования и отчётность

Что является входом и выходом этапов STLC

| Этап STLC | Входы | Выходы | |---|---|---| | Анализ требований | требования, макеты, API-контракты, уточнения от аналитика/PO | список рисков, вопросы, критерии тестируемости, черновик тест-идей | | Планирование | приоритеты, сроки, команда, риски | тест-план или подход к тестированию, стратегия, оценка трудозатрат | | Проектирование тестов | требования + уточнения + риски | тест-кейсы, чек-листы, тестовые сценарии, матрица покрытия | | Подготовка среды/данных | тест-дизайн, ограничения среды | готовая тестовая среда, тестовые аккаунты/данные | | Выполнение | сборка приложения, тесты, данные | результаты прогонов, отчёты, дефекты | | Дефекты и ретест | заведённые баги, фиксы | подтверждённые исправления, регресс-результаты | | Завершение | результаты, метрики, выводы | тест-репорт, рекомендации, список известных проблем |

Роль QA на каждом этапе SDLC

Один из ключевых принципов современной разработки — находить проблемы как можно раньше. Это часто называют shift-left: смещение активности по качеству «влево», ближе к требованиям и дизайну.

Ниже — что делает QA на этапах SDLC.

Требования

QA помогает сделать требования тестируемыми.

задаёт уточняющие вопросы

выявляет противоречия и «дыры»

предлагает примеры и крайние случаи

помогает сформулировать критерии приёмки (условия, при которых задача считается сделанной)

Примеры вопросов QA к требованиям:

какие состояния считаются ошибкой

что происходит при пустых/некорректных данных

какие роли пользователей имеют доступ

какие ограничения по времени/объёму

Проектирование

QA подключается к обсуждению решения, чтобы снизить риски.

проверяет логику сценариев (особенно негативных)

оценивает тестируемость: можно ли проверить функционал без «магии»

предлагает точки контроля: логи, события, статусы, мониторинг

Разработка

QA и разработка работают как партнёры.

уточняют критерии готовности

договариваются о форматах дефектов и воспроизведении

поддерживают быстрый цикл обратной связи

Полезная практика — договориться о Definition of Done (что значит «готово»). Обычно туда включают:

код написан и прошёл ревью

автоматические проверки прошли

тестирование выполнено по согласованному объёму

критические дефекты исправлены

Тестирование

Здесь QA выполняет и организует проверки, но важно помнить: тестирование — не только «покликать интерфейс».

функциональные проверки (что система делает)

нефункциональные проверки (как она это делает): производительность, безопасность, удобство

интеграционные проверки (взаимодействие сервисов)

регрессионное тестирование (не сломалось ли старое)

Релиз и поддержка

Качество продолжается после релиза.

участвует в релизных решениях на основе рисков

помогает подготовить release notes (заметки о выпуске)

анализирует инциденты и причины дефектов

улучшает тестовый набор, чтобы подобные проблемы не повторялись

Смещение активности «вправо» часто называют shift-right: мониторинг, аналитика, сбор обратной связи в эксплуатации.

Качество продукта: что именно мы защищаем

Качество — это не только «нет багов». Продукт может быть без явных ошибок, но неудобным или небезопасным.

Примеры характеристик качества:

функциональная корректность

надёжность (стабильность)

удобство использования

производительность

безопасность

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

Если хочется углубиться в терминологию «модели качества», ориентир: ISO/IEC 25010.

Артефакты QA: что обычно создаётся

Артефакты — это результаты работы, которые помогают команде повторять процесс и принимать решения.

тест-план или краткий подход к тестированию

чек-листы и тест-кейсы

тестовые данные

отчёты о тестировании (test report)

баг-репорты

матрица покрытия требований тестами (traceability)

Важно: артефакты — средство, а не цель. Их объём зависит от рисков, сроков и зрелости команды.

Критерии входа и выхода: как понять, что можно начинать и заканчивать

Чтобы тестирование не превращалось в бесконечность, команды часто договариваются о критериях.

Критерии входа (entry criteria): что должно быть готово, чтобы начинать тестирование (например, доступна среда, есть сборка, требования стабильны на текущую итерацию).

Критерии выхода (exit criteria): что должно быть выполнено, чтобы завершать тестирование и принимать релизное решение (например, пройдены критические тесты, нет блокирующих дефектов, известные проблемы задокументированы).

Как QA взаимодействует с командой

QA — это не «вратарь» между разработкой и релизом, а участник команды.

с аналитиком/PO: уточнение требований и критериев приёмки

с разработчиками: воспроизведение дефектов, диагностика, улучшение тестируемости

с DevOps/инфраструктурой: стабильность сред, доступы, логи, мониторинг

с поддержкой: анализ инцидентов и улучшение предотвращения дефектов

Итоги

SDLC описывает жизненный путь продукта от идеи до поддержки.

STLC структурирует работу по тестированию: от анализа требований до отчётности.

QA создаёт ценность на ранних этапах (тестируемость требований, снижение рисков) и на поздних (устойчивость релиза, обратная связь из эксплуатации).

Качество — это совместная ответственность команды, а QA помогает сделать её управляемой.

Тестирование: уровни, виды, стратегии и подходы

Тестирование — это управляемая проверка продукта, которая даёт команде информацию о качестве и рисках. В прошлой статье мы разобрали, как тестирование «встраивается» в SDLC и STLC, какие бывают входы и выходы этапов, и почему важно находить проблемы раньше.

В этой статье соберём «карту» тестирования:

уровни тестирования (на каком «слое» системы проверяем)

виды тестирования (что именно проверяем)

стратегии (как выбираем что тестировать в первую очередь и каким объёмом)

подходы (какими методами проектируем и выполняем проверки)

> Цель QA не в том, чтобы «проверить всё», а в том, чтобы дать максимум уверенности за ограниченное время, ориентируясь на риски.

Базовые определения

Дефект (bug) — несоответствие фактического поведения ожидаемому.

Отказ (failure) — проявление дефекта в работе системы (когда пользователь видит проблему).

Тест-кейс — пошаговое описание проверки с ожидаемым результатом.

Чек-лист — список проверок без детальной пошаговости.

Регрессия — проверка, что ранее работавший функционал не сломался после изменений.

Терминология может отличаться в компаниях, но хороший общий ориентир — ISTQB Glossary.

Уровни тестирования

Уровни отвечают на вопрос: на каком уровне детализации мы проверяем продукт.

Модульное тестирование

Проверяет маленькие части кода: функции, методы, классы.

Обычно пишется разработчиками.

Даёт быстрый фидбэк и помогает «ловить» ошибки рядом с местом появления.

Важно: QA часто не пишет модульные тесты на старте карьеры, но должен понимать их роль, ограничения и как они влияют на общее качество.

Интеграционное тестирование

Проверяет взаимодействие компонентов между собой: сервисы, базы данных, очереди, сторонние API.

Часто находит ошибки контрактов, форматов данных, таймингов, обработки ошибок.

Системное тестирование

Проверяет систему целиком как продукт: основные пользовательские сценарии, права доступа, бизнес-правила.

Обычно выполняется в среде, близкой к реальной, и включает UI и/или API.

Приёмочное тестирование

Проверяет, что функциональность соответствует ожиданиям бизнеса и пользователя.

Может выполняться PO/аналитиком/заказчиком, иногда вместе с QA.

Основа — критерии приёмки и ожидаемая ценность.

!Пирамида тестирования показывает, почему обычно выгоднее иметь больше проверок на низких уровнях и меньше дорогих E2E.

Виды тестирования

Виды отвечают на вопрос: какое свойство продукта мы проверяем.

Функциональное тестирование

Проверяет, что система делает то, что должна.

корректность бизнес-логики

работа экранов, форм, расчётов, статусов

корректность ответов API

Нефункциональное тестирование

Проверяет, как система это делает.

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

Безопасность

Удобство использования (usability)

Доступность (accessibility)

Совместимость (браузеры, устройства, ОС)

Чтобы понимать, какие «характеристики качества» существуют в целом, можно ориентироваться на ISO/IEC 25010.

Тестирование изменений

Это группа видов, которые особенно важны в итеративной разработке.

Дымовое тестирование (smoke) — быстрый минимум, чтобы понять, что сборка «вообще живая» и её имеет смысл тестировать глубже.

Санитарное тестирование (sanity) — быстрая проверка конкретного изменения или области после фикса/небольшой правки.

Регрессионное тестирование — проверка, что изменения не сломали существующий функционал.

Тестирование по назначению проверки

Исследовательское тестирование (exploratory)

Повторяемое тестирование по заранее подготовленным проверкам (чек-листам/тест-кейсам)

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

Стратегии тестирования

Стратегия отвечает на вопрос: как мы принимаем решения о приоритетах, объёме и глубине проверок.

Риск-ориентированная стратегия

Суть: тестируем в первую очередь то, где выше риск.

Риск обычно рассматривают как сочетание двух факторов:

Вероятность проблемы (насколько легко сломать, насколько сложное изменение)

Ущерб (сколько пользователей пострадает, деньги, репутация, безопасность)

Практический результат для QA:

критичные сценарии идут первыми

глубокие проверки — там, где высокая цена ошибки

второстепенные области можно проверять выборочно

Стратегия по критическим пользовательским потокам

Выделяют end-to-end цепочки, без которых продукт не имеет смысла.

Примеры (обобщённо):

регистрация → вход → основное действие пользователя

поиск/выбор → оформление → оплата → подтверждение

Эти потоки получают стабильный набор проверок (часто — регрессионный минимум).

Стратегия по изменениям

Суть: чем ближе к изменённому месту, тем вероятнее дефект.

тщательно тестируем изменённые модули

проверяем интеграции вокруг

делаем целевой регресс по затронутым сценариям

Эта стратегия особенно важна, когда времени мало, а релизы частые.

Стратегия автоматизации

Автоматизация — не цель, а способ сделать проверки быстрее и повторяемее.

Реалистичный подход:

Автоматизировать «долго и часто» (регресс, критические сценарии)

Оставлять ручными проверки, которые редко повторяются или сильно меняются

Следить за стоимостью поддержки автотестов

Полезная модель мышления — «пирамида тестирования» (много быстрых проверок внизу, меньше дорогих E2E наверху). Часто упоминается в контексте идей Майка Кона: Test Pyramid.

Подходы к тестированию

Подход отвечает на вопрос: как именно мы проектируем и выполняем проверки.

Чёрный, белый и серый ящик

Чёрный ящик (black-box): проверяем поведение без знания внутреннего устройства. Основной подход в ручном тестировании UI и API.

Белый ящик (white-box): используем знания о коде и структуре (ветвления, условия, обработка исключений). Чаще применяют разработчики и QA в автоматизации/ревью тестов.

Серый ящик (gray-box): знаем часть внутренностей (например, схему БД, логи, архитектуру), но тестируем как пользователь/через API.

Статическое и динамическое тестирование

Статическое — без запуска кода: ревью требований, макетов, кода, тестовой документации.

Динамическое — с запуском системы: выполнение тестов, наблюдение фактического поведения.

Связь с прошлой статьёй про STLC: статические активности особенно полезны на этапе анализа требований и проектирования, чтобы реализовать shift-left и предотвратить дефекты до разработки.

Скриптовое и исследовательское тестирование

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

Исследовательское — одновременно изучаем продукт, проектируем и выполняем проверки. Сильная сторона: быстро находит неожиданные дефекты и пробелы в требованиях.

На практике полезна комбинация:

Зафиксировать стабильный «скелет» регресса

Оставить время на исследование новых/рискованных изменений

Подход через тест-дизайн (как придумывать проверки)

Тест-дизайн — набор техник, которые помогают системно подбирать проверки, а не «кликать наугад».

Ниже — техники, которые часто применяют даже на старте.

Разбиение на классы эквивалентности

Проверка граничных значений

Таблицы решений (когда много условий)

Переходы состояний (когда система имеет статусы)

Важно: эти техники не гарантируют отсутствие дефектов, но помогают покрыть ключевые варианты меньшим числом тестов.

Как выбрать нужную комбинацию на проекте

Комбинация уровней, видов, стратегий и подходов зависит от контекста.

Быстрый ориентир по выбору

Если релизы частые и много правок, усиливайте регресс и стратегию «по изменениям»

Если продукт новый и требования меняются, добавляйте больше исследовательского тестирования и статических ревью

Если высокая цена ошибки (деньги, безопасность, регуляторика), усиливайте приёмочные критерии, трассировку требований и нефункциональные проверки

Если приложение «падает» и среда нестабильна, начинайте со smoke и стабилизации окружения, иначе любая стратегия будет буксовать

Типичные ошибки новичков

Путать уровни и виды

Делать «полный регресс» всегда и везде без учёта рисков

Считать, что E2E через UI должны покрывать всё

Игнорировать нефункциональные риски до инцидента

Начинать тестирование без понятных критериев приёмки и ожидаемого поведения

Итоги

Уровни показывают, на каком «слое» продукта мы тестируем: модульный, интеграционный, системный, приёмочный.

Виды показывают, что проверяем: функциональность, нефункциональные свойства, изменения (smoke/sanity/регресс).

Стратегия помогает выбирать приоритеты и объём тестирования на основе рисков, критических потоков и характера изменений.

Подходы определяют, как проектировать проверки: black-box/white-box/gray-box, статическое/динамическое, скриптовое/исследовательское, техники тест-дизайна.

Следующий практический шаг для QA — научиться превращать требования и риски в понятные наборы проверок: чек-листы, тест-кейсы и баг-репорты.

Тест-дизайн: техники, приоритизация и покрытие

Тестирование становится управляемым, когда QA умеет превращать требования и риски в конкретные проверки и понимает, насколько хорошо эти проверки покрывают продукт.

В прошлых статьях мы разобрали:

как QA встроен в SDLC/STLC и почему важно начинать думать о качестве рано

уровни, виды, стратегии и подходы тестирования

Эта статья — про практический «мотор» ручного тестирования: тест-дизайн. Мы разберём:

как из требований получать тестовые условия и тесты

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

как приоритизировать проверки при ограниченном времени

что такое покрытие и как его сделать прозрачным

Что такое тест-дизайн

Тест-дизайн — это процесс проектирования проверок так, чтобы с минимальным набором тестов получить максимальную информацию о качестве и рисках.

На практике тест-дизайн отвечает на вопросы:

что именно проверяем (объекты и условия)

какие варианты входных данных и состояний важны

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

как показать команде, что покрыто, а что нет

Тест-дизайн не равен «написать много тест-кейсов». Часто результатом будет компактный чек-лист, а детальные тест-кейсы — только для критичных и повторяемых сценариев.

Термины вроде тест-кейс, чек-лист, дефект полезно сверять с ISTQB Glossary.

От требований к тестам: базовый алгоритм

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

Определить объект тестирования и границы: что входит в задачу, что явно не входит.

Выписать правила и ожидаемое поведение: бизнес-правила, валидации, ограничения, роли, статусы.

Сформировать тестовые условия (test conditions): что должно быть проверено.

Выбрать техники тест-дизайна и получить набор тестов.

Подготовить тестовые данные и предусловия.

Решить формат фиксации: чек-лист или тест-кейсы.

Сделать покрытие прозрачным: связать тесты с требованиями/критериями.

!Схема показывает путь от требований к тестам и покрытию

Техника: разбиение на классы эквивалентности

Классы эквивалентности — это группы входных данных, которые с точки зрения системы должны обрабатываться одинаково. Идея: вместо проверки всех значений выбираем по 1–2 представителя из каждого класса.

Когда полезно

поля ввода (возраст, сумма, длина строки)

фильтры и параметры API

любые правила вида «допустимо/недопустимо»

Пример

Требование: поле Возраст принимает целое число от 18 до 65 включительно.

Классы:

валидные: 18–65

невалидные: меньше 18

невалидные: больше 65

невалидные: не число (буквы, спецсимволы)

невалидные: пусто

Минимальный набор проверок можно построить по представителю из каждого класса.

Техника: граничные значения

Граничные значения — это проверка точек рядом с границами допустимых диапазонов, где ошибки встречаются чаще всего (например, перепутали < и <=).

Когда полезно

диапазоны (минимум/максимум)

лимиты (количество товаров, размер файла)

длины строк

даты и время

Пример

Для возраста 18–65 типовой набор границ:

17 (ниже минимума)

18 (минимум)

19 (рядом с минимумом)

64 (рядом с максимумом)

65 (максимум)

66 (выше максимума)

Эта техника часто идёт вместе с классами эквивалентности: классы дают «области», границы — самые опасные точки внутри них.

Техника: таблицы решений

Таблица решений помогает, когда поведение зависит от нескольких условий, а комбинаций становится много. Техника превращает набор правил в список комбинаций «условия → результат».

Когда полезно

скидки, тарифы, комиссии

права доступа

бизнес-правила с несколькими флагами и исключениями

Мини-пример

Правило: доступ к отчёту есть, если пользователь админ или если он менеджер и отчёт не секретный.

| Условие | Правило 1 | Правило 2 | Правило 3 | |---|---:|---:|---:| | Роль = админ | да | нет | нет | | Роль = менеджер | нет | да | да | | Отчёт секретный | не важно | нет | да | | Ожидаемый доступ | разрешён | разрешён | запрещён |

Такую таблицу удобно превращать в тесты: по одной проверке на каждое правило (колонку), а не на все возможные сочетания.

Техника: переходы состояний

Переходы состояний подходят системам, у которых есть статусы и разрешённые переходы между ними.

Когда полезно

заказы: создан → оплачен → доставлен → завершён

тикеты: открыт → в работе → решён → закрыт

подписки: активна → приостановлена → отменена

Что проверять

разрешённые переходы работают

запрещённые переходы невозможны (или корректно ошибаются)

побочные эффекты при смене состояния (уведомления, списания, записи в историю)

корректное отображение статуса в UI и API

Пример набора проверок

Если заказ не может перейти из создан сразу в доставлен, это отдельная негативная проверка, даже если UI «не даёт нажать кнопку»: запрет должен быть и на уровне API/бэкенда.

Техника: попарное тестирование (pairwise)

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

Когда полезно

формы с множеством полей и вариантов

настройки (язык, валюта, тип доставки, способ оплаты)

совместимость (браузер × ОС × устройство)

Это не заменяет тестирование критичных E2E потоков, но помогает разумно сжать комбинаторику.

Ориентир по идее техники: Pairwise testing.

Техника: use case и пользовательские сценарии

Иногда лучшая «техника» — это честно пройти ключевой пользовательский сценарий от начала до конца.

Что важно не забыть

предусловия (зарегистрирован, есть права, есть товары в корзине)

основные шаги и ожидаемый результат

альтернативные пути (нет товара, нет денег, отмена)

негативные ситуации (потеря сети, истёкшая сессия)

Такие проверки часто составляют основу smoke/регресса для критических потоков.

Техника: предположение об ошибках (error guessing)

Предположение об ошибках — это опытная техника: QA использует знания о типичных сбоях, слабых местах и прошлых дефектах.

Примеры источников идей:

история багов в этом модуле

места частых изменений

интеграции со сторонними системами

нестабильные среды, тайм-ауты, ретраи

Важно: технику лучше фиксировать результатом в виде списка «наблюдений и рисков» и добавлять найденные важные проверки в регресс.

Как выбирать технику: быстрый ориентир

| Ситуация | Техника, с которой стоит начать | Почему | |---|---|---| | Диапазоны, лимиты, длины | границы + эквивалентность | быстро ловит ошибки на стыках | | Много условий и правил | таблица решений | структурирует комбинации | | Статусы и жизненный цикл | переходы состояний | покрывает логику статусов | | Много параметров в комбинации | pairwise | сжимает комбинаторику | | Ключевой путь пользователя | сценарии/use case | защищает ценность продукта | | Есть история проблем | error guessing | повторяемость реальных рисков |

На практике техники комбинируют: например, сценарий оформления заказа + границы для промокода + таблица решений для скидок.

Приоритизация проверок: что делать сначала

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

Полезная модель: риск как «вероятность × ущерб»

Чтобы не спорить «на ощущениях», QA обычно оценивает риск как сочетание:

вероятности дефекта (сложное изменение, новая логика, много интеграций)

ущерба от дефекта (деньги, безопасность, блокировка ключевого потока)

Это не обязано быть математикой: часто достаточно шкалы низкий/средний/высокий и короткого обоснования.

Практические правила приоритизации

Начинайте со smoke для проверки «сборка жива»: вход, основные страницы, базовые API.

Затем проверяйте критические пользовательские потоки end-to-end.

Далее — область изменения и ближайшие интеграции вокруг (стратегия «по изменениям»).

Негативные сценарии добавляйте приоритетно там, где высокая цена ошибки (деньги, безопасность, данные).

Остальное покрывайте выборочно, используя техники сжатия (эквивалентность, pairwise).

Как превратить приоритет в план на день

Удобная структура чек-листа по приоритету:

P0: блокирующие и критические проверки (без них нельзя принимать релиз)

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

P2: второстепенные (редкие сценарии, косметика)

Важно заранее договориться с командой, что P0 — это критерий выхода для тестирования на итерации (связь с темой entry/exit criteria из статьи про STLC).

Покрытие: как понять, что вы проверили достаточно

Покрытие — это ответ на вопрос: «какую часть требований, рисков и поведения системы мы проверили тестами».

В ручном тестировании чаще всего используют три вида покрытия.

Покрытие требований и критериев приёмки

Самый понятный для бизнеса вариант: на каждое требование или критерий приёмки есть хотя бы одна проверка.

Практический инструмент — матрица трассируемости (traceability): связь требование → тесты.

Покрытие рисков

Для сложных задач полезно явно выписать риски и напротив каждого указать проверку(и), которые этот риск снижают.

Пример формата:

| Риск | Почему важен | Проверки | |---|---|---| | Двойное списание при оплате | финансовые потери и инцидент | повторная отправка запроса, обновление страницы, тайм-аут ответа | | Утечка данных между ролями | безопасность и репутация | проверки прав доступа для ролей, прямые запросы к API |

Покрытие функций и состояний

Это покрытие «карты продукта»: экраны, функции, статусы, роли. Особенно полезно для регресса: видно, что у вас есть стабильный набор проверок по ключевым областям.

Чек-лист или тест-кейс: что выбрать

Выбор формата — часть тест-дизайна.

Когда достаточно чек-листа

проверка одноразовая или меняющаяся

нужно быстро пройти область и собрать информацию

команда понимает контекст без детальных шагов

Когда нужен тест-кейс

критичный сценарий (регресс, релизная проверка)

сложные предусловия и данные

проверку выполняют разные люди

важно однозначное «пройдено/не пройдено» и воспроизводимость

Частая практика: чек-лист на исследование и первичную проверку, а найденные важные проверки постепенно превращаются в регрессионный набор тест-кейсов.

Типичные ошибки новичков в тест-дизайне

Делать проверки только «счастливого пути» и забывать негативные сценарии.

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

Не отделять тестовые условия от тестов (в итоге тесты дублируются и неясно, что покрыто).

Не фиксировать связь с требованиями и критериями приёмки (покрытие становится невидимым).

Писать детальные тест-кейсы на всё подряд, не учитывая стоимость поддержки.

Итоги

Тест-дизайн превращает требования и риски в эффективный набор проверок.

Базовые техники: классы эквивалентности, граничные значения, таблицы решений, переходы состояний, pairwise, сценарии, предположение об ошибках.

Приоритизация обычно строится на рисках, критических потоках и области изменений.

Покрытие полезно показывать через связь требований/рисков/функций с тестами (матрица покрытия).

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

Тестовая документация: тест-кейсы, чек-листы, баг-репорты

Тестирование становится предсказуемым, когда результаты работы QA можно повторить, обсудить и использовать в следующих релизах. Для этого нужна тестовая документация.

В предыдущих темах мы разобрали:

где QA находится в SDLC/STLC и какие есть входы/выходы этапов

уровни, виды, стратегии тестирования и как выбирать приоритеты

техники тест-дизайна и как превращать требования в проверки

Теперь соберём это в практику: как оформлять проверки и находки так, чтобы команда быстрее выпускала качественные релизы.

В статье разберём:

чем отличаются тест-кейсы и чек-листы, и когда что выбирать

из чего состоит хороший тест-кейс и как писать ожидаемые результаты

как оформлять баг-репорт, чтобы дефект быстро воспроизвели и исправили

как связать документацию с требованиями и покрытием

Термины полезно сверять с ISTQB Glossary.

Зачем вообще нужна тестовая документация

Документация QA — это не «бумажки ради галочки», а инструмент управления рисками и коммуникации.

Она помогает:

сделать тестирование повторяемым (регресс, релизные проверки)

показать покрытие (что проверили и почему этого достаточно)

ускорить диагностику дефектов (разработчик получает точные шаги и факты)

хранить знания о продукте (что важно проверять в следующий раз)

договориться с командой о критериях готовности и приемки

При этом объём документации должен соответствовать контексту:

больше формализации, если высокая цена ошибки (деньги, безопасность, регуляторика)

меньше формализации, если продукт быстро меняется и важна скорость обратной связи

Карта артефактов: как всё связано

Обычно это выглядит как цепочка от требований к дефектам и отчётности.

!Схема показывает путь от требований и рисков к тестам, прогонам и баг-репортам.

Чек-лист и тест-кейс: в чём разница

Оба формата описывают проверки, но с разной детализацией.

Чек-лист

Чек-лист — это список проверок, обычно без подробных шагов. Он отвечает на вопрос: что проверить.

Когда чек-лист подходит лучше:

нужно быстро проверить область и собрать информацию

функциональность часто меняется, детальные шаги быстро устаревают

проверку делает человек, который хорошо знает продукт

нужно зафиксировать набор идей для исследовательского тестирования

Риски чек-листа:

разные люди могут «проверить одно и то же» по-разному

сложнее доказать покрытие требований и повторить точные шаги

Тест-кейс

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

Когда тест-кейс обязателен или очень полезен:

критичные сценарии (основа smoke, регресса, релизных проверок)

сложные условия и данные (роли, статусы, интеграции)

проверку должны выполнять разные люди

нужно однозначное понимание результата и воспроизводимость

Компромисс, который часто работает в командах:

чек-листы для быстрого покрытия и исследования

тест-кейсы для стабильного регресса и критических потоков

Структура хорошего тест-кейса

Единого стандарта для всех компаний нет, но поля обычно похожи.

Минимальный набор полей

ID: уникальный номер или ключ

Название: что проверяем

Предусловия: какое состояние системы нужно заранее

Шаги: действия тестировщика

Ожидаемый результат: что должно быть в итоге

Часто добавляют

Тестовые данные: логины, суммы, промокоды, даты

Приоритет: насколько важно (например, P0/P1/P2)

Требование или критерий приёмки: ссылка на задачу или пункт требований

Окружение: браузер, ОС, стенд, версия сборки

Постусловия: что должно произойти после теста (например, создан заказ)

Как писать ожидаемый результат

Ожидаемый результат должен быть:

проверяемым (можно однозначно сказать «да/нет»)

конкретным (какой текст, какой статус, какая запись создаётся)

привязанным к бизнес-ценности (что именно важно для пользователя)

Плохой ожидаемый результат:

«всё работает»

Хороший ожидаемый результат:

«после оплаты заказ получает статус Оплачен, отображается номер транзакции, в истории платежей появляется запись с суммой 4990 ₽»

Пример тест-кейса

Как из требований сделать набор тестов и не утонуть

Связь с прошлой темой про тест-дизайн такая:

техники тест-дизайна помогают выбрать минимально достаточные проверки

тестовая документация помогает эти проверки зафиксировать и переиспользовать

Практический подход:

Выпишите тестовые условия (что должно быть проверено).

Для каждого условия решите формат:

- чек-лист, если проверка быстро меняется или одноразовая - тест-кейс, если сценарий критичный и повторяемый

Добавьте приоритет (P0/P1/P2), чтобы при дефиците времени было понятно, что делать первым.

Свяжите проверки с требованиями или критериями приёмки, чтобы показать покрытие.

Чек-лист: как писать так, чтобы он работал

Хороший чек-лист обычно:

сгруппирован по областям (экран, API-метод, роль пользователя)

содержит короткие формулировки проверок

отмечается результатом pass/fail и краткими заметками

Пример чек-листа

Баг-репорт: цель и принцип

Баг-репорт нужен, чтобы команда могла:

воспроизвести проблему

понять факты (что ожидали и что получили)

оценить серьёзность и принять решение по исправлению

Хороший баг-репорт — это не эмоции и не обвинения, а точная инструкция и наблюдения.

Терминологию дефектов и ошибок удобно сверять с ISTQB Glossary.

Структура баг-репорта

Поля могут отличаться в трекерах, но смысл обычно одинаковый.

Обязательный минимум

Заголовок: коротко и конкретно, что сломано и где

Окружение: стенд, версия, браузер/ОС, устройство

Шаги воспроизведения: нумерованный список действий

Фактический результат: что произошло

Ожидаемый результат: как должно быть

Очень желательно добавить

Частота: всегда, иногда, 1 раз из 10

Серьёзность: насколько сильно ломает работу (например, блокер/крит/мажор/минор)

Приоритет: насколько срочно исправлять (это часто продуктовая договорённость)

Вложения: скриншоты, видео, логи, HAR, тело запроса/ответа API

Тестовые данные: какой пользователь, какой заказ, какой промокод

Важно различать:

серьёзность как технический/пользовательский ущерб

приоритет как очередность исправления с точки зрения планов релиза

Как писать шаги воспроизведения

Шаги должны быть:

достаточными, чтобы другой человек повторил проблему

короткими и без лишних действий

с указанием конкретных данных, если без них не воспроизводится

Если проблема зависит от состояния системы, это нужно вынести в предусловия:

пользователь с ролью manager

есть заказ в статусе Создан

включён флаг функции (feature flag)

Пример баг-репорта

Антипаттерны в тестовой документации

В тест-кейсах

шаги зависят от «интуиции» и не воспроизводимы

ожидаемый результат расплывчатый

кейс проверяет сразу много несвязанных вещей

нет данных и предусловий, без которых тест не повторить

В баг-репортах

нет конкретных шагов воспроизведения

не указано окружение и версия

смешаны факты и предположения (например, «сломалась база» без доказательств)

нет ожидаемого результата (непонятно, что считать дефектом)

Покрытие и трассируемость: как показать, что вы проверили нужное

В прошлой статье мы говорили о покрытии требований и рисков. Практически это часто решают связями:

требование или критерий приёмки → тест(ы)

риск → тест(ы)

Простой формат матрицы покрытия можно вести даже в таблице.

| Требование или критерий | Риск | Тесты | Комментарий | |---|---|---|---| | Оплата картой доступна авторизованным | финансовые потери при ошибках оплаты | TC-PAY-001, TC-PAY-002 | добавить проверки двойного клика | | Пользователь без прав не видит чужие заказы | утечка данных | TC-ACL-003 | проверить через API и UI |

Ценность матрицы не в бюрократии, а в прозрачности:

что именно защищает релиз

что не покрыто и какой риск команда принимает осознанно

Практический вывод: как выбрать формат артефакта

Ориентир, который помогает новичкам:

если проверку нужно делать часто и одинаково, делайте тест-кейс

если нужно быстро покрыть область и понять состояние, делайте чек-лист

если нашли несоответствие, оформляйте баг-репорт так, чтобы его могли воспроизвести без вас

Итоги

Чек-лист фиксирует что проверить, тест-кейс фиксирует как проверить и что ожидать.

Хорошие тест-кейсы содержат предусловия, данные, шаги и проверяемый ожидаемый результат.

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

Связь тестов с требованиями и рисками делает покрытие прозрачным и помогает принимать релизные решения.

Инструменты QA и процессы: Agile/Scrum, Git, CI/CD, трекинг задач

В прошлых темах курса мы разобрали, как QA встроен в SDLC/STLC, какие бывают стратегии тестирования, как применять тест-дизайн и как оформлять тестовую документацию (чек-листы, тест-кейсы, баг-репорты).

Следующий шаг до уровня уверенного QA — понимать, в каких процессах и инструментах живёт команда каждый день. Даже сильные проверки «не взлетают», если QA не умеет:

работать в Agile-процессе (Scrum или его вариациях)

ориентироваться в Git (хотя бы на уровне чтения изменений)

понимать, как работает CI/CD и где смотреть результаты прогонов

использовать трекер задач для коммуникации, статусов и прозрачности

Эта статья — практическая карта: что это такое, какие термины нужны новичку, и что именно делает QA.

Agile и Scrum: как команда организует работу

Agile: что это и что важно QA

Agile — это подход к разработке, где ценность доставляется небольшими итерациями, а команда регулярно получает обратную связь и адаптируется.

Ориентир по ценностям — Agile Manifesto.

Для QA это означает:

требования могут уточняться по ходу работы

тестирование идёт параллельно разработке, а не «после всего»

важно быстро давать обратную связь о рисках и качестве

Scrum: роли, артефакты, события

Scrum — популярный фреймворк внутри Agile. Официальный источник — Scrum Guide.

#### Роли

Product Owner: отвечает за ценность продукта и приоритеты.

Developers: команда, которая делает инкремент (включая разработку, тестирование, аналитику внутри команды — как договорились).

Scrum Master: помогает процессу, убирает препятствия.

Важно: в Scrum нет отдельной «официальной» роли QA, но в реальности QA часто входит в команду как специалист по качеству.

#### Артефакты

Product Backlog: список всего, что может понадобиться продукту.

Sprint Backlog: что команда берёт в текущий спринт.

Increment: готовый результат спринта, соответствующий Definition of Done.

#### События

Sprint Planning: планирование спринта.

Daily Scrum: синхронизация команды.

Sprint Review: показ результата и сбор обратной связи.

Sprint Retrospective: улучшение процесса.

!Круговой цикл Scrum и ключевые артефакты

User Story и критерии приёмки

В Agile требования часто формулируют как user story (пользовательская история): короткое описание ценности.

Пример:

«Как пользователь, я хочу сохранять адрес доставки, чтобы оформлять заказ быстрее»

Критерии приёмки (acceptance criteria) — это проверяемые условия, при которых история считается выполненной. Они напрямую связываются с тем, что мы делали в прошлых статьях:

критерии приёмки → тестовые условия → проверки (чек-лист/тест-кейсы)

Definition of Ready и Definition of Done

Чтобы избежать хаоса, команда часто договаривается о двух «контрактах».

Definition of Ready (DoR): когда задача готова к взятию в работу.

Definition of Done (DoD): когда задача действительно сделана и её можно считать частью инкремента.

Примеры того, что часто важно QA в DoR:

понятные критерии приёмки

макеты или описание UI

согласованные изменения API/контрактов

известные ограничения и допущения

Примеры того, что часто важно QA в DoD:

функциональность реализована и прошла ревью

выполнены согласованные проверки (ручные и/или автоматические)

нет блокирующих дефектов

обновлена тестовая документация, если она нужна для регресса

Что делает QA в Scrum на практике

На planning уточняет критерии приёмки, риски, тестируемость.

В течение спринта поддерживает быстрый фидбэк: sanity, проверка фиксов, целевой регресс вокруг изменений.

На review помогает подтвердить, что результат соответствует ожиданиям.

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

Git для QA: зачем и что нужно уметь

Git — система контроля версий, которая хранит историю изменений и позволяет работать с ветками.

Официальная справка: Git Documentation.

Зачем QA знать Git

понимать, что именно изменилось в релизе или задаче

находить, где могли появиться побочные эффекты

ориентироваться в версиях: какой коммит ушёл на стенд, какой в релиз

скачивать проект или тестовые артефакты, если так устроено в команде

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

Базовые понятия Git

Repository (репозиторий): папка проекта с историей изменений.

Commit (коммит): сохранённый набор изменений с сообщением.

Branch (ветка): независимая линия разработки.

Merge / Rebase: способы объединения изменений.

Pull Request / Merge Request: запрос на слияние изменений с ревью.

Tag (тег): метка версии, часто используется для релизов.

Минимальный набор действий QA

посмотреть историю и состав релиза по коммитам

открыть Pull Request и прочитать список изменённых файлов

сравнить версии через diff

найти по репозиторию: конфиги, тестовые данные, документацию

Если в команде приняты релизные теги, QA может быстро связать:

версия на стенде → тег/коммит → список изменений → зона риска → план проверок

Ветки и релизы: типовые схемы

Схем ветвления много, но новичку важно понять идею:

есть место, где идёт активная разработка

есть способ собрать релиз из конкретного набора изменений

Типовые варианты:

короткоживущие feature-ветки и слияние через Pull Request

отдельная release-ветка для стабилизации перед выпуском

hotfix-ветка для срочных правок в продакшене

QA обычно включается в момент, когда изменения попали на тестовый стенд, но понимание веток помогает ответить на вопросы:

«это уже в сборке или ещё нет?»

«фикс точно попал в релизную ветку?»

CI/CD: как изменения превращаются в сборку и поставку

CI/CD — это практики и процессы автоматизации.

CI (Continuous Integration): частое объединение изменений и автоматическая проверка качества (сборка, тесты).

CD (Continuous Delivery/Deployment): доставка изменений в окружения (staging/production) с разной степенью автоматизации.

Хорошая обзорная статья: Continuous integration.

Типовая структура пайплайна

Пайплайн — это цепочка шагов, которая запускается по событию (например, коммит или Pull Request).

Типовые стадии:

сборка (build)

статические проверки (линтеры, анализ)

модульные тесты

интеграционные тесты

деплой на тестовый стенд

E2E/автотесты (UI и/или API)

публикация артефактов (логи, отчёты, сборка)

!Упрощённый CI/CD пайплайн и точки, где QA смотрит результаты

Что в CI/CD важно QA

где смотреть результаты прогонов: отчёты тестов, логи, артефакты сборки

что считается «красным»: падение сборки, падение тестов, ошибки деплоя

как отличить проблему продукта от проблемы окружения: например, недоступна база или истёк токен

как перезапустить прогон и что приложить в баг/тикет (ссылка на джобу, лог, версия)

Практический минимум коммуникации в команде:

ссылка на пайплайн/джобу

номер сборки или тег

список упавших тестов и их сообщения

шаг, на котором произошла ошибка (build, deploy, tests)

Quality Gates: «ворота качества»

Во многих командах часть стадий — это «гейты»: если они не пройдены, изменения не попадают дальше.

Примеры гейтов:

Pull Request нельзя смержить, пока не прошли CI проверки

деплой на staging не произойдёт при падении сборки

релиз на production требует ручного подтверждения

QA часто участвует в настройке договорённостей:

какие тесты обязательны для мержа

какой минимум проверок нужен перед релизом

что делаем с нестабильными тестами и нестабильной средой

Связь CI/CD с регрессом и тестовой документацией

Из предыдущих тем:

регресс нужен, чтобы изменения не ломали старое

тест-кейсы нужны для повторяемости критичных сценариев

CI/CD помогает сделать это регулярным:

часть регресса автоматизируется и запускается на каждый Pull Request или на nightly-прогоне

ручной регресс остаётся там, где автоматизация пока невыгодна или нестабильна

Трекинг задач: как команда фиксирует работу и дефекты

Трекер задач — это единое место, где живут:

требования (user story)

технические задачи

баги

статусы работ

обсуждения и решения

Популярные примеры: Jira, YouTrack.

Типовые сущности в трекере

Epic: крупная цель/фича.

Story: пользовательская история.

Task: задача на реализацию.

Bug: дефект.

Sub-task: подзадача.

Команды называют сущности по-разному, но идея одна: от целей к конкретным действиям.

Workflow: статусы и переходы

Workflow — это жизненный цикл задачи в трекере.

Типовой пример:

To Do → In Progress → Code Review → Ready for QA → Testing → Done

Важная часть работы QA — корректные переходы и прозрачность:

не переводить задачу в Done, пока не выполнен DoD

фиксировать, что именно проверено, и что осталось риском

не «терять» дефекты: баг должен иметь владельца и понятный статус

Связь трекера с баг-репортами и тестами

Из статьи про баг-репорты:

хороший баг — это воспроизводимость и факты

Трекер помогает сделать это командным стандартом:

баг привязан к версии/сборке

баг привязан к задаче или Pull Request

баг содержит вложения: логи, видео, скриншоты, ссылки на CI

в задаче есть ссылка на тест-кейсы/чек-лист или краткое описание покрытия

Триаж дефектов: как принимаются решения

Триаж — разбор дефектов и принятие решений: исправляем сейчас, переносим, отклоняем как не баг.

На триаже обычно обсуждают:

серьёзность (насколько ломает пользователя/систему)

приоритет (насколько срочно исправлять в контексте релиза)

риск и влияние на критические потоки

наличие обходного пути

QA помогает тем, что приносит факты:

шаги воспроизведения

частоту

влияние на пользователей и данные

результаты дополнительных проверок (регресс вокруг области)

Практическая связка: как это выглядит в одной задаче

Ниже — типовой поток работы, который объединяет всё из статьи и предыдущих тем курса.

В трекере появляется story с критериями приёмки.

На planning QA уточняет требования, риски и тестируемость.

Разработчик делает изменения в feature-ветке и открывает Pull Request.

CI запускает сборку и тесты, появляются отчёты.

Изменения деплоятся на стенд, задача переходит в Ready for QA.

QA проектирует проверки (тест-дизайн) и фиксирует нужное в чек-листе/кейсах.

QA выполняет тестирование: sanity по изменению + проверки интеграций + целевой регресс.

Если найден дефект, QA заводит bug в трекере и прикладывает факты, включая ссылку на CI или версию сборки.

После фикса QA делает ретест и при необходимости регресс.

На review команда показывает инкремент, на ретро улучшает процесс.

Типичные ошибки новичков

Пытаться тестировать «в вакууме», не смотря на критерии приёмки, DoD и статусы.

Игнорировать CI результаты и тратить время на тестирование заведомо сломанной сборки.

Заводить баги без версии/окружения и без ссылок на логи или пайплайн.

Не проверять, что фикс реально попал в нужную ветку/сборку.

Путать приоритет и серьёзность и спорить «на ощущениях», а не на фактах.

Итоги

Agile/Scrum задаёт ритм и правила коммуникации; QA помогает сделать требования тестируемыми и поддерживает быстрый цикл обратной связи.

Git помогает связать изменения с рисками и понять состав релиза; QA полезно уметь читать diff и ориентироваться в версиях.

CI/CD автоматизирует сборку, проверки и деплой; QA должен уметь читать результаты прогонов и приносить факты.

Трекер задач — центр прозрачности: там живут требования, статусы, баги и связи с тестами.

Дальше в практике курса эти инструменты будут использоваться вместе: от story и критериев приёмки — к тестам, прогонам в CI и оформлению дефектов в трекере.

Тестирование API и основы работы с базами данных (SQL)

В предыдущих темах курса мы разобрали роль QA в SDLC/STLC, виды и стратегии тестирования, тест-дизайн и тестовую документацию, а также основные процессы и инструменты (Agile/Scrum, Git, CI/CD, трекеры задач).

Следующий важный шаг к уверенной практике QA — уметь тестировать API и понимать основы работы с базами данных через SQL. Это даёт два больших преимущества:

вы можете проверять продукт быстрее и глубже, чем только через UI

вы можете подтверждать факты: что реально сохранилось в базе, какие статусы и записи создались, почему система ведёт себя так

Эта статья даст практическую базу:

что такое API и как устроены HTTP-запросы и ответы

что и как проверять в API (функционально и нефункционально)

какие инструменты чаще всего используются (Postman, Swagger, curl)

основы SQL, которые нужны QA: чтение данных, простые изменения в тестовых средах, проверка эффектов API

!Схема взаимодействия API с базой данных и точек контроля для QA

Что такое API и зачем QA его тестирует

API (Application Programming Interface) — это интерфейс, через который одна программа взаимодействует с другой. В веб-разработке чаще всего QA сталкивается с HTTP API: клиент (веб/мобильное приложение) отправляет HTTP-запросы на сервер и получает ответы.

Зачем API тестировать отдельно от UI:

API обычно стабильнее UI и быстрее для проверок

через API проще воспроизводить дефекты и проверять негативные сценарии

многие дефекты живут на уровне бизнес-логики и данных, а UI лишь показывает последствия

API тесты хорошо автоматизируются и часто входят в CI

Термины и основы HTTP удобно сверять по справке: HTTP (MDN).

Как устроен HTTP-запрос и ответ

Из чего состоит HTTP-запрос

Обычно запрос включает:

Метод: что хотим сделать с ресурсом

URL: адрес ресурса и параметры

Заголовки (headers): метаданные (тип данных, авторизация, корреляция)

Тело (body): данные, которые отправляем (часто JSON)

Из чего состоит HTTP-ответ

Ответ обычно включает:

Статус-код: результат обработки

Заголовки: метаданные ответа

Тело: данные (часто JSON) или описание ошибки

Частые HTTP-методы

| Метод | Идея | Типичный пример | |---|---|---| | GET | получить данные | получить список заказов | | POST | создать сущность или запустить операцию | создать заказ | | PUT | заменить сущность целиком | полностью обновить профиль | | PATCH | частично обновить | поменять только телефон | | DELETE | удалить | удалить адрес доставки |

Справка по методам: HTTP request methods (MDN).

Популярные статус-коды

| Код | Значение | Что важно QA | |---:|---|---| | 200 | OK | успешный ответ с данными | | 201 | Created | сущность создана; часто возвращают id | | 204 | No Content | успешно, но тело пустое | | 400 | Bad Request | ошибка валидации, формат запроса неверный | | 401 | Unauthorized | нет авторизации или она неверная | | 403 | Forbidden | авторизован, но нет прав | | 404 | Not Found | ресурса нет или недоступен по id | | 409 | Conflict | конфликт состояния, дубль, гонка | | 429 | Too Many Requests | лимиты/рейты | | 500 | Internal Server Error | ошибка сервера, часто дефект или проблема окружения |

Важно: одинаковый статус-код в разных продуктах может означать немного разное, поэтому QA всегда опирается на контракт API и договорённости команды.

REST и контракты API

Часто (не всегда) HTTP API построено в стиле REST: ресурсы имеют URL, а операции описываются методами.

Ключевая идея для QA: у API должен быть контракт.

Распространённый формат описания контракта — OpenAPI (часто его называют Swagger).

контракт фиксирует эндпоинты, методы, схемы запросов и ответов

QA использует контракт как источник ожиданий: что считается корректным запросом и корректным ответом

Официальная спецификация: OpenAPI Specification.

Инструменты для тестирования API

Postman

Postman полезен для ручного тестирования:

коллекции запросов и окружения (dev/stage)

переменные, pre-request scripts и базовые автопроверки

импорт OpenAPI

Официальный сайт: Postman.

Swagger UI

Swagger UI часто разворачивают вместе с сервисом:

можно увидеть список эндпоинтов

попробовать запросы в браузере

быстро сверить схемы

curl

curl полезен, когда нужно:

быстро повторить запрос в терминале

приложить в баг-репорт точную команду

проверить проблему вне Postman

Документация: curl.

Пример запроса:

Что именно проверять в API

Ниже — практический чек-лист того, что QA обычно проверяет в API. Логику приоритизации берём из прошлых тем: сначала критические потоки и риски.

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

Статус-код соответствует сценарию

Тело ответа соответствует контракту

- типы полей - обязательность полей - корректность форматов (дата, валюта)

Смысл данных корректен

- бизнес-правила (например, сумма заказа равна сумме позиций) - корректные статусы

Проверки входных данных и валидаций

Для каждого важного поля полезно применить техники тест-дизайна из прошлой статьи:

классы эквивалентности: валидные и невалидные группы значений

граничные значения: минимумы, максимумы, пустые строки

Пример негативных проверок для POST /users:

пустое обязательное поле email

некорректный формат email

слишком длинное значение

неожиданный тип данных (строка вместо числа)

Ожидаемое поведение должно быть конкретным: статус-код, структура ошибки, тексты/коды ошибок по стандарту команды.

Проверки авторизации и прав доступа

Важно различать:

401: пользователь не авторизован

403: пользователь авторизован, но действие запрещено

Типовые проверки:

запрос без токена

запрос с просроченным токеном

запрос пользователя без нужной роли

попытка доступа к чужим данным по id

Если хотите системно ориентироваться в рисках API, полезный источник: OWASP API Security Top 10.

Проверки идемпотентности и повторов

Идемпотентность означает: повторный запрос не должен приводить к нежелательным побочным эффектам.

Примеры рисков:

повторный POST создаёт дубль заказа

повторное нажатие кнопки оплаты создаёт два платежа

Что делает QA:

повторяет запросы

симулирует тайм-аут (когда клиент не получил ответ и повторил)

проверяет, как система защищается от дублей (например, через idempotency key)

Проверки пагинации, сортировки и фильтров

Это частая зона дефектов, особенно при больших объёмах данных.

Что проверять:

limit и offset или cursor работают ожидаемо

сортировка стабильна и корректна

фильтр действительно фильтрует, а не игнорируется

крайние случаи: пустая выдача, последняя страница

Проверки обработки ошибок

Система должна ошибаться предсказуемо.

Хорошая практика для API:

единый формат ошибок

понятные коды ошибок для клиента

отсутствие лишних технических деталей в ответе

QA фиксирует ожидания в тест-кейсах/чек-листах и в баг-репортах прикладывает:

URL

метод

заголовки (без секретов)

тело запроса

тело ответа

статус-код

Нефункциональные проверки на уровне API

Даже на базовом уровне QA полезно помнить о нефункциональных рисках:

производительность: время ответа на типовых запросах

стабильность: нет ли периодических 5xx

лимиты: размер запроса, rate limiting (429)

безопасность: отсутствие утечек данных, корректные права

Глубокое нагрузочное и security-тестирование обычно выделяют отдельно, но базовые наблюдения QA на API-уровне очень ценны.

Мини-пример: как выглядит тестирование одного эндпоинта

Представим эндпоинт POST /v1/orders, который создаёт заказ.

Что QA обычно проверяет:

Успешное создание заказа

- статус 201 - в ответе есть orderId - созданный заказ доступен через GET /v1/orders/{orderId}

Валидации

- пустая корзина - отрицательное количество - невалидный адрес

Права доступа

- неавторизованный пользователь

Защита от дублей

- повтор того же запроса

Пример запроса и ответа в формате, удобном для баг-репорта:

Зачем QA нужен SQL

API-тестирование часто упирается в вопрос: что реально произошло с данными.

SQL помогает QA:

проверять эффекты запросов (создалась ли запись, какой статус, какие поля)

готовить тестовые данные (в тестовой среде и по правилам команды)

быстро расследовать дефекты (например, почему UI показывает не то)

очищать данные после тестов (если разрешено)

Важно: доступ к базе и операции INSERT/UPDATE/DELETE обычно ограничены. В продакшене QA почти всегда работает только через согласованные каналы и с минимальными правами.

База данных: минимальные понятия

Чаще всего QA сталкивается с реляционными базами данных:

данные хранятся в таблицах

таблица состоит из строк (записей) и столбцов (полей)

связи между таблицами задаются ключами

Ключевые термины:

Primary key (первичный ключ): уникальный идентификатор строки (часто id)

Foreign key (внешний ключ): ссылка на запись в другой таблице (например, orders.user_id)

Constraint (ограничение): правило целостности (например, NOT NULL, уникальность)

Index (индекс): структура для ускорения поиска (может влиять на скорость запросов)

!Пример связи таблиц пользователей и заказов

SQL для QA: самые нужные команды

Ниже — базовые операции SQL, которые чаще всего нужны QA.

SELECT: чтение данных

Пример: найти заказ по id.

Что важно:

SELECT выбирает столбцы

FROM указывает таблицу

WHERE фильтрует строки

WHERE: фильтрация и осторожность

Очень частая ошибка новичков — выполнить запрос без WHERE и получить слишком много данных.

Пример: найти заказы пользователя за последние статусы.

ORDER BY и LIMIT: быстро смотреть последние изменения

JOIN: объединение таблиц

Когда данные разнесены по таблицам, вы связываете их через JOIN.

Что важно:

JOIN ... ON ... связывает таблицы по ключам

удобно использовать алиасы o, u

INSERT, UPDATE, DELETE: изменения данных

В тестовых средах иногда разрешают подготовку и очистку данных.

Добавление записи:

Обновление записи:

Удаление записи:

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

Транзакции: зачем QA знать базовую идею

Транзакция — это группа операций, которая выполняется как единое целое.

Типовая логика:

либо применяются все изменения

либо не применяется ничего (если случилась ошибка)

QA полезно знать это, чтобы понимать дефекты класса:

деньги списались, но заказ не создался

заказ создался, но позиции не привязались

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

Как связывать API и SQL в проверках

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

Пример подхода:

Вызвать API POST /v1/orders и получить orderId.

Проверить GET /v1/orders/{orderId}.

Проверить в базе:

- запись в orders создана - статус правильный - сумма total корректна - созданные позиции заказа лежат в таблице order_items (если она есть)

Пример проверки по orderId:

Важно: если API возвращает одно, а в базе другое, это сильный сигнал дефекта или асинхронной обработки.

Типичные проблемы, которые QA находит через API и SQL

рассинхронизация данных: UI показывает статус PAID, в БД CREATED

ошибки валидации: API принимает некорректные данные и сохраняет мусор

ошибки прав: пользователь получает чужие записи

дубли: два заказа на один запрос, два платежа

гонки и конкуренция: два параллельных запроса меняют статус некорректно

необработанные ошибки: 500 без понятного сообщения и без стабильного формата

Как оформлять баги по API и базе данных

Связь с предыдущей статьёй про баг-репорты:

цель — воспроизводимость и факты

Хороший баг по API обычно содержит:

эндпоинт, метод

окружение (staging, версия)

авторизация (тип, без секретов)

тело запроса

статус-код и тело ответа

фактические данные в базе (если доступно и разрешено)

Если вы прикладываете SQL-результаты:

не публикуйте персональные данные без необходимости

прикладывайте ровно те поля, которые доказывают проблему

Итоги

API-тестирование позволяет быстрее и точнее проверять бизнес-логику и данные, особенно в связке с тест-дизайном и риск-ориентированным подходом.

В HTTP важно понимать методы, статус-коды, структуру запросов и ответов, а также авторизацию и обработку ошибок.

Инструменты QA для API: Postman, Swagger UI, curl.

SQL даёт QA возможность проверять фактическое состояние данных и ускоряет расследование дефектов.

Базовый набор SQL для QA: SELECT, WHERE, ORDER BY, LIMIT, JOIN, и осторожно INSERT/UPDATE/DELETE в тестовых средах.

Basics of test automation and building a testing framework

Manual testing gives fast feedback and is indispensable for exploration, usability, and quickly validating new ideas. But as the product grows and releases become frequent, repeating the same checks manually becomes expensive and unreliable.

In previous course topics we covered:

how QA fits into SDLC/STLC and why shift-left matters

test levels, types, strategies, and how to prioritize by risk

test design techniques to build an effective set of checks

test documentation (checklists, test cases, bug reports)

tools and processes (Agile/Scrum, Git, CI/CD, tracking)

API testing and basic SQL to verify real data

This article connects those concepts to automation:

what test automation is and what it is not

what to automate first (and what not to automate)

how the test pyramid translates into an automation strategy

what a test framework consists of and how to structure it

how to keep automated tests stable, maintainable, and useful in CI

!Test pyramid: why most automated checks should be on lower levels

What test automation really means

Test automation is the practice of using code and tools to execute checks automatically and report results without manual steps.

Automation is valuable when it:

runs frequently (every commit, every pull request, nightly)

provides fast feedback to developers and QA

catches regressions in critical behavior

makes results repeatable and traceable (reports, logs, artifacts)

Automation is not a replacement for QA thinking. You still need:

good test design (what scenarios matter)

risk-based priorities (what is worth automating)

clear expected results (what is considered correct)

What to automate first (and what not to automate)

A practical beginner rule: automate checks that are frequent, stable, and high value.

Great candidates for automation

smoke checks that confirm the build is usable

critical user flows that must never break (login, checkout, payments)

API regression checks for core business rules

input validation checks that are easy to data-drive

permissions and access control checks at the API level

Poor candidates (at least at the beginning)

unstable UI areas that change every sprint

tests that depend on external systems you cannot control

rare one-off scenarios that are unlikely to be repeated

checks where the expected result is subjective (visual design, “looks good”)

A useful mindset: automation is an investment. If a test is costly to maintain and rarely finds issues, it is usually a bad investment.

Automation strategy and the test pyramid

In the “Testing: levels, types, strategies and approaches” topic, we discussed levels of testing. Automation follows the same logic:

Unit tests (usually written by developers): cheapest and fastest feedback

Integration/API tests: validate contracts, business rules, and services interaction

UI end-to-end tests: validate the full user journey, but are slower and more fragile

This is often summarized as the test pyramid. A widely referenced explanation is Martin Fowler’s article: The Practical Test Pyramid.

A typical healthy balance:

many unit tests

some integration and API tests

a small number of UI end-to-end tests for the most critical flows

For QA Engineers, API tests are often the best entry point into automation because they are faster and more stable than UI tests while still validating real business behavior.

Key terms you must know

Test framework: a structured codebase that makes writing, running, and maintaining automated tests consistent.

Test runner: tool that discovers tests, runs them, and reports results (for example, pytest, JUnit).

Assertion: a check that compares actual to expected.

Test suite: a collection of tests.

Test fixture: setup/teardown logic used by tests (create user, clean database, start browser).

Flaky test: a test that sometimes fails and sometimes passes without a product change.

If terminology differs across sources, use the reference glossary: ISTQB Glossary.

What a good test framework contains

A framework is not “just tests”. It is the infrastructure that keeps tests readable and maintainable.

Minimum components

test runner and assertions

project structure (where tests and support code live)

configuration management (environments, URLs, credentials)

test data strategy (how to create and clean data)

reporting (what happened, how to debug failures)

Very common additions

logging with correlation identifiers

screenshots and videos for UI failures

API client wrappers (reusable request logic)

reusable UI page objects or components

tagging (smoke, regression, critical)

CI integration (run on pull request, generate artifacts)

Choosing tools: a realistic beginner stack

Tool choice depends on your team, product, and language. What matters is understanding roles of tools.

For UI automation

Playwright: modern cross-browser automation with good auto-waiting and debugging tools: Playwright

Selenium WebDriver: classic industry standard with huge ecosystem: Selenium

Cypress: popular for web apps, good developer experience: Cypress

For API automation

language HTTP clients (for example, Python requests, Java clients)

contract as a reference (OpenAPI)

For test execution

Python: pytest pytest

Java: JUnit 5 JUnit 5 User Guide

A good starting point is to pick one language and one runner, then add UI and API layers gradually.

Designing an automation-friendly framework structure

The goal is simple: tests should read like business checks, while support code hides technical details.

A common structure (language-agnostic):

tests/

- ui/ - api/ - smoke/

pages/ or ui/

- page objects or UI components

clients/

- API client wrappers

fixtures/

- setup/teardown helpers (users, cleanup)

config/

- environment settings

utils/

- logging, random data, helpers

This separation prevents a typical beginner problem: putting everything into test files until they become unmaintainable.

!Typical test framework structure and dependencies

A maintainable UI layer: Page Object Model

UI tests break frequently because UI changes frequently. The Page Object Model reduces maintenance by keeping selectors and UI operations in one place.

Core idea:

tests should call methods like login_as(user)

page objects should contain selectors and UI actions

This improves:

readability

reuse

stability when UI changes

But do not over-engineer: keep page objects focused on what users do, not on every tiny UI element.

A maintainable API layer: client wrappers

For API tests, you typically do not want to repeat:

base URL logic

authorization headers

common error handling

A simple API client wrapper helps tests stay short and focused on assertions.

Example: a small API test in Python (pytest)

This is a minimal illustration of a readable check.

What makes this “framework-ready”:

base_url and auth_token are fixtures, not hardcoded

timeout is explicit

assertions are simple and focused

Example: a small UI test idea (Playwright)

UI automation usually requires more infrastructure (browser setup, waits, artifacts). Playwright includes strong built-in waiting.

Even with good tools, UI tests must be kept small in number and focused on critical flows.

Test data and environment strategy

Automation fails most often not because of assertions, but because of data and environment issues.

Choose one of these approaches (or combine them):

create test data via API calls (fast and realistic)

create data via database scripts (powerful but risky and permission-dependent)

use isolated test accounts with cleanup

Key rules:

tests should not depend on “random existing data”

tests should clean up what they create, or create data in an isolated scope

tests should be able to run in parallel without interfering

Making tests stable: how to fight flakiness

Flaky tests destroy trust. If engineers stop believing test results, automation becomes noise.

Typical flakiness causes:

timing issues (no waiting for async UI updates)

unstable selectors (CSS classes that change)

shared state (tests using the same user/order)

environment instability (deploy in progress, broken test DB)

external dependencies (third-party services)

Practical solutions:

prefer stable selectors (roles, labels, data-testid if your team uses it)

use explicit waiting for meaningful states, not sleep

isolate data per test (unique user/order identifiers)

retry only when you have a strong reason, and track retry rate

separate “product failures” from “infrastructure failures” in reports

Reporting and debugging: treat failures as investigations

When a test fails in CI, you need enough evidence to debug quickly.

A good framework typically stores:

logs with timestamps

request and response details for API tests (without secrets)

screenshots on UI failures

videos or traces (if supported)

environment info (build number, commit, URL)

This connects directly to what you learned about bug reports: automation should produce facts that make issues reproducible.

CI integration: automation becomes valuable when it runs continuously

Automation has maximum impact when it is part of CI/CD, covered in the “Tools and processes” topic.

A typical setup:

run fast checks on every pull request (smoke, core API tests)

run deeper suites on schedule (nightly regression)

store test reports and artifacts as CI build artifacts

A popular CI option is GitHub Actions: GitHub Actions Documentation.

Quality gates and release decisions

Automation results should support release decisions rather than block releases blindly.

A practical approach:

define a stable smoke suite as a gate

track flaky tests separately and fix or remove them

agree on exit criteria, as discussed in STLC: what must pass to consider a release candidate acceptable

Common beginner mistakes

automating unstable UI before stabilizing API checks

writing tests that do many unrelated assertions

hardcoding URLs, credentials, and data

making tests depend on execution order

ignoring test maintainability and readability

Summary

Automation is a risk-reduction tool that provides fast, repeatable feedback.

Use the test pyramid mindset: prioritize unit and API/integration checks, keep UI end-to-end small and critical.

A framework is more than tests: structure, configuration, fixtures, data strategy, and reporting.

Stability matters as much as coverage: fight flakiness with good selectors, meaningful waits, and isolated data.

CI integration turns automation into a continuous quality signal for the whole team.