Error — человеческая ошибка в требованиях, дизайне или коде.
Defect/bug/fault — технический изъян в артефакте, а failure — уже проявившийся сбой в работе системы.
Из практики: эта цепочка помогает правильно описывать причину и не путать источник проблемы с её симптомом.
Частые ошибки
Используют дефект/defect/fault/failure как взаимозаменяемые слова, теряя точность.
Забывают, что ошибки могут быть не только в коде: требования неверны – это тоже ошибка (error) аналитика, влекущая дефект в постановке задачи.
Дополнительные вопросы
Почему важно различать причину дефекта и симптом (failure) при анализе инцидента?
Как вы исправляете error в требованиях, если уже реализован код по ним (валидация требований)?
Что такое тестирование и какова его цель?
Junior
Тестирование — это проверка продукта, чтобы понять, насколько он соответствует ожиданиям и требованиям.
Главная цель — снизить риски релиза и дать команде прозрачную картину качества.
Из практики: хороший результат тестирования — это не только найденные дефекты, но и понятные решения по выпуску.
Частые ошибки
Сводят тестирование к поиску багов вместо управления рисками.
Нет явной цели теста.
Дополнительные вопросы
Какие риски вы уменьшаете текущим набором тестов?
Как измеряете уверенность перед релизом?
В чём разница между QA, QC и тестированием?
Junior
QA — это система процессов, которая предотвращает дефекты заранее.
QC — контроль качества готового результата, а тестирование — один из основных инструментов QC.
Из практики: когда фокус только на тестах без QA-процессов, одни и те же проблемы повторяются в каждом релизе.
Частые ошибки
Смешивают роли и процессы.
Утверждают, что QA = тестирование.
Дополнительные вопросы
Приведите пример QA-активности, не связанной с тестами?
Какой артефакт относится к QC?
Когда начинать тестирование в SDLC и почему это важно?
Junior
Тестирование стоит начинать с этапа требований: так риски и противоречия выявляются до разработки.
В V-модели это видно наглядно: каждому этапу разработки (требования, дизайн, код) параллельно сопоставлен уровень тестирования (приёмочное, интеграционное, модульное), а тест-дизайн стартует вместе с этим этапом.
Ранний старт экономит время и стоимость исправлений: баги не успевают «прорасти» в архитектуру и код.
Из практики: участие QA в груминге и дизайне задачи снижает число критичных сюрпризов перед релизом.
Частые ошибки
Ожидание готового билда для старта работы.
Нет участия в уточнении требований.
Дополнительные вопросы
Как вы участвуете в уточнении требований?
Какие артефакты нужны до билда?
Какие уровни тестирования вы используете и зачем?
Junior
Модульный уровень проверяет отдельные функции и классы, интеграционный — взаимодействие компонентов.
Системный уровень проверяет продукт целиком, а приёмочный подтверждает, что решение подходит бизнесу и пользователю.
Из практики: проблемы на стыках чаще ловятся на интеграционном уровне, даже если модульные тесты зелёные.
Частые ошибки
Путают интеграционное с системным.
Нет связки с рисками.
Дополнительные вопросы
Пример тестов на каждом уровне?
Как решаете, где тестировать?
Какие бывают виды тестирования?
Junior
По цели чаще выделяют функциональные и нефункциональные проверки.
По уровню — модульные, интеграционные, системные и приёмочные.
Из практики: набор видов выбираю по рискам конкретного релиза, а не по шаблону.
Частые ошибки
Перемешивают разные классификации.
Упускают нефункциональные виды.
Дополнительные вопросы
Какие виды тестирования нужны для проверки нефункциональных требований?
Что такое альфа- и бета-тестирование?
В чём разница между верификацией и валидацией?
Junior
Верификация отвечает на вопрос «правильно ли мы строим продукт по спецификации».
Валидация отвечает на вопрос «решает ли продукт реальную задачу пользователя».
Из практики: можно пройти верификацию и всё равно провалить валидацию, если неверно поняли пользовательскую потребность.
Частые ошибки
Смешивают понятия: напр., считают, что достаточно протестировать готовое ПО (валидация), пренебрегая ранними ревью требований и дизайна (верификация).
Или наоборот, полагаются только на документы и спеки (верификация), не проводя полноценного тестирования с точки зрения пользователя.
Дополнительные вопросы
Какие статические методы используют для верификации на этапе разработки?
Как валидация проводится на этапе приёмочного тестирования?
Какие существуют методы тестирования?
Junior
Ключевые методы: чёрный, белый и серый ящик, а также исследовательское тестирование.
Обычно они комбинируются: бизнес-сценарии проверяем как «чёрный ящик», а технические риски — глубже через API, логи и данные.
Из практики: лучший результат даёт не один метод, а правильное сочетание под конкретный риск.
Частые ошибки
Считают, что тестировщики всегда работают только как «черный ящик» и не смотрят код.
Путают методы с уровнями: например, говорят «интеграционное тестирование – это белый ящик».
Дополнительные вопросы
Когда тестировщику полезно применять знания кода (элементы белого ящика)?
Какие метрики качества кода важны при использовании метода белого ящика?
Каковы принципы тестирования?
Junior
Базовые принципы: тестирование показывает наличие дефектов, но не доказывает их отсутствие; полное тестирование недостижимо.
Нужно начинать рано, учитывать контекст продукта и регулярно обновлять набор проверок.
Из практики: если не пересматривать тесты под новые риски, они перестают находить реальные проблемы.
Частые ошибки
Знают формулировки, но не применяют их: напр., повторяют одни тесты (нарушая принцип про "пестицид"), или откладывают тесты на конец проекта (вопреки принципу раннего тестирования).
Считают принципы абстракцией и не ищут им подтверждение на практике.
Дополнительные вопросы
Как пример принципа "дефекты сконцентрированы" влияет на выбор областей для регрессионного тестирования?
Почему даже после прохождения всех тестов нельзя утверждать, что дефектов нет (какой принцип об этом говорит)?
Что такое «парадокс пестицида»?
Junior
Парадокс пестицида — это ситуация, когда один и тот же набор тестов со временем теряет эффективность.
Команда проходит старые проверки, но новые дефекты остаются незамеченными.
Из практики: поэтому я регулярно обновляю тесты и добавляю свежие сценарии из продовых инцидентов.
Частые ошибки
Игнорируют этот эффект: длительное время используют неизменный набор тестов, теряя покрытие новых изменений.
Неправильно понимают метафору: полагают, что старые тесты вообще не нужны.
Дополнительные вопросы
Как поступить, если все тест-кейсы проходятся долгое время без единого сбоя?
Как автоматизация тестов связана с парадоксом пестицида?
Каковы этапы тестирования?
Junior
Обычно этапы такие: анализ требований, планирование, дизайн проверок, выполнение, отчётность и ретроспектива.
На каждом этапе важна прозрачная коммуникация с командой, чтобы качество не превращалось в отдельный «остров».
Из практики: процесс работает только тогда, когда его реально используют в ежедневной работе, а не держат в документе.
Частые ошибки
Начинают тестирование без подготовки.
Не определяют критерии начала/завершения этапов, из-за чего, например, тестирование может начаться на сыром продукте или не заканчивается вовремя.
Дополнительные вопросы
Какие документы вы создаёте на стадии планирования тестирования?
Что включается в этап завершения тестирования (test closure)?
В чём разница между статическим и динамическим тестированием?
Middle
Статическое тестирование идёт без запуска кода: ревью требований, дизайна, кода и документации.
Динамическое тестирование проверяет систему во время выполнения через реальные сценарии и данные.
Из практики: ранний статический анализ часто дешевле, чем поздний поиск тех же проблем на стенде.
Частые ошибки
Не проводят статическое тестирование вовсе.
Считают, что динамическое тестирование – это только ручные действия, забывая про автоматизированные тесты как часть динамического подхода.
Дополнительные вопросы
Какие инструменты статического анализа кода вы использовали?
Как совмещаются статические и динамические методы в стратегии тестирования?
В чём разница между smoke и санитарным тестированием?
Middle
Smoke — короткая проверка, что сборка в целом живая и основные функции не сломаны.
Sanity — узкая проверка конкретных изменений после фикса или доработки.
Из практики: сначала запускаю smoke, а потом sanity на затронутой зоне — это экономит время в релизный день.
Частые ошибки
Используют термины как синонимы, хотя smoke шире и поверхностнее, а sanity специфичнее и глубже в конкретном участке.
Не выполняют этих быстрых проверок вообще, сразу проводя полный тест, что может быть тратой ресурсов, если сборка изначально негодна.
Дополнительные вопросы
Когда вы обычно выполняете smoke-тесты и кто их проводит?
Можно ли автоматизировать smoke и sanity проверки и какие выгоды этого?
Как вы проверяете юзабилити и доступность (a11y)?
Middle
Юзабилити проверяю через пользовательский сценарий: понятен ли интерфейс без инструкции, нет ли тупиков в навигации, читаемы ли сообщения об ошибках.
Доступность (a11y): навигация с клавиатуры (Tab, Enter, Esc), контраст текста и фона (WCAG AA: минимум 4.5:1), alt-тексты изображений, aria-labels. Инструменты: axe DevTools, Lighthouse CI, NVDA (Windows), VoiceOver (Mac/iOS).
Из практики: автоматические инструменты (axe) ловят ~30% проблем доступности. Остальное требует ручной проверки с экранным читалкой — особенно формы и динамически обновляемые регионы.
Частые ошибки
Тесты только мышью.
Игнорируют screen reader/контраст.
Дополнительные вопросы
Какие WCAG-критерии критичны?
Как проверяете фокус?
Каковы основные фазы STLC?
Middle
STLC обычно включает: анализ требований, план тестирования, подготовку тестов и данных, выполнение, отчёт и закрытие цикла.
Смысл STLC — сделать качество управляемым и предсказуемым по шагам.
Из практики: чёткий цикл особенно полезен на больших проектах с несколькими командами.
Частые ошибки
Смешивают фазы или пропускают их: например, начинают выполнение тестов без этапа дизайна, что снижает эффективность.
Не устанавливают критерии входа/выхода для фаз.
Дополнительные вопросы
Какие Entry и Exit criteria вы используете для фазы выполнения тестов?
Что происходит на фазе планирования помимо составления тест-плана?
Что такое Entry и Exit Criteria?
Middle
Entry Criteria — условия старта тестирования, когда проверка будет осмысленной и не хаотичной.
Exit Criteria — условия завершения, когда команда понимает остаточные риски и готовность к релизу.
Из практики: если критерии не определены заранее, релиз почти всегда уходит в споры и ручной режим.
Частые ошибки
Не определяют эти критерии явно, в итоге начинают тестирование на неподходящей сборке или не знают, когда можно останавливать тестирование перед релизом.
Ставят нереалистичные критерии (например, ноль дефектов вовсе), которые никогда не выполнятся, и фактически игнорируются – что обесценивает идею критериев.
Дополнительные вопросы
Как вы определяете Entry-критерии для приёмочного тестирования?
Что делаете, если Exit Criteria не достигнуты, а сроки релиза наступили?
Чем SDLC отличается от STLC?
Junior
SDLC (Software Development Life Cycle) — это цикл разработки продукта в целом: анализ требований, проектирование, разработка, тестирование, релиз, поддержка.
STLC (Software Testing Life Cycle) — подцикл тестирования: анализ требований к тестированию, планирование, дизайн тест-кейсов, настройка среды, выполнение, закрытие.
Из практики: STLC встраивается в SDLC. QA подключается с самых ранних фаз (анализ требований), а не только на этапе тестирования готового кода.
Частые ошибки
Считать, что QA начинается после кодирования.
Думать, что SDLC и STLC — независимы.
Дополнительные вопросы
Что такое shift-left testing?
На каких этапах SDLC QA приносит больше всего пользы?
Что такое верификация и валидация?
Junior
Верификация — «делаем продукт правильно»: соответствует ли реализация спецификации. Это работа с фактом построения.
Валидация — «делаем правильный продукт»: решает ли продукт реальную потребность пользователя. Это работа с уместностью.
Из практики: можно верифицировать всё, но создать ненужный продукт. И можно сделать правильный продукт с ошибками. QA участвует в обеих активностях.
Частые ошибки
Считать тестирование = только верификация.
Игнорировать валидацию, делая «как написано в задаче».
Дополнительные вопросы
Кто чаще занимается валидацией?
Что такое product market fit?
Чем QA отличается от QC и тестировщика?
Junior
QA (Quality Assurance) — это процессно-ориентированная активность: организовать так, чтобы качество встраивалось в процесс с самого начала. Шире, чем тестирование.
QC (Quality Control) — это проверка готового продукта на соответствие требованиям. По сути — тестирование.
Тестировщик — исполнитель тестов. На практике границы размыты, и часто все три слова используют как синонимы. Но важно понимать, что качество строится в процессе, а не «проверяется» в конце.
Частые ошибки
Считать QA = QC = тестировщик без понимания нюансов.
Unit — тестирование отдельной функции/класса в изоляции. Быстро, точечно, дёшево. Integration — взаимодействие двух или более компонентов (например, сервис и БД). End-to-end — весь поток через систему, как у пользователя.
Пирамида тестирования: больше unit, меньше integration, ещё меньше e2e. E2E дорогие и нестабильные, поэтому их меньше всего.
Из практики: пирамида — ориентир. Реальное распределение зависит от проекта. Главное — не делать только e2e (как «мороженое») или только unit (без интеграционной проверки).
Частые ошибки
Полагаться только на e2e — медленно и хрупко.
Считать, что unit-тесты заменяют интеграцию.
Дополнительные вопросы
Что такое testing trophy?
Где здесь contract testing?
Что такое регрессионное тестирование?
Junior
Регрессионное тестирование — это проверка, что ранее работавшая функциональность не сломалась после изменений в коде.
Применяют после рефакторинга, исправления багов, добавления фич, обновления зависимостей.
Из практики: полная регрессия — долго. Поэтому стараются автоматизировать критичные сценарии и запускать на каждом PR. Ручную регрессию используют для UX-критичных и редкоизменяемых областей.
Частые ошибки
Делать полную ручную регрессию каждый раз — слишком долго.
Не обновлять регрессионный набор — устаревает.
Дополнительные вопросы
Что такое smoke vs regression?
Как выбирать что входит в регрессионный набор?
Что такое smoke и sanity тесты?
Junior
Smoke — это поверхностная проверка, что сборка вообще работает: запускается, основные экраны открываются, главные сценарии проходят. Обычно 5-15 минут.
Sanity — это короткая проверка после внесения изменений в одну область: затронуло ли это смежные функции, ничего не сломалось «по соседству». Уже точечная.
Из практики: на проде «дымит ли» проверяет smoke. Sanity нужен в момент быстрых правок — посмотреть, что не разнесло окрестности.
Частые ошибки
Путать smoke и sanity.
Полагаться на smoke вместо регрессии.
Дополнительные вопросы
Что такое build verification test?
Как автоматизировать smoke на проде?
Какие виды тестирования бывают по знанию о системе (black/white/grey)?
Junior
Black box — тестировщик знает только внешний интерфейс, не знает внутреннюю реализацию. White box — известна внутренняя структура и логика (часто это unit-тестирование самим разработчиком).
Grey box — частичное знание: знаем структуру БД и API, но не внутреннюю логику. Это типичная роль QA-инженера на больших системах.
Из практики: одна и та же команда часто комбинирует подходы: разработчики пишут unit (white), QA — функциональные/integration (grey), пользователи (или бета-тестеры) — UAT (black).
Частые ошибки
Считать, что black box — это только мануальный подход.
Без знания структуры не пользоваться доступной информацией.
Дополнительные вопросы
Что такое UAT?
Какие из видов тестирования автоматизируются легче всего?
Что такое functional и non-functional тестирование?
Junior
Functional проверяет, что система делает то, что должна (правильно работают функции, формы, расчёты, переходы).
Из практики: оба вида одинаково важны. Без функционального продукт не работает; без нефункционального — работает, но плохо (тормозит, небезопасно, неудобно).
Частые ошибки
Фокусироваться только на функциональном.
Откладывать non-functional на «потом».
Дополнительные вопросы
Какие виды non-functional самые ходовые?
Чем UX-тестирование отличается от functional?
Что такое тестовая среда (test environment)?
Junior
Тестовая среда — это окружение, в котором проводят тесты: набор серверов, БД, интеграций, конфигов, тестовых данных, в котором продукт ведёт себя «как на проде, но безопасно».
Типовая иерархия: dev (для разработчиков), test/staging (для QA), pre-prod (приближено к проду), prod (живые пользователи). Между ними отличия — конфиги, данные, обновления.
Из практики: чем ближе test-среда к prod, тем надёжнее результаты тестов. Большой разрыв — типовая причина «у нас работало».
Частые ошибки
Тестировать на dev и сдавать в prod — большой разрыв.
Не следить, чтобы среды были изолированы.
Дополнительные вопросы
Чем dev отличается от staging?
Как готовить тестовую среду к крупному релизу?
Что такое тест-стенд (test stand) и чем отличается от тестовой среды?
Middle
Стенд — это часто физическая или виртуальная конфигурация для конкретного типа тестирования (нагрузочный стенд, security-стенд, мобильный стенд с устройствами).
Тестовая среда — более широкое понятие, включающее всю инфраструктуру (приложение + БД + интеграции).
Из практики: «стенд» обычно про специализацию (где железо/устройства/нагрузка). Среда — про общее окружение продукта.
Частые ошибки
Путать стенд и среду в коммуникации.
Использовать общий стенд для нескольких типов тестирования — конфликты.
Дополнительные вопросы
Что такое device farm как стенд?
Чем отличаются нагрузочный и функциональный стенды?
Из каких этапов состоит SDLC?
Junior
Классические этапы: 1) инициация (идея, цели, ROI); 2) анализ требований; 3) проектирование (архитектура, UX, БД); 4) разработка; 5) тестирование; 6) внедрение (deploy, обучение, миграция); 7) сопровождение и эксплуатация.
В Agile эти этапы не последовательны, а итеративны: каждый спринт включает мини-цикл анализ-дизайн-разработка-тест. Но сами стадии не исчезают.
Из практики: SDLC — не «методология», а скелет процесса. Waterfall и Agile — это разные способы пройти его.
Частые ошибки
Считают, что в Agile «нет анализа и дизайна» — они просто распределены по итерациям.
Игнорируют этап эксплуатации — продукт умирает через год без поддержки.