сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Теория тестирования

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

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

173 вопросов в банке·13 подтем·ниже разбор 9

Что спрашивают

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

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

Разборы подтем

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

Примеры вопросов с разбором

  1. #docs_defects1 / 9
    Что такое тест-кейс и что в нём обязательно должно быть?
    A)Предусловия, шаги, тестовые данные и ожидаемый результат — воспроизводимая проверка
    B)Список шагов, которые нужно выполнить, без указания ожидаемого результата
    C)Отчёт о найденном дефекте с шагами воспроизведения, серьёзностью и приоритетом ошибки
    D)Общий план тестирования проекта с расписанием, ресурсами и распределением ролей в команде
    показать ответ и разбор
    +A)Предусловия, шаги, тестовые данные и ожидаемый результат — воспроизводимая проверка

    // разбор: Тест-кейс — формализованное описание одной проверки, которое любой исполнитель может повторить одинаково. Обязательные элементы: идентификатор/название, предусловия (состояние системы до), шаги выполнения по порядку, тестовые данные, и — ключевое — ожидаемый результат, с которым сравнивают фактический. Без ожидаемого результата это не тест-кейс: непонятно, пройден он или нет. Хороший кейс атомарен (проверяет одну вещь), однозначен и не зависит от того, кто его выполняет. Кейсы часто связывают с требованиями (трассируемость), чтобы видеть покрытие. Именно наличие ожидаемого результата отличает тест-кейс от простого списка действий.

  2. #fundamentals2 / 9
    Какова главная цель тестирования ПО?
    A)Дать стейкхолдерам информацию о качестве и рисках продукта — для решения о релизе
    B)Доказать, что в программе нет ни одного дефекта и она работает правильно
    C)Исправить все найденные ошибки в коде продукта до его выхода в продакшен
    D)Написать как можно больше тест-кейсов, чтобы формально закрыть требования по документации
    показать ответ и разбор
    +A)Дать стейкхолдерам информацию о качестве и рисках продукта — для решения о релизе

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

  3. #levels3 / 9
    Какие основные уровни тестирования выделяют в порядке снизу вверх?
    A)Модульное → интеграционное → системное → приёмочное: от компонентов ко всей системе
    B)Дымовое → регрессионное → нагрузочное → приёмочное, по возрастанию сложности проверок
    C)Ручное → автоматизированное → нагрузочное → пользовательское, по способу выполнения проверок
    D)Приёмочное → системное → интеграционное → модульное, строго от общего к частному компоненту
    показать ответ и разбор
    +A)Модульное → интеграционное → системное → приёмочное: от компонентов ко всей системе

    // разбор: Уровни тестирования соответствуют этапам сборки системы и идут от мелкого к крупному. Модульное (unit) проверяет отдельный компонент/функцию в изоляции. Интеграционное — как модули взаимодействуют между собой и через интерфейсы. Системное — всю собранную систему целиком против требований. Приёмочное (acceptance/UAT) — готовность продукта к передаче, проверяет заказчик/бизнес под реальные сценарии. Каждый уровень ловит свой класс дефектов: unit — логику компонента, интеграционное — стыки, системное — сквозное поведение, приёмочное — соответствие ожиданиям бизнеса.

  4. #nonfunctional4 / 9
    Что проверяет нагрузочное тестирование (performance)?
    A)Поведение системы под нагрузкой: время отклика, пропускную способность, стабильность
    B)Соответствие пользовательского интерфейса макетам и принятым гайдлайнам дизайна
    C)Правильность бизнес-логики приложения на типовых пользовательских сценариях
    D)Устойчивость приложения к взлому, инъекциям и утечкам чувствительных данных
    показать ответ и разбор
    +A)Поведение системы под нагрузкой: время отклика, пропускную способность, стабильность

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

  5. #process_tools5 / 9
    Что такое спринт в Scrum?
    A)Совещание всей команды в начале каждого рабочего дня
    B)Фиксированная итерация (1–4 недели) с готовым инкрементом на выходе
    C)Формальный документ с полным списком требований к продукту на год вперёд
    D)Роль в команде, которая отвечает за приоритеты продуктового бэклога
    показать ответ и разбор
    +B)Фиксированная итерация (1–4 недели) с готовым инкрементом на выходе

    // разбор: Спринт — короткая итерация фиксированной длины (обычно 1–4 недели): команда берёт объём работ из бэклога и к концу выдаёт потенциально готовый инкремент продукта. Внутри спринта — планирование, ежедневная работа, ревью и ретроспектива. Для тестировщика важно, что тестирование идёт внутри спринта, а не после: тест-дизайн начинается с разбора требований, а не когда фича «уже готова». Спринт — не совещание и не документ.

  6. #qa_observability6 / 9
    Зачем в логах приложения разделяют уровни DEBUG, INFO, WARN, ERROR?
    A)Чтобы логи разных уровней складывались в разные файлы и не занимали общий диск
    B)Чтобы фильтровать записи по важности: на проде оставляют INFO и выше, DEBUG шумит
    C)Чтобы уровнем задать язык сообщения: ERROR по-английски, INFO на языке пользователя
    D)Чтобы система по уровню сама решала, какие из ошибок чинить автоматически, не привлекая разработчика
    показать ответ и разбор
    +B)Чтобы фильтровать записи по важности: на проде оставляют INFO и выше, DEBUG шумит

    // разбор: Уровень — это метка важности записи. Она позволяет управлять детализацией и быстро находить нужное: DEBUG — подробности для отладки (шумно, на проде обычно выключен), INFO — нормальный ход событий, WARN — подозрительное, но не сломавшее работу, ERROR — то, что реально упало. На проде фильтруют от INFO и выше, а при разборе инцидента временно включают DEBUG. Тестировщику это ускоряет диагностику: он идёт сразу к ERROR/WARN около времени бага, а не читает весь поток.

  7. #stlc_process7 / 9
    Что описывает STLC (software testing life cycle)?
    A)Фазы процесса тестирования: планирование, дизайн кейсов, выполнение, завершение
    B)Этапы написания и компиляции исходного кода приложения от анализа до сборки релиза
    C)Уровни тестирования — модульное, интеграционное, системное и приёмочное по порядку
    D)Жизненный цикл дефекта от его обнаружения и регистрации до финального закрытия
    показать ответ и разбор
    +A)Фазы процесса тестирования: планирование, дизайн кейсов, выполнение, завершение

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

  8. #types8 / 9
    Чем функциональное тестирование отличается от нефункционального?
    A)Функциональное — что делает система; нефункциональное — как: скорость, надёжность, удобство
    B)Функциональное выполняется вручную, а нефункциональное — автоматизированными инструментами
    C)Функциональное проверяет скорость и надёжность, а нефункциональное — корректность бизнес-функций
    D)Нефункциональное тестирование не связано с требованиями и проводится без каких-либо критериев
    показать ответ и разбор
    +A)Функциональное — что делает система; нефункциональное — как: скорость, надёжность, удобство

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

  9. #boundary_values9 / 9
    Почему ошибки в программах особенно часто проявляются на границах диапазонов?
    A)Границы кодируются условиями сравнения (< vs ≤), где легко ошибиться на единицу (off-by-one)
    B)Потому что на границах диапазона данные физически хранятся в другой области памяти
    C)Потому что пользователи чаще всего вводят именно крайние значения полей на практике
    D)Потому что граничные значения дольше обрабатываются процессором и вызывают таймауты
    показать ответ и разбор
    +A)Границы кодируются условиями сравнения (< vs ≤), где легко ошибиться на единицу (off-by-one)

    // разбор: Граница диапазона в коде — это оператор сравнения: age >= 18, count < limit. Именно здесь программисты чаще всего ошибаются: путают < и ≤, включают лишний или теряют крайний элемент (off-by-one), неверно обрабатывают равенство границе. Середина диапазона проходит через ту же ветку и такими ошибками не задета, а край — задет напрямую. Поэтому тесты на самих граничных значениях и их соседях ловят непропорционально много дефектов относительно своего числа.

это 9 из 173

Ещё 164 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше