QA тестирование: основы и практика

Роль QA и основы качества в разработке ПО

Качество в ПО не возникает «само» после добавления пары тест-кейсов. Оно формируется на протяжении всего жизненного цикла продукта: от идеи и требований до разработки, релиза и поддержки. В этом процессе QA (Quality Assurance) помогает команде выстроить подход, при котором дефекты предотвращаются, а риски становятся управляемыми.

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

Что такое качество ПО

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

Важно понимать два слоя качества:

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

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

Существует общепринятая модель качества, описывающая характеристики ПО: ISO/IEC 25010. Она полезна QA тем, что помогает не забыть про «нефункциональную» часть качества (производительность, безопасность и т.д.).

Источник: ISO/IEC 25010 на Википедии

Ниже — примеры характеристик качества, о которых QA часто думает при тестировании и обсуждении требований.

| Характеристика | Что означает простыми словами | Пример вопроса QA | |---|---|---| | Функциональная пригодность | Функции работают как нужно | «Поиск реально находит то, что должен?» | | Надёжность | Система стабильно работает и восстанавливается после сбоев | «Что будет, если оборвётся сеть на оплате?» | | Удобство использования | Пользователю понятно и комфортно | «Можно ли выполнить сценарий без подсказок?» | | Производительность | Время ответа и ресурсы в норме | «Откроется ли каталог за 2 секунды при нагрузке?» | | Безопасность | Защита данных и доступа | «Можно ли получить чужие данные через URL/ID?» | | Совместимость | Работает в нужных окружениях и интеграциях | «В Safari всё так же, как в Chrome?» | | Сопровождаемость | Легко менять и развивать | «Насколько рискованно это изменение для соседних модулей?» |

QA, QC и тестирование: различия

В командах часто смешивают термины QA, QC и тестирование. Для новичка важно развести их по смыслу.

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

QC (Quality Control) — продукт-ориентированная проверка: контроль качества конкретного результата (сборки, фичи).

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

Определения терминов можно сверять в глоссарии ISTQB.

Источник: ISTQB Glossary

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

| Термин | Основной фокус | Цель | Примеры | |---|---|---|---| | QA | Процессы и предотвращение проблем | Сделать качество системным | договорённости о Definition of Done, ревью требований, улучшение процесса релизов | | QC | Контроль результата | Найти дефекты в конкретном артефакте | проверка сборки перед релизом, приёмка фичи | | Тестирование | Проверки и эксперименты | Обнаружить дефекты и снизить риски | тест-дизайн, выполнение тестов, автоматизация регрессии |

Где QA находится в жизненном цикле разработки

QA эффективнее всего работает не «в конце», а везде, где принимаются решения, влияющие на продукт.

Типичные этапы (упрощённо):

Идея и цели продукта

Требования и аналитика

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

Разработка

Тестирование и стабилизация

Релиз

Эксплуатация и поддержка

На каждом этапе у QA есть вклад:

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

На этапе проектирования — обращать внимание на риски: безопасность, производительность, логирование, возможность диагностики.

Во время разработки — поддерживать быстрый фидбек: смоук, проверка фич по мере готовности, участие в code review по рисковым местам (по договорённости в команде).

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

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

!Схема показывает, что QA участвует на всех этапах SDLC, а не только на этапе «тестирования».

Основные принципы работы QA

Ниже — базовые принципы, которые отличают профессиональный QA-подход от хаотичных «потыкали и вроде норм».

Профилактика дефектов важнее охоты на дефекты

Ранний и частый фидбек: чем раньше найден риск, тем дешевле исправление

Риск-ориентированность: тестируем не «всё подряд», а в приоритете то, что может сильнее навредить

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

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

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

Отдельно полезно помнить ценности гибкой разработки: качество — часть совместной ответственности команды.

Источник: Agile Manifesto

Артефакты и результаты работы QA

QA создаёт не только баг-репорты. Ценность QA — в информации, которая помогает принимать решения.

Частые артефакты QA:

Тест-стратегия: общий подход к качеству на проекте (что, как и где проверяем)

Тест-план: план конкретного тестирования (объём, сроки, ресурсы, риски)

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

Тест-кейсы: детальные сценарии (когда нужна строгая воспроизводимость)

Отчёт о тестировании: что сделано, что найдено, какие риски остались

Баг-репорты: формализованное описание дефекта

Минимально полезная структура баг-репорта (часто достаточно именно этого):

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

Окружение: версия, платформа, браузер/устройство, конфигурация

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

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

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

Вложения: скриншоты, видео, логи, данные тестового аккаунта (если уместно)

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

Роль QA в команде и коммуникации

QA постоянно взаимодействует со всеми ролями:

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

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

С дизайном: проверка UX-ожиданий, консистентность интерфейса

С DevOps/инфраструктурой: тестовые окружения, стабильность стендов, CI/CD, логирование

С поддержкой: анализ обращений пользователей и инцидентов, воспроизведение проблем

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

Минимальный набор навыков начинающего QA

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

Понимание жизненного цикла разработки и роли тестирования

Умение читать требования и задавать уточняющие вопросы

Базовый тест-дизайн: как придумывать проверки, а не «угадывать»

Умение оформлять баг-репорты так, чтобы их можно было быстро исправить

Основы веба: клиент-сервер, HTTP, cookies/session (на уровне понимания)

Базовый SQL (простые SELECT) и работа с тестовыми данными

Что дальше в курсе

Дальше логично перейти от роли QA к практике:

виды тестирования и уровни (смоук, регрессия, интеграционное и т.д.)

техники тест-дизайна (эквивалентные классы, граничные значения)

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

баг-репорты и жизненный цикл дефекта

основы тестирования веба и API

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

