Вопросы на собеседовании тестировщика: тест-дизайн и разбор дефекта

Отвечая на вопрос «как проверить возврат?», сначала уточните правило, по которому определите правильный результат. Если не уточнены комиссия и точная граница времени, длинный список тестов может проверять ваше предположение. А когда правило уже согласовано, даже один неверный знак сравнения становится воспроизводимым дефектом.

Разберём авторскую функцию допуска возврата: уточним условие, выведем проверки, воспроизведём ошибку на границе и подготовим сообщение разработчику. Для тренировки используйте Testing a New Feature: Planning Test Cases and Handling Flaky Tests, связывая каждый тест с правилом и ожидаемым результатом.

Граница доказательств: официальная программа ISTQB даёт терминологию тестирования. Правила возврата, таблицы, дефект и приоритеты ниже — оригинальное учебное упражнение. Они не описывают закон, условия магазина, отчёт кандидата или частоту вопросов работодателя. Выполнены 30 локальных проверок Python-модели; платёжный провайдер, API и интерфейс не запускались, деньги не возвращались.

Что уточнить в исходном требовании?

Начальная формулировка вымышленного продукта: «Пользователь может вернуть стоимость билета, если отменяет не позднее чем за 48 часов до мероприятия. Исключения согласует менеджер». Она оставляет несколько вопросов, влияющих на результат.

Входит ли сервисная комиссия в стоимость? Что означает ровно 48 часов? Какая временная зона используется? Можно ли запросить часть суммы и повторный возврат? Что происходит, если предыдущий запрос ещё выполняется? Как подтверждается исключение менеджера?

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

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

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

Как вывести классы и границы из этих правил?

ISTQB CTFL 4.0.1 описывает классы эквивалентности как группы входов с одинаковой ожидаемой обработкой, а граничный анализ — как проверку краёв упорядоченных классов. Ниже эти техники применены к нашей модели, а не скопированы из примера программы.

Для суммы при уже возвращённых 4 000 остаток равен 6 000. Разделите целые значения на неположительные, допустимые от 1 до 6 000 и превышающие остаток. Отдельно рассмотрите неверные типы: дробь, строку, NULL и Boolean. Они могут попадать в иной путь обработки до проверки диапазона.

Минимальные полезные границы: 0, 1, 6 000, 6 001. Проверка «запросить 3 000» подтверждает только внутреннее значение допустимого диапазона. Она не обнаружит ошибку, допускающую сумму на одну единицу больше остатка.

Для времени зафиксируйте точность упражнения в одну секунду и возьмите 48 часов плюс секунду, ровно 48 часов и 48 часов минус секунду до начала. На каждой проверке остальные условия должны быть допустимыми. Иначе отказ из-за состояния оплаты может скрыть неправильную временную границу.

Не называйте три точки доказательством всех часовых поясов и переходов времени. В локальном наборе сравниваются UTC и один эквивалентный момент с фиксированным смещением +03:00. Проверок интерфейса, региональных правил или переходов летнего времени нет.

Зачем нужна таблица решений, если есть границы?

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

Последняя строка полезна для уточнения UX: что показать при нескольких ошибках? Контракт уже позволяет проверить отсутствие допуска, но не даёт основания требовать конкретный текст первой ошибки. Не путайте определённый бизнес-результат и ещё не согласованный приоритет сообщений.

Здесь таблица не покрывает каждый недопустимый тип или каждое состояние провайдера. Для captured, failed и cancelled нужны отдельные представители; для RUB и rub — проверка точного принятого формата. Подсчитывая покрытие, назовите конкретные выбранные правила и классы, а не обещайте «100% тестирования продукта».

Как воспроизвести дефект ровно на 48 часах?

Начало мероприятия задано как 2026-10-12T18:00:00+00:00. Запрос приходит 2026-10-10T18:00:00+00:00, сумма 6 000, ранее возвращено 4 000, captured, RUB. Все условия, кроме проверяемой границы, заведомо допустимы.

В дефектной версии условие написано как delta > timedelta(hours=48). Оно отклоняет равенство. Исправленная версия использует >=. В сохранённом defect-evidence.json для одинаковых аргументов указаны buggy_actual: false и fixed_actual: true.

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

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

Что должно попасть в воспроизводимый отчёт?

По разделу ISTQB о дефектах отчёт должен помогать воспроизвести проблему и сопоставить ожидаемый результат с фактическим. Для этого кейса достаточно следующего оригинального пакета:

Заголовок: «Ровно за 48 часов допустимый запрос отклоняется строгим сравнением».

Объект и среда: локальная функция eligible, Python 3.12.14, UTC, дефектная ветка с inclusive=False. Реального номера сборки приложения нет.

Предусловия: база 10 000, ранее подтверждено 4 000, запрошено 6 000, captured/RUB. Начало и запрос имеют точные значения из предыдущего раздела.

Шаги: вызвать модель на этих аргументах в дефектной ветке; записать Boolean-результат; повторить на исправленной ветке с теми же аргументами.

Ожидание: допуск True по правилу включённой границы. Факт: False; исправленная ветка возвращает True.

Приложения: входные значения и результаты сохранены в defect-evidence.json; отдельный список содержит все 30 проверок. Скриншота ошибки интерфейса нет, потому что интерфейс не тестировался.

Указывайте HTTP-код или текст уведомления только после наблюдения в соответствующем API или интерфейсе. Модель возвращает Boolean, и это единственное наблюдение данного опыта. Для API-репродукции потребовались бы реальный запрос, ответ, идентификатор окружения и проверка состояния после вызова.

Как выбрать первые проверки по риску?

ISTQB связывает оценку риска с вероятностью и последствиями. В нашем упражнении порядок ниже — авторское качественное решение без статистики сбоев. Оно не является универсальной шкалой работодателя.

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

После проверки допуска и лимита переходите к тексту отказа, отображению комиссии и доступности элементов формы. Но если основная задача команды — доступность интерфейса для пользователей, приоритет визуально небольшого дефекта может измениться. Объясняйте контекст и последствия вместо автоматического правила «всё, связанное с деньгами, всегда P0».

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

Что показывают 30 проверок и чего они не доказывают?

В локальном наборе есть временная тройка, границы суммы и ранее возвращённой части, состояния оплаты, регистр валюты, неверные типы, эквивалентный момент +03:00, отклонение времени без зоны и сравнение дефектной/исправленной ветвей. Сохранённый запуск завершился PASS 30.

Официальная документация Python datetime различает время с информацией о зоне и без неё. Модель отвергает вход без зоны вместо догадки о его значении. Тест на +03:00 использует тот же момент, а не просто те же цифры часов.

Ещё одна техническая ловушка: Boolean в Python является подтипом int. Поэтому модель проверяет точный тип суммы; True не проходит как одна минимальная единица. Это наблюдаемая особенность конкретной реализации проверки, а не требование всех языков или API.

Две отдельные проверки демонстрируют ограничение модели. Два независимых вызова по 8 000 при исходном остатке 10 000 оба получают допуск; их сумма 16 000 больше базы. Это арифметический контрпример отсутствия резервирования, а не выполненный многопоточный тест или найденный дефект реального сервиса.

В реальной системе нужно проверить изменение состояния между запросами, повтор с тем же идентификатором операции, тайм-аут после принятия провайдером и позднее подтверждение. Пока нет интеграции, сохраните эти пункты как риски и планы проверки. Не отмечайте их пройденными по результатам Boolean-функции.

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

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

Затем проверьте, что изменение сравнения не обошло независимые условия. На разрешённом времени запрос 6 001 при остатке 6 000 всё ещё отклоняется. Failed и cancelled не получают допуск; неверная валюта и недопустимый тип не принимаются. В локальной исправленной модели эти проверки прошли.

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

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

Как обсуждать результат с разработчиком и владельцем правила?

Если разработчик отвечает «так и задумано», вернитесь к основанию ожидания. Покажите согласованную включённую границу и точные времена. Возможно, он использует другую версию требования; тогда сначала нужно устранить расхождение документов. Если версия одна, сравнение > вместо >= даёт конкретное место для исправления без спора о личных предпочтениях тестировщика.

Если проблему не удаётся повторить, проверьте окружение, входное состояние и источник времени. У одного проверяющего запрос мог прийти на секунду позже, у другого уже изменился остаток. Сравните сохранённые аргументы, а не только итоговые фразы «не работает» и «работает». Для нашей модели аргументы фиксированы; для реального приложения эта управляемость ещё должна быть обеспечена.

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

Статус требования тоже важен в итоговом сообщении. Можно написать: «Граничный дефект подтверждён на модели; исправленная проверка проходит. Поведение исключения менеджера не определено и не проверено. Риск повторных запросов показан контрпримером, интеграционный тест не выполнен». Такая запись сообщает результат без искусственного общего вердикта о готовности продукта.

Если времени осталось мало, предложите следующий тест и объясните, какой риск он уменьшит. Например, после границы проверьте повторную отправку с тем же идентификатором операции в доступном тестовом API. Не обещайте найти все дефекты и не придумывайте готовый ответ провайдера. Ценность ответа — в связи между известными фактами, открытым вопросом и обоснованным действием.

Какие вопросы помогут отработать такую защиту?

На PracHub выбраны вопросы о тестах новой функции, различии UI/backend и отказах возврата. Они шире нашей модели; используйте их как практику переноса навыка, а не как свидетельство реального процесса найма.

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

Sources and Further Reading

• ISTQB CTFL Syllabus 4.0.1 — техники, риск и отчёт о дефекте.
• Python 3.12: datetime — моменты времени и временные зоны.
• Python 3.12: Boolean type — связь bool и int.

Источники проверены 11 октября 2026 года. Учебные правила и данные вымышлены. 30 локальных проверок не заменяют тестирование UI, API, провайдера и конкурентных запросов.