Основы тестирования программного обеспечения

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Тестировщику Разработчику Аналитику

Теория данных (раздел 3)

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

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

---

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

Представьте: разработчики закрыли задачу, выкатили сборку на тестовый сервер. Функция "работает у автора на ноутбуке" — но достаточно ли этого, чтобы отдать продукт пользователям?

Обычно нет. Сценариев много — другой браузер, пустая корзина, двойной клик, обрыв сети, старые данные в базе (сверка SQL, транзакции). Разработчик проверил "счастливый путь", а систематически пройти десятки комбинаций — отдельная работа. Ею и занимается тестирование программного обеспечения.

Play ITЗагрузка интерактивного демо…

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

В учебниках и стандартах часто дают и более формальную формулировку: анализ программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта. В глоссарии ISTQB отдельного термина "тестирование ПО" нет — там используется общий термин testing.

Важно не путать с обеспечением качества (QA). QA — про процессы, стандарты и предотвращение проблем до и вокруг разработки. Тестирование — про измерение и проверку конкретной сборки. Оба нужны; это не одно и то же.

Классическое определение Гленфорда Майерса (1979): "Тестирование — это процесс выполнения программы с намерением найти ошибку". Оно полезно как историческая отправная точка, но сегодня формулировку дополняют.

Парадокс тестирования (эволюция 1970-х) — с одной стороны, тесты используют, чтобы убедить заказчика в корректности (приёмка, демо "всё зелёное"); с другой — зрелая практика ищет расхождения с ожиданиями. Второй подход продуктивнее для качества — "успешный" тест — тот, который нашёл ранее неизвестную проблему, а не тот, который молча прошёл.

С 1980-х тестирование распространили на весь SDLC — проверяют не только собранную программу, но и требования, архитектуру, тест-кейсы и сами тесты (shift-left). Статическое тестирование анализирует артефакты без запуска кода (ревью ТЗ, линтеры, анализ исходников — Код — о разделе); динамическое — при выполнении программы (Выполнение кода — о разделе). Подробнее про стратегии доступа к коду — в классификации видов тестирования.

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

Проверка ТЗ, user story и макетов до кода — один из самых дешёвых способов снизить дефекты. Аналитик формулирует ожидания; QA проверяет, что по документу можно построить объективный тест (см. свойства качественных требований в разделе аналитики).

Техника	Что делаем
Ревью требований	Читаем документ по чек-листу: полнота, однозначность, проверяемость
Инспекция (формальная)	Встреча с ролями: автор, модератор, читатели; фиксируем дефекты в документе
Прототип / walkthrough	Проходим сценарий на макете или черновом UI
Трассировка	Каждое требование связано с тест-кейсом или критерием приёмки

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

• тестирование не доказывает, что дефектов нет — оно снижает риск и показывает, где система ведёт себя иначе, чем ожидалось;
• цель — дать обоснованную информацию о готовности к релизу;
• хорошее тестирование начинается раньше кода — анализ требований, тест-дизайн, уточнение критериев приёмки.

На практике тестирование включает:

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

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

---

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

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

Период	Акцент	Что важно запомнить
1950–60-е	Формальная "проверка всех путей" (exhaustive testing)	Исчерпывающий перебор входов для реальной системы невозможен — см. тест-дизайн и принцип "исчерпывающее тестирование невозможно" ниже
1970-е	Доказательство работоспособности и поиск условий поломки	Две цели дополняют друг друга: убедить заказчика и найти расхождения с ожиданиями
1980-е	Тестирование на всём SDLC, статика + динамика	Ревью ТЗ, анализ кода без запуска; тесты на каждой итерации — основа shift-left
1990-е	QA шире, чем прогон тестов	Процессы, стандарты, метрики качества вокруг разработки
2000-е — сейчас	Agile, автоматизация, TDD/BDD, фокус на ценность для пользователя	Тестирование встроено в команду; см. жизненный цикл и карту уровней

Хронология подробнее:

• До 1950–60-х — первые крупные программы в основном для обороны; проверку часто делали сами разработчики.
• 1950–60-е — мода на "прогнать все пути и все данные"; рост объёма кода сделал исчерпывающий перебор нереалистичным.
• 1970-е — два акцента: демонстрация работоспособности заказчику и поиск условий поломки (зародыш "парадокса тестирования").
• 1980-е — оформление методологии, предупреждение дефектов, первые инструменты автоматизации.
• 1990-е — QA шире прогона тестов — планирование, проектирование, метрики на всём SDLC.
• 2000-е — исследовательское тестирование, массовое API-тестирование без UI; 2004 — открытый Selenium, сдвинувший UI-автоматизацию.
• 2010-е — сейчас — CI/CD, shift-left/shift-right, контрактные тесты, нагрузка "как код"; см. DevOps.

Про "ИИ заменит тестирование"

В обзорных материалах для новичков иногда шутят про 2040 год, когда "машины не ошибаются".

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

Упражнение на масштаб

Программа проверяет, существует ли треугольник с тремя сторонами (три знаковых 8-байтовых целых). Полный перебор всех троек при 100 млн проверок в секунду займёт годы. Это наглядный аргумент, зачем нужны классы эквивалентности и границы, а не "прогнать всё подряд".

---

Семь принципов тестирования

Их часто приводят в стандартах вроде ISO/IEC/IEEE 29119 и на курсах ISTQB. Не как заучивание, а как здравый смысл профессии:

Принцип	Простыми словами
Исчерпывающее тестирование невозможно	Проверить все комбинации нельзя — выбираем по риску и тест-дизайну.
Тестирование — это компромисс	Время и люди ограничены; важнее правильные проверки, а не их количество.
Раннее тестирование	Чем раньше нашли неясность в требованиях, тем дешевле исправление.
Скопление дефектов	Баги часто кучкуются в одних модулях — туда и направляем усилия.
Пестициды	Одни и те же тесты со временем перестают находить новые проблемы — набор нужно обновлять.
Тестирование зависит от контекста	Банк, игра и внутренний админка требуют разных подходов.
Заблуждение об отсутствии ошибок	"Все тесты зелёные" ≠ "пользователям точно понравится".

Для собеседований и переписки

Если спрашивают "зачем тестирование, если баги всё равно останутся" — ответ — мы не обещаем идеал, мы уменьшаем риск и раньше показываем, где продукт не соответствует ожиданиям.

---

А что может пойти не так?

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

Ниже — цепочка терминов, которую стоит держать в голове (близко к ISTQB и классификации):

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

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

Сбой / отказ (failure) — наблюдаемое неверное поведение при работе системы — белый экран, 500, списание денег дважды. Пользователь видит именно сбой.

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

Фраза "не баг, а фича" в чатах команды означает другое: баг — непреднамеренное поведение, фича — задуманная функция (иногда спорная). На triage это разводят по требованиям и продуктовому решению, а не по формулировке разработчика.

Не каждый сбой — дефект в коде

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

Пример цепочки. Аналитик ошибся в формуле скидки (ошибка) → в ТЗ и коде заложена неверная логика (дефект) → при оформлении заказа клиент видит неверную сумму (сбой) → в YouTrack создаётся тикет "Неверный расчёт скидки" (баг в трекере).

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

---

Исключение в коде — отдельная история

Исключение (exception) в Java, Python, C# и других языках — механизм языка: объект, который выбрасывается при аварийной ситуации и перехватывается в catch / except. Это не синоним "бага в Jira".

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

---

Кто такой тестировщик и QA-инженер

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

QA-инженер (Quality Assurance Engineer) — более широкая роль, включающая не только выполнение тестов, но и участие в формировании стратегии обеспечения качества на всех этапах жизненного цикла разработки. QA-инженер может заниматься автоматизацией тестирования, проектированием тестовой инфраструктуры, внедрением метрик качества, участвовать в планировании релизов и влиять на процессы разработки с целью их улучшения. QA-инженер стремится не просто находить ошибки, а предотвращать их появление через улучшение процессов, стандартов и практик.

Тестировщики:

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

---

Верификация и валидация

Верификация — это процесс оценки того, правильно ли система построена. Она отвечает на вопрос: "Соблюдены ли требования при реализации?". Верификация проводится без запуска кода и включает в себя такие виды деятельности, как:

• рецензирование требований;
• анализ архитектуры;
• проверка кода (code review);
• статический анализ.

Валидация — это процесс оценки того, правильно ли построена нужная система. Она отвечает на вопрос: "Соответствует ли продукт потребностям пользователя?". Валидация требует выполнения программы и включает:

• функциональное тестирование;
• приёмочное тестирование;
• тестирование юзабилити;
• проверку на соответствие бизнес-целям.

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

Образ "осёл и конь"

Классический пример: заказчик по ТЗ просил непарнокопытное животное с четырьмя ногами, умеющее скакать — верификация пройдена.

Релиз — осёл. Формально спецификация соблюдена, но валидация (нужен был конь) провалена. QA на раннем этапе как раз ловит разрыв между буквой ТЗ и реальной потребностью.

---

Ожидаемое и фактическое поведение системы

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

Фактическое поведение системы — это реальное поведение программы при выполнении тех же условий. Если фактическое поведение отличается от ожидаемого, фиксируется дефект (баг).

Сравнение этих двух состояний — основа любого теста. Без чётко определённого ожидания невозможно объективно судить о корректности работы системы.

---

QC (Quality Control) и QA (Quality Assurance)

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

• выполнение тестов;
• анализ логов;
• проверку соответствия требованиям.

Quality Assurance (Обеспечение качества) — это системный подход к предотвращению дефектов путём улучшения процессов разработки и сопровождения. QA охватывает:

• стандартизацию процессов;
• обучение команды;
• внедрение метрик;
• аудиты и ретроспективы.

QC — это реактивная деятельность, QA — проактивная. Обе составляют полную систему управления качеством.

---

Требования

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

Требования бывают разных видов:

• бизнес-требования;
• пользовательские требования;
• продуктовые требования (функциональные и нефункциональные).

Бизнес-требования могут быть:

• верхнеуровневыми (общие стратегические цели компании);
• пользовательскими (потребности пользователей);
• системными (технические детали решения).

Обычно требования представляются в виде документации, к примеру, это может быть User Story (как пользователь, я хочу, чтобы...) или Use Case (сценарий использования). Их составляют, как правило, аналитики, путём выявления требований через:

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

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

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

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

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

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

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

---

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

Цель анализа требований на стороне QA — понять ожидаемый результат до прогона тестов: иначе нельзя объективно сказать "прошло" или "упало".

Если в требованиях не описана, например, валидация поля "Возраст", это не значит "можно не делать". Это сигнал: пробел в спецификации. Тестировщик поднимает вопрос на refinement — нужна ли валидация, какие границы, что показывать пользователю. Решение принимает команда (часто с аналитиком и владельцем продукта), а не тестировщик в одиночку.

Работа аналитиков — сделать требования проверяемыми; работа тестировщика на раннем этапе — найти дыры и двусмысленности, пока правка дешевая. На практике споры и уточнения — нормальная часть процесса, а не признак "плохой команды".

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

Требования, как правило, имеют следующие свойства:

• обязательность;
• актуальность;
• атомарность;
• завершённость;
• выполнимость;
• важность;
• стабильность;
• срочность;
• недвусмысленность;
• непротиворечивость;
• прослеживаемость;
• модифицируемость.

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

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