Жизненный цикл разработки и место тестирования (SDLC/STLC)

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

В индустрии для этого часто используют два понятия:

SDLC (Software Development Life Cycle) — жизненный цикл разработки ПО, то есть этапы, через которые проходит продукт от идеи до поддержки.

STLC (Software Testing Life Cycle) — жизненный цикл тестирования, то есть этапы работы тестирования внутри разработки.

Важно: SDLC — про создание продукта, STLC — про проверку качества и снижение рисков в рамках SDLC.

Что такое SDLC

SDLC описывает общий процесс создания и развития программного продукта. Конкретные названия и границы этапов могут отличаться в компаниях, но логика обычно похожа.

Типичные этапы SDLC:

Инициирование и цели

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

Проектирование решения (архитектура, UX/UI, контракты интеграций)

Разработка (код, ревью, сборка)

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

Релиз и поставка (выкатка, миграции)

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

Роль QA в SDLC — помогать команде принимать решения на каждом этапе так, чтобы итоговое качество было предсказуемым, а риски — понятными и контролируемыми.

Источник терминов и базовых определений можно сверять в глоссарии ISTQB: ISTQB Glossary

Популярные модели SDLC и их влияние на тестирование

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

Каскадная модель (Waterfall)

Логика: этапы идут последовательно, следующий начинается после завершения предыдущего.

Особенности для тестирования:

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

Много формальной документации, а тесты чаще опираются на спецификации.

Риски:

Если требования были неполными или неверными, это станет ясно ближе к концу.

V-модель

V-модель — развитие каскадной идеи, где каждому этапу разработки соответствует этап проверок.

Пример соответствий:

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

Системный дизайн ↔ системное тестирование

Архитектура/модули ↔ интеграционное тестирование

Код ↔ модульное тестирование

Что это даёт QA:

Упор на раннее планирование проверок и критериев приёмки.

Чёткая связь: что спроектировали — то должны уметь проверить.

Итеративная/инкрементальная разработка и Agile

Логика: продукт развивается небольшими частями (инкрементами) в коротких циклах (итерациях). Требования уточняются по ходу.

Особенности для тестирования:

Тестирование идёт параллельно разработке и начинается раньше.

Много быстрых проверок: смоук, проверка фичи по готовности, частая регрессия по ключевым потокам.

Нужны договорённости о готовности работы, например Definition of Done.

Официальный источник по Scrum (одной из Agile-практик): Scrum Guide

Что такое STLC

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

Важно: STLC — не «раз и навсегда фиксированный стандарт». На реальном проекте этапы могут объединяться, упрощаться или выполняться параллельно.

Классический набор этапов STLC:

Анализ тестируемых требований

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

Проектирование тестов (тест-кейсы/чек-листы, тестовые данные)

Подготовка тестового окружения

Выполнение тестов и заведение дефектов

Закрытие тестирования (итоги, отчётность, выводы)

!Инфографика показывает, что тестирование и QA-активности идут через весь SDLC, а не только в конце.

Подробно про этапы STLC и место QA

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

Задача QA — помочь сделать требования проверяемыми и однозначными.

Что обычно делает QA:

Уточняет сценарии пользователя: кто, что делает, какой результат ожидает.

Формулирует или помогает сформулировать критерии приёмки.

Ищет двусмысленности и «дыры»: исключения, ошибки, ограничения.

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

Результат: меньше сюрпризов на тестировании и релизе.

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

Это решение о том, что и как проверяем и какие риски принимаем.

Типичные элементы планирования:

Объект тестирования (что входит/не входит)

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

Приоритеты по рискам

Ресурсы и сроки

Критерии входа/выхода (когда начинаем и когда считаем достаточно)

Артефакты могут быть разными: от короткого плана на страницу до тест-стратегии.

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

На этом этапе QA превращает информацию из требований и рисков в конкретные проверки.

Варианты артефактов:

Чек-лист — список проверок (часто подходит для быстрых итераций)

Тест-кейс — детальный сценарий (нужен, когда важна строгая воспроизводимость)

Также здесь продумывают:

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

негативные сценарии (ошибки, неверный ввод)

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

Подготовка окружения

Окружение — это условия, где запускается продукт: стенд, база, конфигурации, интеграции.

Частые проблемы, которые QA помогает предотвращать:

«У меня не воспроизводится» из-за разных конфигураций

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

нестабильность стенда

Минимальная практика — фиксировать, где тестировали: версия сборки, URL стенда, роль пользователя, браузер/устройство.

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

Здесь QA выполняет проверки и даёт команде обратную связь.

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

смоук на сборке (быстро понять, что стенд живой)

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

регрессия (убедиться, что старое не сломалось)

повторная проверка исправлений (ретест)

Дефекты фиксируются в баг-трекере и проходят жизненный цикл: создан → в работе → исправлен → проверен → закрыт (варианты статусов зависят от процесса).

Закрытие тестирования

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

Что полезно иметь на выходе:

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

какие дефекты найдены (и какие ещё открыты)

какие риски остаются (например, не протестировали интеграцию из-за недоступности сервиса)

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

Как тестирование встраивается в SDLC: shift-left и shift-right

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

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

Shift-right — внимание к качеству после релиза: мониторинг, метрики, алерты, анализ ошибок, A/B эксперименты.

Для QA это означает: качество — не только про тестовый стенд, но и про продакшен-сигналы.

Уровни тестирования и где они живут в SDLC

Чтобы не путать «виды» и «уровни», полезно разделять:

Уровни тестирования — на каком уровне системы проверяем (модуль, интеграция, система, приёмка).

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

Классические уровни:

Модульное (unit) — проверка маленьких частей кода (чаще делает разработчик)

Интеграционное — проверка взаимодействия компонентов и сервисов

Системное — проверка системы целиком

