15 вопросов по теме «QA: Теория тестирования» на собеседовании

Короткий ответ: Верификация отвечает на вопрос «делаем ли мы продукт правильно» — соответствует ли он спецификации и требованиям. Валидация отвечает «делаем ли мы правильный продукт» — решает ли он реальную задачу пользователя. Verification — про соответствие документам, validation — про соответствие ожиданиям.

Подробно:

1. Верификация — проверка соответствия артефакта его спецификации. Часто статическая: ревью требований, инспекция кода, сверка с ТЗ. Отвечает: «построили ли по чертежу?».
2. Валидация — проверка, что готовая система закрывает потребность пользователя. Обычно динамическая: реальное выполнение, приёмочное тестирование, демо заказчику. Отвечает: «а нужен ли был этот чертёж?».
3. Порядок — верификация раньше и дешевле, валидация ближе к релизу.

⚠️ Частая ошибка: сыпать примерами («ревью — это верификация») без двух чеканных формулировок «делаем ли правильно» / «делаем ли правильное». Именно их слушает интервьюер.

Короткий ответ: По ISTQB четыре уровня: модульное (unit), интеграционное, системное и приёмочное. Юнит-тесты пишут разработчики, интеграцию — разработчики и QA, системное — QA, приёмочное — QA вместе с заказчиком/бизнесом. Уровни отражают форму пирамиды: чем ниже, тем больше и дешевле тесты.

Подробно:

1. Unit — отдельный модуль/функция в изоляции. Владелец — разработчик, обычно в CI на каждый коммит.
2. Integration — взаимодействие модулей и внешних систем (API, БД). Владелец — разработчик и/или QA.
3. System — вся система целиком против требований, end-to-end. Владелец — QA.
4. Acceptance (UAT) — готова ли система к передаче с точки зрения бизнеса. Владелец — заказчик/PO при поддержке QA.

⚠️ Частая ошибка: путать уровни тестирования с видами (smoke, регрессия, нагрузочное). Уровень — это про масштаб объекта, вид — про цель проверки; они ортогональны.

Короткий ответ: Виды тестирования удобнее не перечислять списком, а раскладывать по осям классификации: по цели (функциональное / нефункциональное), по знанию кода (black / white / grey box), по степени автоматизации (ручное / автоматизированное) и по этапу/цели прогона (smoke, регрессия, приёмочное). Структура важнее длины списка.

Подробно:

1. По цели — функциональное (что делает система) vs нефункциональное (производительность, безопасность, юзабилити).
2. По доступу к коду — black box (без кода), white box (полное знание), grey box (частичное).
3. По автоматизации — ручное vs автоматизированное.
4. По этапу/цели прогона — smoke, sanity, регрессия, приёмочное.

⚠️ Частая ошибка: вывалить кучу терминов («нагрузочное, дымовое, регрессионное, юзабилити…») без логики группировки. Интервьюер оценивает системность мышления, а не длину списка.

Короткий ответ: Smoke — широкая и поверхностная проверка, что билд вообще живой и его имеет смысл тестировать дальше (ключевые функции запускаются). Sanity — узкая и глубокая проверка одного конкретного фикса или фичи после изменения. Smoke — «в ширину», sanity — «в глубину».

Подробно:

1. Smoke — прогоняем основные сценарии по верхам сразу после сборки: логин открывается, главные страницы грузятся. Если билд «дымит» — возвращаем разработчику, не тратя время на детальное тестирование.
2. Sanity — после точечного изменения проверяем, что именно эта область работает корректно, обычно без полного регресса.
3. Формализация — smoke чаще автоматизирован и задокументирован, sanity бывает неформальным.

⚠️ Частая ошибка: использовать smoke и sanity как синонимы. Это классический трап-вопрос: разница именно в паре «широкий-поверхностный» против «узкий-глубокий».

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

Подробно:

1. Retest — идёт по шагам конкретного дефекта, ожидая, что теперь баг воспроизвести не удаётся. Выполняется точечно и только на пофикшенных багах.
2. Регрессия — набор тестов по смежной и ключевой функциональности; отвечает на вопрос «не сломалось ли то, что раньше работало». Хороший кандидат на автоматизацию, так как повторяется на каждом релизе.
3. Порядок — сперва retest (баг закрыт?), затем регрессия вокруг.

        фикс бага #123
            │
     ┌──────┴───────┐
     ▼              ▼
  retest #123    регрессия
 (те же шаги)  (смежные фичи —
  баг ушёл?    ничего не сломалось?)

⚠️ Частая ошибка: смешивать понятия — «я перетестировал, значит сделал регрессию». Retest — про один баг по тем же шагам, регрессия — про сохранность всего остального.