• Неполнота — отсутствие описания определённых сценариев использования, исключений или граничных условий. Например, требование "Система должна сохранять данные пользователя" не уточняет, какие именно данные, в каком формате, при каких условиях и с какими ограничениями.
• Двусмысленность — использование терминов, допускающих несколько интерпретаций. Фраза "Система должна быть быстрой" не содержит измеримых критериев.
• Противоречивость — наличие в спецификации взаимоисключающих условий. Например, "Система должна отвечать за 200 мс" и "Система должна использовать асинхронную обработку с задержкой до 1 секунды".
• Избыточность — дублирование одних и тех же требований в разных разделах документа, что усложняет поддержку и приводит к рассогласованности при изменениях.
• Непроверяемость — формулировки, которые невозможно верифицировать технически. "Интерфейс должен быть удобным" — субъективное суждение, требующее количественной оценки (например, через метрики юзабилити).

Способы устранения таких проблем включают:

• Проведение рецензирования требований (requirements review) с участием аналитиков, тестировщиков, разработчиков и представителей заказчика.
• Формализацию требований в виде пользовательских историй или сценариев использования (use cases).
• Использование моделей поведения (state diagrams, decision tables) для уточнения сложных логических ветвлений.
• Применение спецификаций в виде executable requirements (например, через Gherkin и BDD-подход), которые одновременно служат документацией и основой для автоматизированных тестов.

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

---

Различия между основными категориями тестирования

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

---

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

Функциональное тестирование проверяет соответствие поведения системы заданным функциональным требованиям. Оно отвечает на вопрос: "Делает ли система то, что от неё ожидается?". Примеры — проверка корректности расчёта итоговой суммы в корзине интернет-магазина, верификация правил авторизации или валидации формы.

Нефункциональное тестирование оценивает атрибуты качества программного обеспечения, которые не связаны напрямую с конкретными функциями, но критически важны для эксплуатации. Оно отвечает на вопрос: "Насколько хорошо система это делает?". К таким атрибутам относятся производительность, безопасность, надёжность, масштабируемость, удобство использования и совместимость.

---

Ручное и автоматизированное тестирование

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

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

---

Позитивное и негативное тестирование

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

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

Успешный негативный тест

Негативный кейс проходит, когда приложение корректно отклонило неверный ввод, показало понятную ошибку и не упало.

Сбой в UI при невалидных данных — повод для баг-репорта, а не "успех теста".

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

---

Ключевые направления тестирования

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

• Регрессионное тестирование — проверка того, что изменения в коде не привели к нарушению ранее работавшей функциональности. Является основой стабильности в итеративной разработке.
• Приёмочное тестирование (UAT) — финальная верификация системы со стороны заказчика или конечного пользователя. Подтверждает, что продукт решает бизнес-задачу.
• Нагрузочное тестирование — оценка поведения системы под ожидаемой или пиковой нагрузкой (количество пользователей, транзакций, запросов в секунду).
• Стрессовое тестирование — проверка устойчивости системы за пределами нормальных условий эксплуатации, вплоть до её отказа (например, при исчерпании памяти или сетевого канала).
• Тестирование безопасности — анализ на уязвимости, такие как SQL-инъекции, XSS, несанкционированный доступ, утечки данных. Может включать как автоматизированные сканирования, так и ручной пентест.
• Тестирование юзабилити — оценка удобства, интуитивности и эффективности взаимодействия пользователя с интерфейсом. Часто включает проведение юзабилити-сессий и анализ пользовательских метрик.

---

Как проводят ручное тестирование

Ручное тестирование выполняется человеком без использования автоматизированных скриптов. Процесс включает следующие шаги:

1. Анализ требований — понимание того, что должно быть проверено.
2. Проектирование тестовых сценариев — создание последовательностей действий, ожидаемых результатов и предусловий.
3. Подготовка тестовой среды — настройка окружения, данных и конфигураций.
4. Выполнение тестов — последовательное выполнение шагов и фиксация результатов.
5. Сравнение с ожидаемым поведением — определение наличия или отсутствия дефекта.
6. Документирование дефектов — создание отчётов с описанием, шагами воспроизведения, скриншотами и логами.
7. Повторная проверка — верификация исправления после устранения дефекта.

Ручное тестирование особенно эффективно при исследовательском тестировании, проверке UX/UI и в ситуациях, где автоматизация затратна или невозможна.

---