Приёмочное — подтверждение, что продукт готов с точки зрения бизнеса/пользователя

QA должен понимать эти уровни, чтобы предлагать эффективные проверки: не всё имеет смысл ловить UI-тестами, многие дефекты дешевле находить на уровне API или интеграций.

Практический вывод для начинающего QA

Чтобы уверенно ориентироваться в проекте, держите в голове простую связку:

SDLC показывает, где сейчас команда и какие решения принимаются.

STLC помогает понять, какие шаги тестирования нужны и чего не хватает.

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

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

Техники тест-дизайна и выбор тестов

В прошлых статьях мы разобрали роль QA и то, как тестирование встраивается в SDLC через STLC. Теперь перейдём к практическому вопросу: как придумывать проверки системно и как выбирать ограниченное количество тестов так, чтобы они давали максимум пользы.

Тест-дизайн — это набор подходов, которые помогают:

превращать требования и риски в конкретные проверки

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

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

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

Почему «проверить всё» невозможно

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

разные значения полей

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

разные статусы объекта

разные интеграции и ошибки сети

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

Как выбирают тесты на практике

В STLC выбор тестов обычно происходит на этапах анализа требований, планирования и проектирования тестов. Типичные критерии выбора:

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

Частота использования: ключевые пользовательские потоки должны быть стабильными.

Сложность и новизна изменений: новое и сложное ломается чаще.

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

Требования и критерии приёмки: минимальный обязательный набор.

Ограничения: сроки, люди, окружения, доступность интеграций.

Практический вывод: хороший тест-набор — это не самый большой, а самый осмысленный.

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

Базовые артефакты: чек-лист и тест-кейс

Один и тот же тест-дизайн можно оформить по-разному.

Чек-лист — список проверок без строгих шагов. Удобен в быстрых итерациях и для исследовательского тестирования.

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

Выбор обычно такой:

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

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

Техники тест-дизайна

Ниже — основные техники, которые чаще всего применяются начинающими QA. Многие из них описаны в материалах ISTQB, например на странице сертификации CTFL: ISTQB CTFL.

Классы эквивалентности

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

Пример: поле Возраст допускает 18–65.

валидный класс: 18–65

невалидные классы: меньше 18, больше 65, не число, пусто

Минимально разумные тесты:

одно значение из валидного класса (например, 30)

по одному значению из каждого невалидного класса (например, 17, 66, abc, пусто)

Эта техника снижает объём тестов и помогает не забыть про негативные сценарии.

Анализ граничных значений

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

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

17, 18, 19

64, 65, 66

Как применять вместе с классами эквивалентности:

классы говорят какие группы есть

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

Таблицы решений

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

Пример: скидка в интернет-магазине.

Условия:

пользователь новый или существующий

сумма корзины больше или равна 3000 или меньше 3000

Действия:

скидка 10%

скидки нет

| Условия / Правила | Правило 1 | Правило 2 | Правило 3 | Правило 4 | |---|---:|---:|---:|---:| | Новый пользователь | Да | Да | Нет | Нет | | Сумма ≥ 3000 | Да | Нет | Да | Нет | | Ожидаемое действие | Скидка 10% | Скидки нет | Скидка 10% | Скидки нет |

Плюсы:

удобно обсуждать с аналитиком и продуктом

хорошо видно, какие комбинации покрыты

Тестирование переходов состояний

Состояние — это режим, в котором находится объект, и от которого зависит поведение.

Пример: заказ.

состояния: Создан → Оплачен → Отправлен → Доставлен → Отменён

переходы: какие смены состояния разрешены, а какие запрещены

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

корректные переходы (например, из Оплачен в Отправлен)

запрещённые переходы (например, из Доставлен обратно в Создан)

поведение на повторных действиях (например, повторная оплата)

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

Попарное тестирование (Pairwise)

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

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

Пример параметров для веб-приложения:

браузер: Chrome / Firefox / Safari

роль: user / admin

язык: ru / en

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

Подробнее о подходе: Pairwise testing.

Тестирование на основе сценариев (Use case)

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

основной поток (happy path)

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

ошибки и исключения

Эта техника хорошо связывает тестирование с ценностью для пользователя и помогает приоритизировать проверки.

Исследовательское тестирование и эвристики

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

Чтобы оно было управляемым, задают:

цель сессии (что изучаем)

ограничения по времени

заметки: что проверили, что нашли, какие вопросы возникли

Часто используют эвристики, например:

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

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

несовместимости (браузеры, разрешения экрана)

Как превратить требования в тесты: короткий алгоритм

Ниже — практичный маршрут, который связывает тест-дизайн со STLC.

Прочитайте требование и найдите объект тестирования (страница, API, бизнес-операция).

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

Определите основные пользовательские сценарии и исключения.

Выберите техники:

ввод и валидации: классы эквивалентности + границы

сложные правила: таблица решений

статусы и процессы: переходы состояний

много параметров: pairwise

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

Приоритизируйте тесты по риску и ценности.

Приоритизация: смоук, санити, регрессия

Эти наборы помогают выбирать тесты под разные цели.

| Набор | Цель | Когда использовать | Пример состава | |---|---|---|---| | Смоук (smoke) | Быстро понять, что сборка вообще рабочая | После выкладки на стенд, перед началом детального тестирования | логин, открывается главная, создаётся сущность, базовый API отвечает 200 | | Санити (sanity) | Быстро проверить конкретное изменение | После небольшого фикса/точечного изменения | проверки только затронутого модуля и критичных связей | | Регрессия (regression) | Убедиться, что старое не сломалось | Перед релизом, после больших изменений, периодически в спринтах | ключевые бизнес-потоки, критичные интеграции, зоны с историей дефектов |

