10 вопросов по теме «QA: Кейсы и задачи» на собеседовании

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

Подробно:

1. Уточняющие вопросы — простой или механический? целевая аудитория (дети / чертёжники)? есть ли спецификация на твёрдость грифеля, длину, покрытие?
2. Функциональные — пишет ли на бумаге, стирается ли ластиком, точится ли, не ломается ли грифель при нормальном нажиме.
3. Нефункциональные — прочность на излом, эргономика (грани, толщина), безопасность (нетоксичность краски), долговечность, внешний вид.
4. Граничные — очень короткий огрызок, карандаш без грифеля, максимальное давление, экстремальные температура и влажность.
5. Негативные — писать тупым концом, рисовать на стекле/ткани, точить с обратной стороны.

Тестируем карандаш
├── Функциональные ── пишет · стирается · точится
├── Нефункциональные ─ прочность · эргономика · безопасность
├── Граничные ─────── огрызок · без грифеля · t°/влажность
└── Негативные ────── тупой конец · стекло · обратная заточка

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

Короткий ответ: Та же рубрика, что и с карандашом, но с упором на системное мышление и safety: функциональность, нагрузка, безопасность, конкурентные вызовы и аварийные режимы. Здесь цена ошибки — жизни, поэтому safety-кейсы приоритетнее косметики.

Подробно:

1. Функциональные — вызов и поездка на нужный этаж, открытие/закрытие дверей, индикация этажа, кнопки в кабине и на этажах.
2. Нагрузка и конкурентность — одновременные вызовы с разных этажей, алгоритм диспетчеризации, пиковый час (утро/вечер), полная кабина проезжает мимо новых вызовов.
3. Безопасность — перегруз (датчик веса блокирует движение), реверс дверей при препятствии, аварийный тормоз, кнопка «стоп» и связь с диспетчером.
4. Аварийные режимы — отключение питания и переход на резерв, пожарный режим (спуск на первый, блокировка), застревание между этажами.
5. Граничные этажи — подвал, 1-й и 100-й, поведение при попытке уехать «за пределы».

⚠️ Частая ошибка: тестировать лифт как «кнопку, которая едет вверх-вниз», забыв про safety и конкурентные вызовы. Именно аварийные и граничные сценарии отличают QA от пользователя.

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

Подробно:

1. Позитивные — валидная регистрация, письмо-подтверждение, создание аккаунта в БД.
2. Границы полей — минимальная и максимальная длина имени/пароля, ровно на границе и на 1 больше/меньше, пустое поле, пробелы по краям.
3. Обязательность — отправка с пустыми required-полями, отсутствие галки «согласен с условиями».
4. Уникальность — регистрация на уже занятый email/логин, тот же email в другом регистре, гонка двух одновременных регистраций.
5. Кросс-полевая логика — «пароль» и «подтверждение пароля» не совпадают, email в двух полях расходится.
6. Правила пароля — сложность, чёрный список частых паролей, показ/скрытие.
7. Безопасность — SQLi/XSS в полях (' OR 1=1--, <script>), unicode, эмодзи.
8. Локализация — кириллица/иероглифы в имени, RTL, форматы дат и телефонов.

⚠️ Частая ошибка: ограничиться «ввёл всё правильно → зарегистрировался». Интервьюер ждёт дубликаты email и кросс-полевые проверки — их забывают чаще всего.

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

Подробно:

1. Базовые — верная пара логин/пароль, неверный пароль, несуществующий логин, пустые поля.
2. Состояние аккаунта — заблокированный, отключённый, неподтверждённый email, удалённый пользователь.
3. Сессии — истечение сессии, «запомнить меня», параллельные сессии на разных устройствах, логаут на одном не рвёт другие.
4. Восстановление и SSO — сброс пароля, вход через Google/Apple, привязка соцсети к существующему аккаунту.
5. Безопасность — rate limiting и брутфорс (блокировка после N попыток), одинаковое сообщение об ошибке для неверного логина и пароля (не палим, что есть аккаунт), показ/скрытие пароля, автозаполнение.
6. Граничные — регистр логина, пробелы по краям, очень длинный ввод, SQLi/XSS.

Логин
├── Базовые ──── верно · неверный пароль · нет логина
├── Аккаунт ──── заблокирован · отключён · email не подтверждён
├── Сессии ───── истечение · параллельные · remember me
├── Вход ─────── сброс пароля · SSO/соцсети
└── Безопасность ─ rate limit · единый текст ошибки · SQLi

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

Короткий ответ: Три условия дают комбинаторику, поэтому строю таблицу решений (или pairwise), добавляю граничные значения по балансу и отдельно проверяю edge-кейсы: истёкшую подписку, неподходящую категорию, нулевой и отрицательный баланс. Happy-path-список без комбинаторики — это провал задачи.

Подробно:

1. Выделяю условия — категория (кэшбэчная / нет), баланс (0 · граница минимума для начисления · выше), премиум (активен / истёк / нет).
2. Таблица решений — перебираю комбинации и фиксирую ожидаемый процент кэшбэка; помечаю невозможные и приоритетные строки.
3. Граничные значения по балансу — минимальная сумма покупки для начисления −1 / ровно / +1, максимум кэшбэка за период (кап).
4. Edge-кейсы — подписка истекла в момент покупки, покупка на границе смены категории, отрицательный баланс (овердрафт: начислять ли вообще?), возврат покупки (сторнирование кэшбэка), валютная конвертация, округление копеек.

⚠️ Частая ошибка: выдать линейный список «купил в категории → получил кэшбэк» без таблицы. Интервьюер Т-Банка проверяет именно комбинаторику условий и обработку истёкшей подписки.

Короткий ответ: Начинаю с риск-приоритизации: платежи и безопасность важнее полировки UI. Дальше подбираю типы тестов под каждый риск (интеграция с железом, нагрузка, безопасность платежей) и определяю метрики готовности к запуску. Структура и приоритеты ценятся выше, чем длина списка проверок.

Подробно:

1. Приоритизация по рискам — деньги (списания, двойные платежи) → разблокировка и GPS (пользователь платит, но не едет) → корректность тарифа → косметика UI.
2. Типы тестов — интеграция с IoT-железом (замок, GPS, заряд), E2E-сценарий «нашёл → разблокировал → поехал → завершил → оплатил», нагрузка на пиковый час, безопасность платежей (PCI, идемпотентность).
3. Полевое тестирование — реальные условия: нет сети, слабый GPS, разряженный самокат, зона запрета парковки.
4. Метрики готовности — crash rate, unlock success rate, доля неуспешных платежей, p95 времени разблокировки.

⚠️ Частая ошибка: вывалить плоский список «протестируем кнопки, карту, оплату» без приоритетов. Открытый кейс Яндекса проверяет умение начать с рисков, а не с UI.

Короткий ответ: Не пытаюсь «потыкать руками» в проде, а запускаю структурный триаж: воспроизвожу под нагрузкой на перф-стенде, поднимаю логи/метрики/трейсы именно на этом RPS, строю гипотезы (гонка, исчерпание ресурсов, таймауты) и координируюсь с dev и SRE. Скрининговый вопрос — проверяют процесс, а не догадку.

Подробно:

1. Собрать факты — что за баг, с какого RPS порог, какие сервисы задеты, есть ли корреляция с деплоем или временем суток.
2. Воспроизвести под нагрузкой — нагрузочный тест на стейдже/перф-стенде до 5000+ RPS; если не воспроизводится — искать отличие сред (данные, конфиг, масштаб пула).
3. Наблюдаемость — включить/поднять логи, метрики (CPU, память, коннекты, GC), распределённые трейсы на пиковом RPS; смотреть p95/p99, а не среднее.
4. Гипотезы — гонка данных, исчерпание пула соединений/потоков, таймауты и ретраи по цепочке, деградация кэша, лимиты БД.
5. Координация — не чинить в одиночку: подключить dev к коду и SRE к инфраструктуре, при риске — фичефлаг или откат.

1. Факты ──────► 2. Воспроизвести (перф-стенд, 5000+ RPS)
                        │
            не вышло ◄──┴──► вышло
         сравнить среды       3. Логи/метрики/трейсы @пик
                                     │
                              4. Гипотезы: гонка · пул · таймауты
                                     │
                              5. Dev + SRE, фиксация, фичефлаг/откат

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

Короткий ответ: За 2 взвешивания. Делю не пополам, а на группы 3-3-2, потому что весы дают три исхода (левая тяжелее / правая тяжелее / равно), а значит на каждом шаге отсеиваю сразу треть.

Подробно:

1. Первое взвешивание — 3 против 3, две монеты откладываю.
   • Если чаша перевесила — фальшивка среди 3 на поднявшейся (лёгкой) стороне.
   • Если равно — фальшивка среди 2 отложенных.
2. Второе взвешивание — из подозрительной группы кладу по 1 монете на чаши.
   • Из тройки: 1 против 1; поднялась — она фальшивая, равно — это третья, отложенная.
   • Из двойки: 1 против 1; лёгкая и есть фальшивка.
3. Почему не 3 — весы троичны: за k взвешиваний различаешь до 3^k вариантов. 3² = 9 ≥ 8, поэтому двух хватает; деление пополам (двоичное) недоиспользует исход «равно».

         8 монет
     [3] vs [3]   +2 в стороне
      /    |    \
 перевес  равно  перевес
   3        2        3
 [1]vs[1] [1]vs[1] [1]vs[1]
  → 2 взвешивания

⚠️ Частая ошибка: ответить «3», деля пополам (4-4-2-2-...). Это игнорирует, что весы дают ТРИ исхода, а не два — и теряет одно взвешивание.

Короткий ответ: Есть много способов, и оценивают именно широту подходов и то, как вы рассуждаете вслух, а не «единственно верный» метод. Называю 3–4 варианта и прямо проговариваю, что задача — на широту мышления.

Подробно:

1. По давлению (учебный) — замерить давление внизу и на крыше; разница даёт высоту через барометрическую формулу. Точный, но чувствителен к погоде.
2. Свободное падение — сбросить барометр с крыши и засечь время падения t; высота h = g·t²/2. Быстро и наглядно.
3. Тени и пропорция — измерить длину тени барометра и тени здания, высота — из подобия треугольников.
4. Маятник / длина верёвки — спустить барометр на верёвке до земли и измерить верёвку; или использовать как маятник и посчитать по периоду.
5. Социальный «лайфхак» — подарить барометр коменданту здания в обмен на ответ (классическая байка, которую приписывают Нильсу Бору).

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

Короткий ответ: Сортирую интервалы по началу, затем прохожу один раз и сливаю каждый следующий с последним в результате, если он пересекается. Для примера ответ — [1,6], [8,10]. Сложность — O(n log n) из-за сортировки.

Подробно:

1. Сортировка — по левой границе; после неё все, что может слиться, стоит рядом.
2. Один проход — держу «текущий» интервал; если начало следующего ≤ конца текущего, они пересекаются → расширяю конец до max(текущий.конец, следующий.конец).
3. Иначе — пересечения нет: закрываю текущий, кладу в результат, следующий становится текущим.
4. Сложность — сортировка O(n log n) доминирует, проход O(n), память O(n) на результат.

def merge(intervals):
    intervals.sort(key=lambda x: x[0])   # по началу
    result = [intervals[0]]
    for start, end in intervals[1:]:
        if start <= result[-1][1]:       # пересекается
            result[-1][1] = max(result[-1][1], end)
        else:
            result.append([start, end])
    return result

# merge([[1,3],[2,6],[8,10]]) -> [[1,6],[8,10]]

⚠️ Частая ошибка: сравнивать все пары интервалов без сортировки — это наивное O(n²) и легко пропустить транзитивные слияния (a∩b, b∩c). Сортировка по началу убирает обе проблемы.