Короткий ответ: Ось различия — насколько тестировщик знает внутреннее устройство системы. Black box — только вход/выход, взгляд пользователя, без доступа к коду. White box — полное знание кода и структуры (юнит-тесты, покрытие ветвей). Grey box — частичное знание: например, знаешь схему БД и API, но не исходники.

Подробно:

1. Black box — тестируем поведение по требованиям, не заглядывая в код. Техники: классы эквивалентности, граничные значения. Взгляд конечного пользователя.
2. White box — тестируем структуру: ветви, условия, пути. Нужен доступ к коду; типично для разработчиков и юнит-тестов.
3. Grey box — гибрид: часть внутренностей известна (структура БД, контракты API), что помогает точнее готовить данные и проверять интеграции.

⚠️ Частая ошибка: путать эти методы с уровнями тестирования (unit / integration / system). Box-подход — про доступ к коду, уровень — про масштаб объекта; на одном уровне можно применять разные подходы.

Короткий ответ: SDLC (Software Development Life Cycle) — весь жизненный цикл разработки продукта от идеи до поддержки. STLC (Software Testing Life Cycle) — цикл тестирования внутри него: от анализа требований до закрытия тестов. STLC не идёт «после разработки», а вплетён в SDLC с самых ранних фаз (shift-left).

Подробно:

1. SDLC — фазы: требования → проектирование → разработка → тестирование → внедрение → поддержка.
2. STLC — фазы: анализ требований → планирование → дизайн тест-кейсов → подготовка окружения → выполнение → закрытие.
3. Связь (shift-left) — тестирование стартует уже на анализе требований (ищем неясности и противоречия статически), а не только на готовом билде.

Анализ треб. → Планирование → Дизайн кейсов
     → Настройка окружения → Выполнение → Закрытие

⚠️ Частая ошибка: считать SDLC и STLC одним и тем же или ставить тестирование только «в конце, после разработки». Ранний старт STLC (shift-left) ловит дефекты, когда чинить их дешевле всего.

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

Подробно:

1. Наличие дефектов — тесты доказывают, что баги есть, но не могут доказать, что их нет.
2. Исчерпывающее невозможно — все комбинации входов не проверить; нужны приоритеты и риск-анализ.
3. Раннее тестирование — чем раньше найден дефект, тем дешевле фикс (shift-left).
4. Кластеризация дефектов — ~80% багов концентрируются в ~20% модулей (принцип Парето).
5. Парадокс пестицида — одни и те же тесты со временем перестают находить новое; кейсы надо обновлять.
6. Зависимость от контекста — банкинг и игру тестируют по-разному.
7. Заблуждение об отсутствии ошибок — продукт без багов, но не решающий задачу пользователя, всё равно провальный.

⚠️ Частая ошибка: путать «заблуждение об отсутствии ошибок» (нашли все баги, но продукт не тот) с «невозможностью исчерпывающего тестирования» (нельзя проверить всё). Это разные принципы.

Короткий ответ: Пирамида тестирования — модель распределения автотестов по слоям: много быстрых и дешёвых unit-тестов в основании, меньше API/интеграционных в середине и минимум медленных UI/E2E-тестов на вершине. UI-тестов меньше всего, потому что они самые медленные, хрупкие (флаки) и дорогие в поддержке.

Подробно:

1. Unit (основание) — тысячи тестов, миллисекунды, ловят баги на уровне логики, быстрый фидбэк разработчику.
2. Integration / API (середина) — проверяют связки и контракты; их меньше, они медленнее.
3. UI / E2E (вершина) — их единицы, гоняют через реальный интерфейс; медленные, ломаются от любой мелочи в вёрстке, дорого чинить.

        /\        UI / E2E   — мало, медленно, флаки
       /  \
      /----\      Integration / API
     /      \
    /--------\    Unit — много, быстро, дёшево

⚠️ Частая ошибка: назвать слои, но не объяснить «почему». Интервьюер ждёт именно причину: скорость обратной связи и стоимость поддержки. Перевёрнутая пирамида (много E2E) — антипаттерн «ice-cream cone».

Короткий ответ: Функциональное тестирование проверяет, что система делает — соответствует ли поведение требованиям (кнопка «Оплатить» списывает деньги). Нефункциональное проверяет, насколько хорошо она это делает — производительность, безопасность, юзабилити, надёжность (оплата проходит за 2 секунды под нагрузкой).

Подробно:

1. Функциональное — по функциональным требованиям: логин, поиск, оформление заказа, расчёты. Ответ «да/нет: работает как в спеке».
2. Нефункциональное — по атрибутам качества: скорость, устойчивость к нагрузке, защищённость, доступность, удобство. Ответ измеряется в цифрах (latency, RPS, uptime).
3. Оба нужны — функционально верная, но тормозящая или дырявая по безопасности система всё равно непригодна.