Как проводят автоматизированное тестирование

Автоматизированное тестирование использует программные средства для выполнения тестов. Этапы:

1. Выбор фреймворка и инструментов — например, Selenium, Cypress, Playwright, JUnit, pytest, xUnit.
2. Написание тестовых скриптов — код, имитирующий действия пользователя или вызывающий API.
3. Интеграция в CI/CD — настройка автоматического запуска тестов при каждом коммите или сборке.
4. Настройка отчётов — генерация понятных отчётов о прохождении/падении тестов.
5. Поддержка и актуализация — регулярное обновление тестов при изменении функционала.

Автоматизация особенно ценна для:

• регрессионного тестирования;
• smoke-тестов;
• нагрузочных и стрессовых сценариев;
• проверки стабильных, часто используемых функций.

---

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

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

Проверяет, что новые изменения не сломали существующий функционал. Выполняется после каждого значимого изменения кода. Часто автоматизируется.

---

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

Проводится заказчиком или представителями конечных пользователей. Проверяется соответствие продукта бизнес-задачам. Обычно выполняется вручную на предпрод-среде.

---

Нагрузочное тестирование

Моделирует ожидаемую рабочую нагрузку (например, 10 000 одновременных пользователей). Используются инструменты вроде JMeter, k6, Gatling. Цель — оценить производительность и стабильность. Дерево TestPlan и HTTP sampler в коде — Практикум — API-тестер на Groovy; обзор инструментов — Нагрузочное и стресс-тестирование производительности.

---

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

Превышает нормальные пределы нагрузки (например, исчерпание памяти, перегрузка CPU). Проверяется, как система ведёт себя в экстремальных условиях и восстанавливается ли после них.

---

Тестирование безопасности

Включает:

• сканирование на уязвимости (OWASP ZAP, Burp Suite);
• проверку на SQL-инъекции, XSS, CSRF;
• анализ прав доступа;
• ручной пентест.

---

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

Проводится с участием реальных пользователей. Оценивается:

• интуитивность интерфейса;
• скорость выполнения задач;
• частота ошибок;
• субъективное восприятие.

Маршрут исследований, протокол сессии и связь с веб-дизайном — Веб-дизайн — блок 7.

---

Стратегия тестирования и планирование процедур

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

• цели тестирования;
• типы тестов;
• уровни покрытия;
• критерии входа и выхода;
• роли и ответственности;
• инструменты и технологии.

Планирование процедур — это детализация стратегии на конкретный релиз или итерацию. Включает:

• составление тест-плана;
• распределение задач;
• оценку трудозатрат;
• определение графика;
• подготовку тестовых данных и сред.

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

---

Серьёзность дефекта и градация

Серьёзность (Severity) — степень влияния дефекта на работоспособность системы:

• Блокирующий — система неработоспособна, дальнейшее тестирование невозможно.
• Критический — важная функция недоступна, данные теряются или портятся.
• Значительный — функция работает некорректно, но есть обходные пути.
• Незначительный — незначительное отклонение от ожидаемого поведения без влияния на основной функционал.
• Тривиальный — косметические недочёты (опечатки, цвет пикселя).

---

Приоритет дефекта

Приоритет (Priority) — насколько быстро дефект должен быть исправлен:

• Высокий — исправление требуется до следующего релиза.
• Средний — можно исправить в ближайших итерациях.
• Низкий — исправление откладывается на будущее.

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

---

Тестовые среды

• Среда разработки (Разработка Env) — используется разработчиками для написания и отладки кода. Часто локальная или персональная.
• Среда тестирования (Test Env) — выделенная среда для тестировщиков. Здесь проводятся функциональные, регрессионные и smoke-тесты.
• Интеграционная среда (Integration Env) — предназначена для проверки взаимодействия между модулями, микросервисами или внешними системами.
• Предпродакшен (Preprod Env) — максимально приближена к продакшену по конфигурации, данным и нагрузке. Используется для финального UAT и проверки развёртывания.
• Продакшен (Production Env) — рабочая среда, доступная конечным пользователям. Тестирование здесь крайне ограничено и проводится осторожно (например, A/B-тесты).

---

Основные фазы тестирования

• Pre-Alpha — прототип с неполным функционалом и множеством ошибок. Используется для внутренней демонстрации идей.
• Alpha — ранняя версия, тестируемая внутри компании. Функционал почти полный, но стабильность низкая.
• Beta — практически готовый продукт, распространяемый среди ограниченного круга внешних пользователей для получения обратной связи.
• Release Candidate (RC) — кандидат на релиз. Все известные критические ошибки исправлены. Проводится финальное регрессионное тестирование.
• Release — финальная версия, официально выпущенная для всех пользователей.

---

Как читать эту тему без перегруза

Если материал кажется объёмным, двигайтесь по простому маршруту:

1. Зафиксируйте базу из этой статьи — термины "ошибка", "дефект", "сбой", различие QA и QC.
2. Перейдите в классификацию видов тестирования, чтобы увидеть "карту" по уровням и целям.
3. Закрепите процесс на жизненном цикле тестирования, где показано, как это работает в проекте по шагам.
4. После этого открывайте практикумы Подготовка среды и создание первого теста, Проверка взаимодействия компонентов, Проверка пользовательского сценария, Проверка надежности под нагрузкой: там теория становится действиями.

Такой порядок помогает быстрее связать термины с реальной работой и снижает ощущение "академичности".

---

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

Команда делает страницу оплаты в интернет-магазине.

• Аналитик фиксирует требования — какие статусы платежа бывают, когда показывать ошибку, что писать в чек.
• Разработчик реализует форму оплаты и интеграцию с платёжным API.
• Тестировщик проверяет ожидаемое и фактическое поведение — позитивный путь, ошибки карты, таймауты, повторные нажатия.
• Команда заводит дефекты, расставляет severity/priority, чинит и перепроверяет.
• Перед релизом выполняют smoke и целевой регресс по оплате.

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

---

Мифы о профессии (что слышат новички)

Фразы из разряда "а я думал(а), что…" встречаются на каждом потоке обучения. Короткие ответы помогают не строить ожидания на фантазиях.

Миф	Как обычно бывает на практике
"Можно без компьютера"	Без понимания ОС, сети, браузера и данных проверять продукт почти нереально
"Обязательно отлично знать программирование"	Помогает, особенно для автоматизации; для ручного QA достаточно базовой технической грамотности
"На курсе научат всему"	Курс задаёт направление; IT меняется быстро — самообучение на всю карьеру
"В тестирование идут те, кто не стал программистом"	В профессию приходят осознанно и из разработки; мотивация у всех разная
"Карьеры нет"	Треки QA Lead, автоматизация, performance, безопасность, аналитика — см. карьеру в IT
"Тестировщик виноват во всех багах"	QA измеряет риск; ответственность за релиз несёт команда
"Скоро всё заменит автоматизация"	Автоматизация снимает рутину; анализ требований, тест-дизайн и исследование остаются за людьми

Дополнительно — цикл "The 7 Plagues of Software Testing" (James Whittaker) для опытных; новичкам достаточно таблицы выше.

---

Частые ошибки новичков и как их избежать

• "Тестирование начинается после кода" — полезнее подключаться на этапе требований и критериев приёмки.
• "Если тесты зелёные, продукт готов" — зелёные тесты подтверждают покрытые сценарии; риск в непокрытых сценариях остаётся.
• "Баг — это всегда ошибка разработчика" — источником проблемы часто бывают требования, данные, интеграции или окружение.
• "Автотесты заменят ручное тестирование" — ручные проверки и исследовательский подход остаются критичными для UX и новых областей.
• "Негативный тест должен "уронить" программу" — см. callout "Успешный негативный тест" в разделе про позитивное и негативное тестирование выше.

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

---

Боевой кейс — triage после инцидента

Ситуация: после релиза часть пользователей получает ошибку при оплате.

• Поддержка передаёт в QA примеры заказов и время сбоев.
• QA воспроизводит проблему на preprod с похожими данными.
• В баг-репорте фиксируются шаги, фактический результат, логи и приоритет.
• На triage команда определяет severity, влияние на бизнес и план фикса.
• После исправления выполняют confirmation по дефекту и целевой регресс зоны оплаты.

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

---

Шаблон артефакта — краткий баг-репорт

Минимальный рабочий шаблон для трекера:

Заголовок: [PAYMENT] Ошибка 500 при оплате картой Visa
Окружение: preprod, build 2.14.0, Chrome 125, Windows 11
Шаги:
1) Открыть корзину с товаром X
2) Выбрать карту Visa
3) Нажать "Оплатить"
Ожидаемо: успешная оплата, статус "Оплачен"
Фактически: HTTP 500, заказ остаётся в статусе "Создан"
Severity/Priority: Critical / High
Вложения: скриншот, лог запроса, trace id

Шаблон хорошо сочетается с документацией тестировщика и ускоряет triage.

---

Готовые поля для Jira и YouTrack

Issue Type: Bug
Summary: [AREA] Короткое описание проблемы
Environment: build, стенд, браузер/ОС
Preconditions: данные и роль пользователя
Steps to Reproduce: 1..N
Expected Result: ...
Actual Result: ...
Severity: Blocker/Critical/Major/Minor
Priority: High/Medium/Low
Attachments: screenshot, log, trace id
Linked Issues: релиз, родительская задача, дубликаты

Пример заполнения:

Issue Type: Bug
Summary: [CHECKOUT] Двойное списание при повторном клике "Оплатить"
Environment: build 2.15.3, preprod, Chrome 125, Windows 11
Preconditions: пользователь авторизован, в корзине 1 товар
Steps to Reproduce:
1) Открыть checkout
2) Нажать "Оплатить" дважды с интервалом < 1 сек
Expected Result: одна транзакция и один заказ
Actual Result: две транзакции, один заказ в дубле
Severity: Critical
Priority: High
Attachments: video.mp4, payment.log, trace id 9f2a...
Linked Issues: REL-482, PAY-319

---

Куда двигаться дальше

Если вам нужно…	Откройте
Разложить виды тестов по полочкам	Классификация видов тестирования
Понять процесс от плана до отчёта	Жизненный цикл тестирования
Научиться оформлять кейсы и баги	Документация тестировщика
Ручная проверка веба	Ручное тестирование веб-приложений — чек-листы UI и Network
SQL для проверки данных	SQL для тестировщика — SQL для тестировщика
UI-автоматизация	Playwright или Selenium
Выбирать, что проверять	Техники проектирования тестов
Насколько "сильны" unit-тесты	Мутационное тестирование
Полный маршрут по разделу	О разделе

Про severity и priority

Severity (серьёзность) — насколько больно системе.

Priority (приоритет) — насколько срочно чинить.

Критический баг в редкой настройке может иметь низкий приоритет.

Подробнее с примерами — в документации тестировщика.

---

Навигация по разделу "Тестирование"

• Маршрут: О разделе · Резюме раздела · Карта уровней и практик (Unit / Integration / UI / E2E, TDD, BDD)
• Теория и процесс: Основы · Классификация · Жизненный цикл · Порядок этапов · Артефакты качества
• Уровни проверок: Unit · Integration · E2E, системное и UI · API · Тестовые дублёры · Покрытие кода · White-box · Мутационное тестирование
• Практика QA: Документация · Тест-дизайн · Ручное веб · SQL
• Автоматизация: Стратегия и пирамида · Каталог инструментов · Selenium · Playwright
• Практикум и углубление: Подготовка среды и создание первого теста · Проверка взаимодействия компонентов · Проверка пользовательского сценария · Проверка надежности под нагрузкой · Мобильное · Нагрузка · Безопасность · Самопроверка · Доп. материалы курса · Инструменты с низким кодом для тестирования · Тестирование нейроморфных систем

---