Важно: эти наборы — не «виды тестирования», а практичные пакеты проверок под разные цели и ограничения.

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

Проверять только happy path и забывать про ошибки, пустые значения, прерывания.

Делать слишком много почти одинаковых тестов вместо классов эквивалентности.

Не проверять границы диапазонов.

Не учитывать состояния и переходы (особенно в процессах оплаты, доставки, модерации).

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

Не фиксировать, что именно не протестировано из-за ограничений.

Практический итог

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

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

сокращаете количество тестов без потери качества

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

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

Документация тестирования: тест-кейсы, чек-листы, отчёты

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

команда понимала, что именно проверяется и почему этого достаточно

проверки были повторяемыми (их можно воспроизвести)

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

Эту задачу решает документация тестирования: чек-листы, тест-кейсы и отчёты.

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

!Схема показывает, как требования превращаются в тесты и отчётность в рамках STLC

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

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

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

объяснить покрытие: какие требования и риски проверены, а какие нет

ускорить регрессию: не вспоминать заново, что важно проверить

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

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

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

Принципы хорошей документации

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

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

Актуальность: устаревшие тесты хуже, чем отсутствие тестов

Однозначность: минимизируйте трактовки, используйте точные шаги и данные

Атомарность: один тест — одна проверяемая идея (проще поддерживать и анализировать)

Тестируемость: ожидаемый результат должен быть проверяемым (что именно увидим в UI, ответе API, базе, логах)

Риск-ориентированность: чем выше риск, тем больше формальности обычно нужно

Чек-листы

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

Когда чек-лист лучше тест-кейса

нужно быстро проверить фичу в спринте

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

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

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

Как выглядит хороший чек-лист

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

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

включает позитивные и негативные проверки

не превращается в «роман» из подробных инструкций

Пример чек-листа для формы логина:

вход с валидными логином и паролем

ошибка при неверном пароле

ошибка при несуществующем пользователе

валидация пустых полей

обрезка/обработка пробелов в начале и конце

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

сохранение сессии и выход из аккаунта

Тест-кейсы

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

Когда тест-кейсы оправданы

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

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

проверки часто повторяются (регрессия)

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

нужно формальное подтверждение объёма проверок

Рекомендуемая структура тест-кейса

Минимально полезные поля:

ID: уникальный идентификатор

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

Предусловия: состояние системы до теста (роль, данные, настройки)

Шаги: что делает тестировщик

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

Тестовые данные: конкретные значения (если критично)

Дополнительно часто добавляют:

приоритет и тип (смоук, регрессия)

постусловия (что меняется после теста)

ссылки на требование/задачу

Пример тест-кейса в компактном виде:

| Поле | Значение | |---|---| | ID | AUTH-001 | | Название | Логин с валидными данными открывает личный кабинет | | Предусловия | Пользователь user1 существует и активен | | Данные | Логин: user1, пароль: P@ssw0rd | | Шаги | 1) Открыть страницу логина 2) Ввести логин и пароль 3) Нажать "Войти" | | Ожидаемый результат | Открывается личный кабинет, отображается имя пользователя, сессия активна |

Частые ошибки в тест-кейсах

шаги завязаны на лишние детали UI, которые часто меняются

нет конкретного ожидаемого результата (написано «всё ок»)

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

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

Как связать требования и тесты: трассируемость

Трассируемость — это связь между требованиями (или критериями приёмки) и тестами. Она помогает ответить на вопросы:

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

какие требования не протестированы

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

Простой способ — таблица соответствия (её часто называют матрицей трассируемости).

Пример:

| Требование / критерий приёмки | Тесты | Статус покрытия | |---|---|---| | AC-LOGIN-01: Валидный пользователь может войти | AUTH-001, AUTH-002 | Покрыто | | AC-LOGIN-02: 5 неудачных попыток блокируют вход на 15 минут | AUTH-010 | Покрыто частично | | AC-LOGIN-03: Сообщение об ошибке не раскрывает, существует ли пользователь | AUTH-011 | Не покрыто |

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

Отчёты о тестировании

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

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

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

тест-отчёт по прогону: что запускали, что прошло, что упало

итоговый отчёт (test summary report): сводка по релизу или итерации

Стандарты по тестированию и документации существуют, например семейство ISO для тестирования: ISO/IEC/IEEE 29119 на Википедии.

Что должно быть в итоговом отчёте

Хороший итоговый отчёт отвечает на вопрос можно ли выпускать и что мы знаем о качестве. Обычно включают:

объект тестирования: что именно тестировали (версия, сборка, стенд)

объём: какие модули/фичи входили и что было вне объёма

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

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

дефекты: количество и список критичных дефектов, статус исправления

остаточные риски: что не проверили и чем это может грозить

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

Пример шаблона итогового отчёта:

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

Это не выбор «что лучше», а выбор под задачу. Ниже — практичная шпаргалка.

| Критерий | Чек-лист | Тест-кейс | |---|---|---| | Скорость подготовки | Быстрее | Медленнее | | Повторяемость разными людьми | Средняя | Высокая | | Подходит для исследовательского тестирования | Да | Ограниченно | | Подходит для регрессии | Иногда | Да | | Удобство поддержания при частых изменениях | Обычно лучше | Обычно хуже | | Нужна доказательная база (аудит, комплаенс) | Редко | Часто |

Частая рабочая стратегия: чек-листы для текущих задач и исследований, тест-кейсы для стабильных и критичных регрессионных сценариев.

Поддержка документации на практике

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

обновляйте тесты вместе с изменением требований (часто это часть Definition of Done)

помечайте тесты тегами: smoke, regression, critical

регулярно чистите дубликаты и «мертвые» тесты

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

используйте единый стиль названий: действие + объект + ожидаемый эффект