⚠️ Частая ошибка: давать определения без примеров и без чеканной пары «что делает» vs «насколько хорошо». Пример на каждую сторону закрывает вопрос.

Короткий ответ: Это четыре вида нагрузочного тестирования по профилю нагрузки. Load — ожидаемая/пиковая штатная нагрузка. Stress — за пределы возможностей, до точки отказа. Soak (endurance) — умеренная нагрузка на длинной дистанции (утечки памяти, деградация). Spike — резкий короткий всплеск и возврат.

Подробно:

1. Load — держим прогнозируемое число пользователей; проверяем, что метрики (latency, RPS) в SLA.
2. Stress — наращиваем нагрузку выше нормы, чтобы найти точку отказа и понять, как система деградирует и восстанавливается.
3. Soak / endurance — часы-сутки под нагрузкой; ловим утечки памяти, распухание логов, деградацию во времени.
4. Spike — мгновенный скачок (распродажа, рассылка) и резкий спад; проверяем эластичность и авто-скейлинг.

⚠️ Частая ошибка: смешивать load и stress. Load — «выдержит ли штатную нагрузку», stress — «где сломается и как поведёт себя за пределом». Даже ручной QA обязан знать эту таксономию.

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

Подробно:

1. Суть — тестировщик учится на ходу: результат каждого шага подсказывает следующий. Дизайн и выполнение слиты воедино.
2. Когда сильнее — новая фича без чётких требований, юзабилити, «а что если», охота на неочевидные баги, нехватка времени на формальные кейсы.
3. Session-based (SBTM) — чтобы это не было хаосом: фиксированный тайм-бокс (60–90 мин), charter (цель сессии) и заметки по ходу.

⚠️ Частая ошибка: называть exploratory «хаотичным тыканьем без плана». Это структурированный подход: session-based testing, charters и логи сессий делают его управляемым и отчётным.

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

Подробно:

1. Статическое — ревью требований, инспекция кода, walkthrough, статический анализ (линтеры, SonarQube). Находит дефекты в документах и коде до запуска, часто на этапе требований.
2. Динамическое — прогон тест-кейсов, unit/integration/system, нагрузочное. Требует собранного, работающего билда.
3. Экономика — исправление дефекта, найденного на ревью требований, в разы дешевле, чем в проде; отсюда ценность статики и shift-left.

⚠️ Частая ошибка: считать, что тестирование начинается только с готового билда. Это противоречит принципу раннего тестирования: статические проверки требований — тоже полноценное тестирование.

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

Подробно:

Что с этим делать:

1. Регулярно пересматривать и обновлять кейсы — добавлять новые проверки под изменившуюся функциональность и найденные в проде баги.
2. Добавлять exploratory-сессии — незаскриптованное тестирование находит то, что фиксированный набор пропускает по определению.
3. Варьировать тестовые данные — новые входы, граничные значения, комбинации, а не один и тот же датасет.
4. Ротировать и чистить набор — выносить устаревшие кейсы, дописывать под новые риски.

⚠️ Частая ошибка: воспринимать зелёный прогон регресса как «багов нет». Стабильно зелёные неизменные тесты чаще означают, что они просто перестали искать новое, а не что качество идеально.

Короткий ответ: Нет. QA (Quality Assurance) — про процессы и предотвращение дефектов (process-oriented). QC (Quality Control) — про контроль качества уже готового продукта (product-oriented). Тестирование — это инструмент внутри QC. Отношение вложенное: QA ⊃ QC ⊃ тестирование.

Подробно:

1. QA — выстраивает процессы, стандарты, ревью, чтобы дефекты не возникали (proactive, о процессе). Пример: внедрение code review и Definition of Done.
2. QC — проверяет готовый продукт на соответствие требованиям, ловит уже допущенные дефекты (reactive, о продукте).
3. Тестирование — конкретная активность QC: выполнение тест-кейсов, поиск багов.

┌──────────────────────────────┐
│ QA — процессы, профилактика  │
│  ┌────────────────────────┐  │
│  │ QC — контроль продукта │  │
│  │   ┌─────────────────┐  │  │
│  │   │  Тестирование   │  │  │
│  │   └─────────────────┘  │  │
│  └────────────────────────┘  │
└──────────────────────────────┘

⚠️ Частая ошибка: использовать QA, QC и тестирование как синонимы. Ключевое различие: QA предотвращает дефекты (процесс), QC обнаруживает их (продукт), тестирование — частный метод обнаружения.