Зачем нужно тестирование и чем QA отличается от QC

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

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

Вопрос 1: «Зачем нужно тестирование, если разработчики — профессионалы?»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

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

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

stages = [
    ("Требования", 1),
    ("Дизайн", 5),
    ("Разработка", 10),
    ("Тестирование", 15),
    ("Продакшен", 100),
]

base = 500  # рублей на исправление на самой ранней стадии
for name, k in stages:
    print(f"{name:<14} x{k:>3}  => {base * k:>6} руб.")

Вывод:

Требования     x  1  =>    500 руб.
Дизайн         x  5  =>   2500 руб.
Разработка     x 10  =>   5000 руб.
Тестирование   x 15  =>   7500 руб.
Продакшен      x100  =>  50000 руб.

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

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

Вопрос 2: «Чем QA отличается от QC и от тестирования?»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

QA предупреждает (ревью требований, code review, договорённости о Definition of Done, настройка CI), QC обнаруживает (проверка результата), тестирование — конкретная деятельность внутри QC. Тестирование входит в QC, QC входит в QA — три вложенные окружности.

Полезно добавить: в российских вакансиях «QA-инженер» почти всегда означает именно тестировщика, и работодатель ждёт от вас обеих ролей — и проверять сборки, и улучшать процесс (например, предлагать чек-листы приёмки или требовать логи от разработчиков).

Вопрос 3: «Verification vs validation»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

• Verification — «делаем ли мы продукт правильно?» Сверка с документом: требованиями, макетом, спецификацией API. Ответ формальный: поле обязательное — значит должно быть обязательным.
• Validation — «делаем ли мы правильный продукт?» Сверка с реальной потребностью. Форма может идеально совпадать с макетом, но пользователь не может ею воспользоваться.

Классический пример: в требованиях написано «пароль не короче 6 символов» — тест на 5 и 6 символов проходит, verification зелёная. Но безопасники скажут, что 6 символов в 2026 году не защищают ни от чего: validation провалена, ошибка не в коде, а в требовании.

Мостик к практике: verification — это ваши тест-кейсы по документации, validation — приёмочное тестирование, пользовательские сценарии, UX-замечания и вопрос «а зачем эта фича?» на груминге.

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

• Определяют тестирование как «поиск багов». Тогда логичный вопрос интервьюера: «а если багов не нашли — вы плохо работали?» Правильная рамка: тестирование даёт информацию о качестве, отсутствие находок — тоже информация.
• Заучивают, что QA «шире, чем QC», но не могут привести ни одного примера работы с процессом.
• Путают verification и validation местами. Мнемоника: verification — по бумаге, validation — по жизни.
• Обещают «протестировать всё». Исчерпывающее тестирование невозможно — это один из семи классических принципов тестирования, и на собеседовании его любят.

Как ответить кратко

Тестирование нужно, потому что цена дефекта растёт по мере движения к продакшену: то, что стоит полчаса на этапе требований, в проде стоит горячий фикс и потерянных пользователей. Тестирование даёт бизнесу информацию для решения о релизе, а не просто список багов. QA — работа с процессом, чтобы дефекты не появлялись; QC — проверка готового продукта; тестирование — конкретная проверка сборки. Verification отвечает на вопрос «сделали ли по спецификации», validation — «решает ли это задачу пользователя»; продукт может пройти первое и провалить второе.