Практический итог

Документация тестирования помогает сделать STLC управляемым:

чек-листы дают скорость и гибкость

тест-кейсы дают точность и повторяемость

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

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

Баг-репорты и работа с дефектами

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

Баг-репорт для QA — это не просто сообщение о проблеме. Это артефакт, который:

делает дефект воспроизводимым

объясняет влияние на пользователя и бизнес

помогает быстро локализовать проблему

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

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

Что такое дефект и баг-репорт

Дефект (defect) — это несоответствие продукта ожидаемому поведению. Ожидание может идти из требований, критериев приёмки, дизайна, стандарта или здравого смысла пользовательского сценария.

Баг-репорт (bug report) — оформленное описание дефекта, которое позволяет команде:

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

понять ожидаемое поведение

оценить серьёзность и приоритет

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

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

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

Запрос на улучшение (enhancement): поведение корректное, но хочется иначе.

Дефект: поведение некорректное относительно ожидания.

Зачем баг-репорт должен быть воспроизводимым

Если дефект нельзя воспроизвести, его почти невозможно надёжно исправить. Поэтому задача QA — дать минимум информации, который делает проблему повторяемой.

Типичные причины, почему баг “не воспроизводится”:

другое окружение (браузер, ОС, версия сборки, конфигурация)

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

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

нестабильность (race condition, сетевые сбои)

Практика: если дефект плавающий, это не повод “не заводить”. Но в репорте нужно честно зафиксировать частоту и условия.

Минимально полезная структура баг-репорта

Ниже — структура, которая работает в большинстве баг-трекеров (Jira, YouTrack, Bugzilla и т.д.).

Заголовок

Хороший заголовок отвечает: что сломано + где + при каком условии.

Плохо: “Не работает оплата”

Лучше: “Checkout: оплата картой возвращает 500 при выборе доставки курьером”

Окружение

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

стенд и URL (например, staging, https://staging.example.com)

версия сборки (например, 1.8.0-rc3)

платформа (Windows/macOS/Android/iOS)

браузер и версия (Chrome 121, Safari 17)

роль и тип аккаунта (user/admin, тариф)

Предусловия

Предусловия — это состояние системы до шагов. Примеры:

пользователь авторизован под ролью manager

в корзине есть товар с ID 123

заказ находится в статусе “Создан”

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

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

короткими и нумерованными

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

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

Фактический результат

Что реально произошло: сообщение об ошибке, код ответа API, неправильное состояние, неправильные данные.

Ожидаемый результат

Что должно было произойти. Источник ожидания желательно обозначить:

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

макет/дизайн

договорённость с продуктом

Вложения

скриншот или видео

логи консоли, network trace (если уместно)

HAR-файл (для веба)

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

Рекомендации по качеству описания дефекта хорошо собраны в гайде Bugzilla: Bug Writing Guidelines.

Поля баг-репорта, которые часто вызывают путаницу

Severity и Priority

Severity (серьёзность) — насколько сильно дефект влияет на систему и пользователя.

Priority (приоритет) — насколько срочно его нужно исправить с точки зрения планов и бизнеса.

Примеры, чтобы не путать:

Высокая severity, низкий priority: редко встречающийся краш в очень редком сценарии.

Низкая severity, высокий priority: мелкий дефект на главной странице перед маркетинговой кампанией.

Важно: часто приоритет ставит продукт или тимлид, а severity — QA. Но процесс зависит от команды.

Reproducibility

Насколько стабильно воспроизводится:

Always: каждый раз по шагам

Often/Sometimes: периодически

Rarely: редко

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

Статусы дефекта

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

New/Open: создан и ожидает обработки

Triaged: оценён и классифицирован

In Progress: в работе

Fixed/Resolved: исправлен (по мнению разработчика)

Ready for test: готов к проверке

Verified: QA подтвердил исправление

Closed: закрыт

Reopened: повторно открыт, если проблема осталась

Won’t fix/Duplicate/Not a bug: решение не исправлять, дубликат или не дефект

Жизненный цикл дефекта и роли в процессе

!Схема показывает типичный жизненный цикл дефекта и возможные ветвления.

Как выглядит работа с дефектом по шагам

QA находит проблему и заводит баг-репорт с достаточной информацией.

Команда делает триаж (triage): проверяет, дефект ли это, оценивает severity, решает приоритет и ответственного.

Разработчик воспроизводит, локализует причину, исправляет.

Разработчик переводит дефект в статус “готов к проверке” и указывает версию/коммит (если принято).

QA делает ретест (retest): проверяет конкретное исправление по шагам.

QA при успехе переводит в “Verified/Closed”, при неуспехе — Reopened с обновлёнными фактами.

Триаж дефектов: цель и правила

Триаж — это регулярная практика, где команда управляет потоком дефектов.

Цели триажа:

отсеять дубликаты и не-дефекты

согласовать severity и priority

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

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

Чтобы триаж был эффективным, QA обычно приходит с готовыми ответами:

воспроизводимость и условия

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

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

связь с требованиями или критериями приёмки

Ретест и регрессия: в чём разница

Ретест — повторная проверка именно того дефекта, который исправляли.

Регрессия — проверка, что исправление или изменение не сломало другое.

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

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

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

Связь с предыдущими темами курса:

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

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

отчёт о тестировании фиксирует остаточные риски, если часть дефектов остаётся открытой

Что делать с “не дефектом”: Not a bug, Duplicate, Won’t fix

Эти резолюции нормальны, если команда использует их прозрачно.

Not a bug

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

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

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

Duplicate

Дубликаты засоряют бэклог и портят метрики. Перед созданием дефекта полезно:

поискать по ключевым словам

проверить похожие дефекты в этом модуле

Won’t fix

Причины могут быть разные:

слишком дорого исправлять относительно ущерба

риск сломать более критичный функционал

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

Задача QA — убедиться, что риск осознан и задокументирован (например, в релизных заметках или тест-отчёте).

Типичные ошибки начинающих в баг-репортах

Неполные шаги: “нажал, и сломалось”.

Нет ожидаемого результата или он сформулирован как “должно работать”.

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

Смешаны разные проблемы в одном дефекте.

Заголовок не даёт понять, в чём суть.

Нет данных для входа или ID сущности, без которых нельзя повторить.

Практические шаблоны

Шаблон баг-репорта

Пример хорошо оформленного дефекта

Как баг-репорты помогают качеству в целом

Баг-репорты — часть системы качества, а не отдельная активность:

они дают команде фидбек, что именно сломано и где риск

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

они помогают строить регрессию: повторяющиеся дефекты превращаются в тест-кейсы или автопроверки

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

Виды тестирования: функциональное, регрессионное, UI/API

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

В этой статье сфокусируемся на:

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

Регрессионном тестировании (проверяем, что изменения не сломали существующее)

Тестировании через UI и через API (выбираем на каком уровне проверять)

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

Как не путаться в терминах: вид и уровень

На практике часто смешивают две оси:

Вид тестирования отвечает на вопрос: что именно проверяем? (например, функциональность, безопасность, производительность)

Уровень/слой проверки отвечает на вопрос: где проверяем? (например, через UI, API, базу, модуль)

В этой статье «функциональное» и «регрессия» — это в первую очередь про цель проверки, а «UI/API» — про уровень, на котором вы выполняете тест.

!Схема помогает увидеть, что функциональность/регрессия и UI/API — разные измерения выбора тестов

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

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

Что обычно входит в функциональные проверки

Позитивные сценарии (happy path): «пользователь может выполнить основную задачу»

Негативные сценарии: «система корректно реагирует на неверные данные/запрещённые действия»

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

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

Пример функционального набора для интернет-магазина

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

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

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

Пользователь без прав не может открыть админ-раздел

Типичные ошибки начинающих

Проверять только UI-«картинку» и не проверять бизнес-эффект (например, заказ «вроде создался», но в системе не появился)

Ограничиваться только позитивными сценариями

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

Регрессионное тестирование

Регрессионное тестирование — это проверки, которые подтверждают, что изменения (новая фича, фикс, рефакторинг, обновление зависимостей) не сломали уже работающие части продукта.

Ключевая идея: регрессия — не «просто много тестов», а осмысленный набор проверок, который защищает продукт от повторных поломок.

Когда нужна регрессия

Перед релизом

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

После массовых правок (переработка интерфейса, миграции)

При обновлении окружений и интеграций (например, смена платёжного провайдера)

Регрессия, смоук и санити: как различать

| Набор | Задача | Объём | Пример | |---|---|---|---| | Смоук (smoke) | Быстро понять, что сборка вообще «живая» | Маленький | логин, открывается главная, создаётся сущность | | Санити (sanity) | Быстро проверить конкретное изменение | Точечный | проверка только затронутой фичи и ближайших связей | | Регрессия (regression) | Убедиться, что старое не сломалось | От среднего до большого | ключевые бизнес-потоки + исторически проблемные зоны |

Важно: смоук и санити часто являются частью регрессии, но отличаются целью и размером.

Как выбирать регрессионный набор

На практике регрессию собирают риск-ориентированно (это связано с темами про тест-дизайн и отчётность):

Ключевые пользовательские потоки (то, что приносит ценность и деньги)

Зоны с историей дефектов (то, что часто ломалось)

Сложные интеграции (оплата, доставка, внешние API)

Права доступа и безопасность (ошибка дорогая)

Кросс-платформенность (если продукт критично зависит от браузеров/устройств)

Тестирование через UI

UI-тестирование — это проверки через пользовательский интерфейс (веб, мобильное приложение, десктоп). Оно отвечает на вопрос: может ли пользователь реально выполнить сценарий так, как задумано.

Что хорошо ловит UI-тестирование

Ошибки в пользовательских сценариях «от начала до конца» (end-to-end)

Проблемы верстки и взаимодействия элементов

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

Ошибки маршрутизации, навигации, состояния страниц

Ограничения UI-проверок

Обычно они медленнее, чем проверки на уровне API

Часто зависят от нестабильных факторов (анимации, сеть, изменения вёрстки)

Сложнее диагностировать причину (упало «оформление заказа» — где именно?)

Практический подход: UI хорошо подходит для ключевых end-to-end потоков и для проверки пользовательского опыта, но не должен быть единственным уровнем проверок.

Тестирование через API

API-тестирование — это проверки на уровне интерфейсов взаимодействия систем. Чаще всего речь про HTTP API (REST), но принципы похожи и для других протоколов.

Если UI — это «как пользователь кликает», то API — это «какие запросы система принимает и какие ответы возвращает».

Что такое HTTP API в простых словах

Клиент отправляет запрос (например, POST /orders)

Сервер возвращает ответ (код статуса, тело ответа, заголовки)

Полезная справка по смыслу статус-кодов: MDN Web Docs: HTTP response status codes.

Что хорошо ловит API-тестирование

Логику бизнес-правил без влияния UI (создание заказа, расчёт скидки)

Ошибки валидации и контрактов (не те поля, не те типы)

Проблемы авторизации (например, 401/403 там, где ожидается доступ)

Интеграционные проблемы между сервисами

Почему API-проверки часто дешевле

Обычно быстрее выполняются

Более стабильны (меньше «ломаются» от изменения UI)

Проще локализовать проблему (видно конкретный запрос/ответ)

Минимальный чек-лист для API-проверки эндпоинта

Позитивный запрос с валидными данными

Негативные запросы по классам эквивалентности (пусто, неверный формат, слишком длинно)

Проверка прав доступа (роль имеет доступ, роль не имеет доступ)

Проверка кодов ответа (например, 200/201, 400, 401, 403)

Проверка структуры ответа (обязательные поля присутствуют)

UI vs API: что выбрать в конкретной задаче

Частая ошибка новичка — пытаться всё проверять через UI, потому что «так видно». На практике выбор зависит от цели.

| Вопрос | UI-проверка чаще лучше | API-проверка чаще лучше | |---|---|---| | Нужно убедиться, что пользовательский путь работает | Да | Частично (UI всё равно важен) | | Нужно быстро проверить бизнес-логику/валидации | Иногда | Да | | Нужно быстро прогнать много сценариев | Редко | Да | | UI часто меняется и тесты «хрупкие» | Нет | Да | | Важно проверить тексты/верстку/элементы управления | Да | Нет |

Практическая стратегия для начинающего QA:

Держите небольшой набор UI-сценариев для критичных потоков

Основную массу функциональных проверок (особенно валидации и правила) по возможности делайте на уровне API

Регрессию строите риск-ориентированно, комбинируя UI и API

Как это связано с тест-дизайном, документацией и дефектами

Эта тема напрямую соединяет предыдущие статьи курса:

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

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

Баг-репорты становятся качественнее, если вы понимаете уровень: для UI-дефекта полезно видео/скриншот, для API-дефекта — запрос/ответ и код статуса.

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

В индустрии популярна идея «пирамиды тестов»: чем ниже уровень, тем больше тестов и тем они быстрее; чем выше уровень (UI/end-to-end), тем тестов меньше, но они ближе к реальному пользовательскому поведению.

Один из известных практических разборов: Martin Fowler: The Practical Test Pyramid.

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

Итог

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

Регрессионное тестирование защищает от поломок уже работающего после изменений.

UI-тестирование ближе всего к реальному поведению пользователя, но часто медленнее и менее стабильно.

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

Дальше по курсу эти виды проверок будут использоваться как основа для практики: составление смоук/регрессионных наборов, выбор уровня проверки (UI/API) и оформление результатов через тестовую документацию и баг-репорты.

Инструменты QA и базовые основы автоматизации

В предыдущих статьях курса мы выстроили фундамент: роль QA, SDLC/STLC, техники тест-дизайна, тестовую документацию и работу с дефектами. Теперь добавим практический слой: какими инструментами пользуется QA каждый день и с чего начинать автоматизацию, чтобы она реально помогала качеству, а не превращалась в дорогую «галочку».

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

Карта инструментов QA: что для чего

Инструменты удобно группировать по задачам.

| Задача | Что делает QA | Примеры инструментов | |---|---|---| | Управление задачами и дефектами | фиксирует баги, следит за статусами, участвует в триаже | Jira, YouTrack | | Управление тестами | хранит тест-кейсы/чек-листы, прогоны, отчёты | TestRail, Zephyr, qTest | | UI-проверки и диагностика | анализирует поведение фронтенда и запросы | Chrome DevTools, Firefox DevTools | | API-тестирование | отправляет запросы, проверяет ответы, контракты | Postman, Swagger/OpenAPI | | Работа с данными | проверяет записи в БД, готовит тестовые данные | SQL-клиенты (например, DBeaver) | | Отладка сетевых проблем | ловит/анализирует HTTP(S), прокси, сертификаты | Charles Proxy, Fiddler | | Контроль версий и командная работа | читает изменения, помогает воспроизводить, делает PR для тестов | Git | | CI/CD | запускает автотесты, собирает отчёты, блокирует релиз при критике | Jenkins, GitHub Actions, GitLab CI/CD | | Автоматизация тестов | пишет и запускает автопроверки (UI/API), формирует отчёты | Playwright, Selenium, Cypress, pytest, JUnit 5, Allure Report |

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

Инструменты для UI-тестирования и диагностики

DevTools: обязательный минимум для веб-QA

DevTools в браузере — главный «диагностический прибор» для проверки веб-приложений. Он полезен и в ручном тестировании, и при разборе дефектов.

Что чаще всего нужно уметь:

Elements/Inspector: проверить, что элемент реально существует, не перекрыт, имеет нужные состояния.

Console: увидеть ошибки JavaScript, предупреждения, логи приложения.

Network: понять, какие запросы уходят, какие ответы приходят, где 401/403/500, какие параметры передаются.

Application/Storage: посмотреть cookies, localStorage/sessionStorage (например, чтобы понять, почему «не держится» сессия).

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

для UI-дефекта часто достаточно видео + Console ошибки

для API/интеграционного дефекта почти всегда полезно приложить Network детали запроса/ответа

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

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

Device toolbar (эмуляция экранов) в DevTools

изменение масштаба, проверка переполнений, проверка кликабельности элементов

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

Postman: быстрые проверки и коллекции

Postman обычно используют для:

ручной отправки запросов

сохранения запросов в коллекции

параметризации (переменные окружения: baseUrl, токены)

быстрой проверки авторизации (Bearer token, cookies)

простых автоматических проверок на уровне коллекции

Минимальный набор того, что QA проверяет у API (связь с темой UI/API из курса):

коды ответа (например, 200/201, 400, 401, 403)

структура ответа (ключевые поля есть)

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

права доступа (доступно одной роли и недоступно другой)

Swagger / OpenAPI: «контракт» как источник ожиданий

Если у проекта есть спецификация OpenAPI, она становится сильной опорой для тестирования:

какие эндпоинты существуют

какие поля обязательны

какие форматы и типы

какие коды ответов ожидаются

Спецификация: Swagger / OpenAPI Specification.

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

SQL и клиенты к базе данных

Даже если вы не администратор БД, QA часто нужно:

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

подготовить тестовые данные быстрее, чем через интерфейс

локализовать проблему (в UI видно одно, в базе другое)

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

Популярный универсальный клиент: DBeaver.

Логи и наблюдаемость (observability)

Если в команде настроены логи и трассировка, QA получает мощный инструмент для диагностики:

корреляция запроса пользователя с серверными ошибками

поиск ошибок по времени и идентификаторам (requestId, userId)

подтверждение, что проблема «на сервере», а не в UI

Конкретные платформы зависят от компании, но подход один: без логов воспроизводимость и скорость триажа падают.

Снифферы и прокси

Инструменты вроде Charles Proxy или Fiddler полезны, когда:

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

нужно воспроизвести сетевые ошибки или подменить ответы

есть проблемы с сертификатами, кэшированием, редиректами

Баг-трекинг и тест-менеджмент: как это связано с артефактами QA

Из прошлых тем курса:

баг-репорт должен быть воспроизводимым

тест-кейсы и чек-листы должны быть актуальными

отчёт о тестировании должен помогать принять решение о релизе

Инструменты помогают «приземлить» это в процесс.

Баг-трекер

В баг-трекере вы обычно фиксируете:

дефект (описание, шаги, expected/actual)

влияние (severity)

срочность (priority, часто совместно с продуктом)

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

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

Тест-менеджмент

Системы тест-менеджмента полезны, когда нужно:

хранить регрессионный набор тест-кейсов

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

собирать статистику прохождения

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

Примеры: TestRail, Zephyr.

Базовые основы автоматизации: что это и зачем

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

Важно не путать:

автоматизацию проверок (checks): «ожидаем X, получили Y»

исследовательское тестирование: поиск неизвестных проблем через изучение и эксперименты

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

Что чаще всего автоматизируют на старте

На проектах начинающих QA чаще всего автоматизируют:

смоук (быстро понять, что сборка «живая»)

регрессию ключевых потоков (то, что приносит ценность и деньги)

API-проверки бизнес-правил (часто быстрее и стабильнее, чем UI)

А вот что обычно автоматизируют позже или аккуратно:

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

редкие сценарии, которые почти не повторяются

Как выбирать кандидатов на автоматизацию

Хорошие кандидаты на автотесты:

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

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

проверки, которые сложно выполнять вручную быстро

проверки, у которых понятный ожидаемый результат

Плохие кандидаты:

«плавающие» сценарии без стабильных данных и окружения

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

сценарии, которые меняются каждую неделю

Из чего состоит автотест

Любой автотест (UI или API) можно разложить на одинаковые части:

Подготовка: данные, окружение, авторизация.

Действие: клик/ввод в UI или запрос в API.

Проверка (assertion): сравнение факта с ожиданием.

Очистка (не всегда): вернуть систему в исходное состояние.

Ключевой элемент — assertion. Если автотест что-то сделал, но ничего не проверил, он не защищает качество.

UI-автоматизация: базовые понятия и риски

Для UI-автотестов часто используют:

Playwright

Selenium

Cypress

Локаторы

Локатор — это способ найти элемент на странице.

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

лучше опираться на специальные атрибуты для тестов (например, data-testid)

хуже опираться на хрупкие CSS-классы, которые часто меняются из-за вёрстки

Ожидания (waits)

Современный UI асинхронный: запросы уходят в сеть, элементы появляются не мгновенно.

Поэтому важно:

ждать состояние, а не «спать N секунд»

проверять, что элемент виден/доступен/содержит текст

API-автоматизация: хороший старт для начинающего

API-автотесты часто:

быстрее выполняются

проще диагностируются

менее хрупкие при изменениях UI

Пример простого API-теста на Python с pytest (идея, а не «универсальный шаблон»):

Что здесь происходит:

requests.get(...) отправляет HTTP-запрос

response.status_code — фактический код ответа

assert ... == 200 — проверка ожидания

Саму структуру тестов и запуск описывает документация pytest.

Автотесты и CI/CD: как они дают быстрый фидбек

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

на pull request

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

перед релизом

Инструменты:

Jenkins

GitHub Actions

GitLab CI/CD

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

Отчёты автотестов и полезная «диагностика падения»

Чтобы автотесты помогали, важно не только «зелёный/красный», но и почему упало.

Практики, которые повышают ценность:

понятные названия тестов (действие + объект + ожидаемый эффект)

скриншоты и видео для UI-падений

сохранение логов и сетевых артефактов (если возможно)

отчёты, которые удобно читать

Для отчётности часто используют Allure Report.

Минимальная стратегия для новичка: с чего начать автоматизацию

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

Выберите небольшой смоук-набор (5–20 проверок), который быстро показывает, что сборка живая.

Максимально вынесите бизнес-валидации на уровень API, где это возможно.

Оставьте UI end-to-end только на самые критичные пользовательские потоки.

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

Сделайте отчётность читаемой: что упало, где, на каком окружении.

Эта стратегия напрямую продолжает темы курса:

из тест-дизайна вы берёте приоритизацию и техники отбора проверок

из документации — превращаете стабильные проверки в тест-кейсы/регрессию

из темы дефектов — оформляете падения так, чтобы разработчик быстро нашёл причину

Итог

Инструменты QA покрывают весь цикл: от анализа UI/API и данных до баг-репортов, тест-менеджмента и CI.

Автоматизация эффективна, когда она риск-ориентирована: смоук, ключевая регрессия, API-проверки.

Базовая единица автотеста — действие плюс проверка (assertion) при стабильных данных и окружении.

Максимальная ценность автотестов появляется при регулярном запуске в CI и понятной отчётности.