Теория тестирования для собеседования: от определений к решениям QA и разработчика
Знать определение регрессии полезно. Объяснить, что именно проверить после изменения конвертации лида и на каком уровне, гораздо полезнее. Разбираем теорию через условия задач, наблюдения и решения, которые можно защитить на собеседовании.
Это учебное руководство, а не список вопросов конкретного работодателя и не гарантия трудоустройства. Вопросы и бизнес-кейсы составлены редакцией; их условия не являются обещанием поведения текущих модулей тренажёра. Блоки для разработчика посвящены тестированию, а не заменяют подготовку по алгоритмам, языку или системному дизайну. Базовая терминология сверена с ISTQB CTFL 4.0.1; авторы и правообладатель программы указаны в документе ISTQB. Это независимый материал, не аккредитованный курс.
- Уточнить правило и риск
- Выбрать данные и действие
- Назвать ожидаемый результат
- Объяснить ограничения проверки
1. Тестирование, QA и доказательства качества
Тестирование даёт информацию о продукте и рисках, а не сертификат отсутствия ошибок. QA шире проверки готовой функции: команда может заранее улучшить правила ревью требований, работу с тестовыми данными и обратную связь. Отладка отличается от проверки: при отладке ищут причину наблюдаемой проблемы и исправляют её. Один человек может выполнять разные виды работы, но цели остаются разными.
Представь CRM: менеджер нажимает «Конвертировать лид», появляется клиент. Это наблюдение, но ещё не вывод о корректности. Требование говорит: один лид создаёт не более одного клиента, а повторное действие возвращает уже созданного. Проверочный эталон, или test oracle, здесь не зелёное уведомление, а правило количества клиентов и связь с исходным лидом. Проверка должна наблюдать именно их.
Разделяй ошибку человека, дефект артефакта и отказ при выполнении. Неверное предположение о повторном запросе может привести к отсутствию защиты от дублей в коде; два клиента после повторного запроса будут наблюдаемым отказом. Отчёт не обязан угадывать ошибку автора кода: достаточно воспроизводимого нарушения правила.
Вопрос на собеседовании
Конвертация лида один раз создала клиента. Можно ли сказать, что функция протестирована?
Разобрать ответ и уточняющий вопрос
Проверен один успешный путь при конкретных данных. Я записываю ID лида и клиента и проверяю связь между ними. Затем отдельно рассматриваю повтор запроса, отсутствие прав, неполные данные и прерывание операции. Полнота зависит от согласованного объёма и риска: фраза «один раз работает» не охватывает эти условия. В отчёте укажу проверенное и оставшиеся ограничения.
Интервьюер уточняет: Требование не описывает повтор. Сразу заводить баг на дубль?
Сначала зафиксировать наблюдение и риск и уточнить правило у владельца продукта. Дубль может быть критичной проблемой, но ожидаемый результат нельзя выдавать за согласованный без основания. Уже существующие ограничения данных или договорённости команды могут стать таким основанием.
Что здесь важно разработчику
До реализации обозначь инвариант: условие, которое должно оставаться истинным. В этом примере один lead_id связан максимум с одним клиентом. Тогда ревью, ограничение БД и тесты проверяют одну бизнес-идею, а не три несвязанных технических детали.
Ловушка: «Не нашли ошибок» и «ошибок нет» не равнозначны. Зелёный результат ограничен данными, средой и наблюдениями конкретного теста.
2. Тестируемые требования и критерии приёмки
Фраза «задача становится просроченной вовремя» скрывает минимум три решения: где хранится срок, по каким часам сравнивать время и считается ли равенство просрочкой. В учебном контракте срок due_at хранится в UTC, серверное время является источником истины, задача просрочена только при now > due_at и status != done. Теперь результат можно вычислить до запуска.
Для срока 12:00:00 UTC открытая задача в 11:59:59 не просрочена, в 12:00:00 ещё не просрочена, в 12:00:01 просрочена. Завершённая задача остаётся непросроченной при любом из этих времён. Перевод интерфейса в другой часовой пояс меняет представление, а не сам момент. Это несколько разных рисков, а не три одинаковых клика.
Критерии приёмки описывают необходимые свойства конкретной функции. Общая готовность команды к поставке может дополнительно требовать ревью, документацию и пройденные проверки. Не подменяй одно другим: запись «все тесты зелёные» не объясняет бизнес-правило просрочки.
Вопрос на собеседовании
Как протестировать требование «поиск клиентов быстрый»?
Разобрать ответ и уточняющий вопрос
Сначала уточню аудиторию, объём данных, запросы, нагрузку и точку измерения. Предложу согласовать, например, p95 серверного времени ответа не более 500 мс при 50 запросах в секунду на миллионе записей, с отдельно оговорённой долей ошибок. p95 означает, что 95% измерений не превышают выбранное значение. Это пример требования, а не универсальная норма. Измерю распределение и ошибки, а не один самый удачный запрос.
Интервьюер уточняет: Среднее время 200 мс, значит требование выполнено?
Нет: среднее может скрывать медленный хвост, а запросы с ошибкой могут завершаться быстро. Нужны заданный перцентиль, доля ошибок и совпадение условий нагрузки. Сохраняю профиль нагрузки, версию сервиса, длительность и правила прогрева, чтобы результат можно было повторить.
Что здесь важно разработчику
Управляемые часы и явно заданный часовой пояс позволяют проверить границу без ожидания реального времени. Не вычисляй ожидаемый результат тем же фрагментом кода, который тестируешь: одинаковая ошибка пройдёт с обеих сторон сравнения.
Ловушка: Самостоятельно назначенные 500 мс не становятся требованием только потому, что это удобно автоматизировать.
3. Уровни, виды, повторная проверка и регрессия
Уровень отвечает на вопрос о границе объекта проверки: отдельный компонент, взаимодействие компонентов, система целиком или её взаимодействие с другой системой. Вид описывает свойство, например функциональность или производительность. Приёмка рассматривает пригодность для согласованной потребности. Один тест может одновременно относиться к уровню и виду; это не конкурирующие списки.
После исправления двойной конвертации лида повторная проверка воспроизводит исходный дефект и подтверждает исправление. Регрессия ищет нежелательные последствия изменения: не сломались ли обычная конвертация, права менеджеров и работа с уже существующим клиентом. Smoke, или короткая проверка работоспособности сборки, лишь отвечает, имеет ли смысл продолжать более глубокое тестирование.
| Проверка | Что наблюдаем | Чего она не доказывает |
|---|---|---|
| Компонент | Функция отклоняет пустой lead_id | Реальная БД защищает от двух клиентов |
| Интеграция с БД | Два запроса не нарушают уникальность связи | В браузере понятное сообщение об отказе |
| Система через UI | Менеджер завершает конвертацию и видит клиента | Все варианты отказа внешнего сервиса |
| Приёмка | Согласованный рабочий сценарий полезен менеджеру | Отсутствие технических дефектов вообще |
Вопрос на собеседовании
Зачем интеграционные проверки, если все unit-тесты зелёные?
Разобрать ответ и уточняющий вопрос
Unit-тест мог заменить БД заглушкой, которая принимает любое значение. Реальная БД иначе обрабатывает ограничения, типы и транзакции. Я выберу интеграционную проверку для риска на этой границе, например конкурентной записи. Полный браузерный сценарий для каждой комбинации будет дороже и хуже локализует причину, поэтому он дополняет, а не заменяет нижние уровни.
Интервьюер уточняет: Нужно ли повторять один и тот же набор на каждом уровне?
Не механически. Множество комбинаций правила выгодно проверить рядом с логикой, контракт связи отдельно, а в UI оставить критичные пользовательские пути. Повторение оправдано новым риском, например потерей поля при сериализации, а не желанием увеличить счётчик тестов.
Что здесь важно разработчику
Пирамида тестов помогает обсуждать стоимость обратной связи, а не задаёт обязательные проценты. Выбирай самый узкий уровень, который способен обнаружить нужный дефект, сохраняя несколько проверок реальной сборки компонентов.
Ловушка: «Интеграционный» не означает просто «долгий», а «автоматизированный» не является отдельным уровнем.
4. Классы эквивалентности, границы и комбинации
Учебное правило: поле quantity обязательно, принимает целое число от 1 до 99 включительно; строки, null и дроби отклоняются без изменения корзины. Здесь есть допустимый класс 1–99, значения ниже и выше диапазона, а также отдельные классы неверного типа и отсутствия поля. Одно значение не представляет все причины отказа.
Для границ диапазона полезны 0, 1, 2 и 98, 99, 100. Значение 50 проверяет обычный случай. null, отсутствие поля, строка "2" и число 1.5 проверяют другие правила контракта. Для каждого отклонённого запроса проверяем не только ошибку, но и неизменность корзины. Если контракт разрешает преобразование строки в число, ожидание для "2" будет другим.
Pairwise, или попарное покрытие, выбирает комбинации так, чтобы каждая пара значений параметров встретилась хотя бы раз. Полный набор для двух браузеров, двух ролей и двух языков содержит восемь комбинаций. В таблице четыре строки покрывают все пары, но не все тройки. Если известен дефект только у viewer в Firefox на русском, соответствующую тройку нужно добавить отдельно.
| Браузер | Роль | Язык |
|---|---|---|
| Chrome | admin | en |
| Chrome | viewer | ru |
| Firefox | admin | ru |
| Firefox | viewer | en |
Вопрос на собеседовании
Достаточно проверить quantity = 1 и quantity = 99?
Разобрать ответ и уточняющий вопрос
Эти значения проверяют включение границ, но не отбрасывание соседних недопустимых значений. Добавлю 0 и 100, значения рядом с границами, типы и отсутствие поля по контракту. При ограниченном времени приоритет отдам рискам неправильного количества и скрытого изменения корзины после отказа. Объясню, какие проверки отложены, вместо заявления о полном покрытии.
Интервьюер уточняет: Почему не перебрать все числа от 1 до 99?
Если правило одинаково внутри диапазона, такой перебор даёт меньше новой информации, чем проверка разных причин отказа. Но предположение об одинаковом поведении нужно пересмотреть, если существуют пороги скидки или упаковки: они создают новые классы и границы.
Что здесь важно разработчику
Параметризованный тест должен показывать вход, ожидаемый результат и смысл случая. Сто одинаковых строк данных не заменяют проверку того, что запрещённый запрос не вызвал запись.
Ловушка: Попарное покрытие не гарантирует обнаружение дефектов, зависящих от трёх и более параметров.
5. Переходы состояний: блокировка входа без двусмысленности
Зададим весь контракт. Для существующего аккаунта пять последовательных попыток с неверным паролем включают блокировку на 15 минут от пятой попытки по серверным часам. Успешный вход до блокировки обнуляет счётчик. Во время блокировки любой пароль отклоняется и таймер не продлевается. При now >= locked_until блокировка снимается, счётчик сбрасывается, новый запрос обрабатывается обычно. Счётчик общий для всех устройств аккаунта.
Состояние здесь включает не только «заблокирован/нет», но и счётчик и время. Изолируй аккаунт перед каждым сценарием. Иначе предыдущая неверная попытка изменит смысл следующей проверки. Управляемые часы в тестовой среде позволяют воспроизвести 14:59 и 15:00 без реального ожидания; в ручной проверке фиксируй серверные метки времени и допустимую точность.
| Исходное состояние | Действие | Результат |
|---|---|---|
| 4 неверных попытки | Верный пароль | Вход разрешён, счётчик 0 |
| 4 неверных попытки | Неверный пароль | Вход запрещён, таймер 15 минут начат |
| Блокировка, прошло 14:59 | Верный пароль | Вход запрещён, срок не меняется |
| Блокировка, прошло ровно 15:00 | Верный пароль | Вход разрешён, счётчик 0 |
| Блокировка истекла | Неверный пароль | Вход запрещён, новый счётчик 1 |
Вопрос на собеседовании
Какие проверки отличают тестирование блокировки от проверки одного сообщения об ошибке?
Разобрать ответ и уточняющий вопрос
Проверю накопление счётчика, переход на пятой неверной попытке, обнуление после успешного входа до блокировки, отказ с верным паролем во время блокировки и границу снятия. Затем сменю устройство, чтобы проверить общий счётчик. В каждом случае фиксирую исходное состояние, действие, результат и изменение счётчика или срока. Одного текста «неверный пароль» для этих выводов недостаточно.
Интервьюер уточняет: Что изменится при двух одновременных неверных попытках после трёх предыдущих?
По заданному правилу итог должен учитывать обе попытки и включить блокировку. Последовательный тест это не проверяет. Нужны два синхронизированных запроса и наблюдение итогового состояния: потерянное обновление счётчика может оставить значение 4.
Что здесь важно разработчику
Обновление счётчика и начало блокировки должны быть согласованы при конкуренции. Отдельно обсуждается продуктовый риск: блокировка по аккаунту может позволить постороннему мешать владельцу войти. Это вопрос защитного дизайна, а не повод молча менять учебный контракт.
Ловушка: «Пять ошибок» не объясняет ни тип ошибок, ни окно накопления, ни момент запуска таймера. Без этих правил тест неоднозначен.
6. HTTP и API: почему статуса 200 мало
API — договор между потребителем и сервисом. Для проверки нужны метод, путь, права, заголовки, тело запроса, ответ и побочные эффекты. Браузерный интерфейс является одним из потребителей: успешная отрисовка не доказывает, что прямой запрос защищён так же.
Учебный контракт POST /enrollments принимает course_id существующего опубликованного курса и создаёт одну запись обучения для текущего пользователя. Проверки: корректная структура ответа и ID, связь с пользователем и курсом, повторный запрос, неизвестный курс, неопубликованный курс, отсутствующее поле, чужой user_id в теле. Для отказов проверяем, что запись не появилась.
Идемпотентность означает одинаковый предполагаемый эффект повторения идентичного запроса, а не обязательное совпадение всех ответов. У POST её нет автоматически. Прикладной ключ повторного запроса требует отдельного контракта: область действия, срок хранения и поведение при другом теле с тем же ключом. Тайм-аут означает отсутствие ответа у клиента, но не доказывает отсутствие записи на сервере.
Вопрос на собеседовании
POST вернул 200. Что ещё проверить до вывода об успехе?
Разобрать ответ и уточняющий вопрос
Сопоставлю статус с контрактом, проверю обязательные поля, типы, значения и отсутствие лишних чувствительных данных. Затем проверю сохранённое состояние независимым чтением: запись относится к нужному пользователю и курсу, создана ровно один раз. Отдельно проверю отказ и отсутствие побочных эффектов. Само число 200 говорит только об HTTP-ответе, а не о выполнении всех бизнес-условий.
Интервьюер уточняет: После тайм-аута можно просто повторить POST?
Сначала выясню договорённость о повторе. При поддержке идемпотентного ключа повторю с тем же ключом и телом; без неё проверю статус исходной операции по предусмотренному идентификатору. Новый случайный ключ может создать вторую операцию. Нужно проверить и гонку двух запросов, а не только последовательный повтор.
Что здесь важно разработчику
Разделяй проверку синтаксиса запроса, бизнес-валидацию и сохранение. Тест контракта ловит несовместимость формата между потребителем и поставщиком, но не заменяет проверку реальных прав и данных.
Ловушка: Одинаковый код ответа не означает одинаковое состояние. И наоборот, повтор может вернуть другой статус, сохранив один и тот же эффект.
7. Аутентификация, авторизация и границы доступа
Аутентификация отвечает, кто обращается; авторизация — какие действия разрешены этому субъекту. Скрытая кнопка не является серверной защитой. Для проверки подготовь два собственных тестовых аккаунта менеджеров A и B в разрешённой среде, клиента A с ID 101 и клиента B с ID 202. Контракт: менеджер читает и меняет только собственных клиентов.
С токеном A сначала получи 101 как положительный контроль. Затем запроси 202, попробуй изменение и экспорт, если они входят в согласованную область. Недостаточно увидеть отказ на GET: путь изменения может иметь другую проверку. Для запрещённого изменения проверь неизменность записи через разрешённый аккаунт B. Не используй чужие реальные данные и не выполняй проверки без разрешения.
401 обычно связан с отсутствием подходящих учётных данных, 403 с отказом выполнить запрос; сервис может скрывать существование ресурса через 404. Поэтому ожидаемый статус нужно брать из контракта. Главные свойства: данные не раскрыты и запрещённый эффект не произошёл.
Вопрос на собеседовании
Почему валидного токена недостаточно для доступа к GET /customers/202?
Разобрать ответ и уточняющий вопрос
Токен подтверждает субъект, но не право на конкретный объект. Я проверю роль, принадлежность клиента менеджеру и границу организации, если система многопользовательская. Сравню разрешённый и запрещённый запросы и проверю тело ответа. UUID вместо числового ID не заменяет эту проверку: знание идентификатора не должно давать право доступа.
Интервьюер уточняет: Сервер вернул 403, но в теле есть имя чужого клиента. Тест прошёл?
Нет. Код отказа не отменяет утечку в теле. Зафиксирую раскрытые поля, роль, ресурс и обезличенные доказательства. Проверю также экспорт и списки в рамках разрешённого объёма, потому что ошибка может быть общей для разных маршрутов.
Что здесь важно разработчику
Проверка объекта должна выполняться на сервере для каждого соответствующего действия. Для регрессии полезна матрица субъект × объект × действие: владелец, чужой менеджер, администратор; чтение, изменение, экспорт.
Ловушка: Успешная проверка входа ничего не говорит о горизонтальном доступе между двумя менеджерами одной роли.
8. SQL на собеседовании: схема, запрос и проверка результата
Задание именно на SQL, а не на пересказ: в PostgreSQL есть customers(id PRIMARY KEY, email TEXT NULL) и orders(id PRIMARY KEY, customer_id NOT NULL REFERENCES customers(id), status TEXT NOT NULL). Нужно найти клиентов без каких-либо заказов и отдельно группы повторяющихся непустых email. В этом задании сравнение email регистрозависимое, пробелы не удаляются, NULL и пустая строка исключаются из поиска дублей. Отменённый заказ тоже считается заказом.
Тестовые данные: customers содержит (1, a@example.test), (2, b@example.test), (3, a@example.test), (4, NULL), (5, пустая строка). orders содержит (10, 1, paid), (11, 1, cancelled), (12, 2, cancelled). Ожидаемые ID без заказов: 3, 4, 5. Ожидаемый дубль: a@example.test с количеством 2. Два заказа клиента 1 специально проверяют, не умножит ли соединение подсчёт клиентов.
SELECT c.id
FROM customers AS c
WHERE NOT EXISTS (
SELECT 1 FROM orders AS o WHERE o.customer_id = c.id
)
ORDER BY c.id;
SELECT email, COUNT(*) AS customer_count
FROM customers
WHERE email IS NOT NULL AND email <> ''
GROUP BY email
HAVING COUNT(*) > 1
ORDER BY email;Вопрос на собеседовании
Как объяснить, что эти запросы решают именно поставленную задачу?
Разобрать ответ и уточняющий вопрос
NOT EXISTS оставляет клиента, для которого нет ни одного связанного заказа; status здесь не фильтруется намеренно. Второй запрос сначала исключает отсутствующие и пустые адреса, затем группирует клиентов по email и оставляет группы больше одного. Проверяю не только три строки первого результата, а точные ID 3, 4, 5. Для второго проверяю адрес и количество 2. Порядок задан явно, поэтому сравнение воспроизводимо.
Интервьюер уточняет: Теперь нужны клиенты без оплаченных заказов. Что меняется?
Внутрь NOT EXISTS добавляется AND o.status = 'paid'. Тогда результат 2, 3, 4, 5: у клиента 2 заказ есть, но он отменён. Это другая бизнес-задача. В варианте LEFT JOIN нельзя бездумно переносить условие в WHERE: это может исключить строки с NULL на стороне заказа.
Что здесь важно разработчику
PRIMARY KEY идентифицирует строку, FOREIGN KEY поддерживает связь, NOT NULL запрещает отсутствие значения. Эти ограничения не доказывают правильность бизнес-запроса. Уточняй нормализацию email до добавления уникальности; lower(trim(email)) меняет правило задачи, а не просто ускоряет запрос.
Ловушка: «Вернулось три строки» не доказывает правильность: это могут быть три неверных клиента. Нужны ожидаемые значения и контрольные примеры.
9. Транзакции, конкуренция и сбои интеграции
Транзакция объединяет изменения БД в единицу завершения: либо согласованный набор фиксируется, либо его незавершённые изменения откатываются. Это не делает внешний сервис частью транзакции автоматически. Если CRM сохранила клиента и отправляет письмо, откат локальной записи не может «отправить письмо назад». Сначала нужно определить, что считается успехом и как восстанавливается частичный результат.
ACID объединяет четыре свойства: атомарность защищает от частичного сохранения, согласованность означает соблюдение заданных ограничений, изоляция определяет допустимое влияние параллельных транзакций, долговечность касается сохранности подтверждённых изменений. Важно назвать границы: база не знает всех бизнес-правил, а уровень изоляции не всегда равен последовательному выполнению. Для проверки перевода отдельно задают допустимый баланс, связанные проводки и поведение при конкуренции.
Учебное правило конвертации: один клиент на lead_id; отказ почтового сервиса не отменяет создание клиента, а уведомление получает статус pending и может быть повторено. В тесте сервис почты возвращает тайм-аут после приёма сообщения. Проверяем одного клиента, сохранённую задачу уведомления, ограничение повторов и отсутствие второго клиента после повторной конвертации. «Ровно одно письмо» требует отдельной договорённости с поставщиком и защиты от повторной обработки.
Для гонки нужны две одновременно выполняемые операции. Если оба запроса сначала читают «клиента нет», а затем оба вставляют запись, последовательный тест может всегда проходить. Уникальное ограничение помогает защитить инвариант, но приложение должно корректно обработать конфликт и вернуть согласованный результат. Уровень изоляции и стратегия повторов зависят от БД и операции.
Вопрос на собеседовании
Перевод списал средства, но зачисление завершилось ошибкой. Что проверять?
Разобрать ответ и уточняющий вопрос
Уточню архитектуру и контракт. Для двух записей в одной локальной транзакции проверю откат обеих при отказе между шагами. Для разных сервисов проверю состояние незавершённой операции и предусмотренное восстановление или компенсацию. Сохраню ID операции и сопоставлю проводки, а не только итоговый баланс. Повтор не должен создавать второе списание; допустимое время согласования также должно быть задано.
Интервьюер уточняет: Тайм-аут значит, что внешняя операция не произошла?
Нет. Ответ мог потеряться после выполнения. Нужны предусмотренные контрактом проверка статуса, идентификатор операции и безопасный повтор. Полезно отдельно смоделировать отказ до приёма запроса и потерю ответа после успешного выполнения: последствия разные.
Что здесь важно разработчику
Обсуди границу транзакции, обработку конфликта и доставку событий. Например, outbox сохраняет намерение отправить событие вместе с бизнес-изменением; повторная доставка всё равно требует защиты потребителя от повторного эффекта. Не обещай exactly once только из-за наличия очереди.
Ловушка: ACID одной базы не гарантирует атомарность всей цепочки с банком, почтой и очередью.
10. Багрепорт, severity, priority и решение о релизе
Хороший отчёт позволяет воспроизвести расхождение: версия и среда, роль, исходные данные, точные действия, ожидаемый результат с основанием, фактический результат и доказательства. Фраза «checkout иногда падает» не сообщает ни шаг, ни симптом. Checkout — оформление заказа; нужно указать, например, что после подтверждения корзины API возвращает 500, заказ сохранён, а страница предлагает повторить действие.
Severity описывает влияние дефекта, priority — срочность работы над ним в конкретном контексте. Разделение важно: визуальная ошибка на главной странице перед запуском кампании может быть срочной, а редкое повреждение данных серьёзным даже без большой аудитории. Окончательные шкалы и полномочия определяет команда, а не универсальная таблица из интернета.
При ограниченном времени на регрессию выдели изменённый путь, связанные данные, права и необратимые эффекты. Для изменения конвертации CRM первыми могут идти дубли, потеря связи с лидом и чужой доступ. В итоговом сообщении перечисли проведённые проверки, известные дефекты, ограничения среды и непроверенные риски. Решение о выпуске должно опираться на это, а не только на процент зелёных тестов.
Вопрос на собеседовании
Дефект воспроизводится один раз из десяти. Как сделать отчёт полезным?
Разобрать ответ и уточняющий вопрос
Опишу десять попыток и различия условий, время неудачного запроса, версию, request ID, ответ и состояние заказа после ошибки. Приложу обезличенные логи или трассу, если есть доступ. Отделю факт от гипотезы: параллельный запрос может быть причиной, но пока это предположение. Укажу риск повторного заказа и точный способ попытаться воспроизвести проблему.
Интервьюер уточняет: Разработчик отвечает «у меня работает». Что дальше?
Сравним версии, конфигурацию, роли, данные и последовательность действий. По request ID найдём конкретную попытку и проверим, что видели разные компоненты. Не заменяю доказательства спором; если условия пока не восстановлены, явно сохраняю статус расследования и собранные наблюдения.
Что здесь важно разработчику
Корреляционный идентификатор связывает действия одной операции в журналах разных компонентов. Логи должны помогать расследованию без записи токенов, паролей и ненужных персональных данных.
Ловушка: Частота воспроизведения не равна влиянию. Редкое двойное списание не становится косметическим дефектом.
11. Теория для разработчика: моки, покрытие, TDD и CI
Автотесту нужны управляемая подготовка, действие и проверка наблюдаемого результата. Для CRM это может быть новый лид и аккаунт владельца, конвертация и утверждение об одном клиенте с нужной связью. Данные должны быть изолированы: тест не должен зависеть от запуска соседнего теста. Очистка или отдельное пространство данных важнее случайного имени, которое лишь снижает вероятность столкновения.
Test double — замена реального участника теста. Stub возвращает подготовленный ответ, mock обычно ещё проверяет ожидаемое взаимодействие, fake даёт упрощённую работающую реализацию. Названия в библиотеках различаются. Главное сказать, что заменено и какие дефекты теперь невидимы. Заглушка почты удобна для проверки поведения при тайм-ауте, но не доказывает совместимость с настоящим провайдером.
TDD строит короткий цикл: тест фиксирует нужное поведение и падает по ожидаемой причине, минимальная реализация делает его зелёным, затем код улучшается с сохранением проверок. Это не гарантия хороших требований. В CI, то есть непрерывной интеграции, тесты запускаются автоматически для изменений; воспроизводимая среда и понятные артефакты нужны, чтобы результату доверяли.
Вопрос на собеседовании
Покрытие кода 100%. Почему всё ещё могут быть дефекты?
Разобрать ответ и уточняющий вопрос
Метрика показывает исполненные элементы кода, а не полноту требований и правильность утверждений. Тест может вызвать ветку и ничего полезного не проверить. Неучтённое правило вообще может отсутствовать в коде. Я посмотрю на проверки значений, отрицательные случаи, взаимодействия и конкуренцию. Для оценки силы теста полезно мысленно изменить правило или применить mutation testing: тест должен заметить значимое изменение поведения.
Интервьюер уточняет: Тест иногда падает в CI и проходит после повтора. Добавить sleep?
Сначала проверю общие данные, порядок запуска, ожидания асинхронного состояния, время и зависимость от сети. Фиксированная пауза может скрыть гонку и замедлить весь набор. В UI лучше ожидать конкретное наблюдаемое состояние с ограниченным сроком. Повторный успешный запуск является диагностикой, а не доказательством исправления нестабильности.
Что здесь важно разработчику
На ревью теста спроси: упадёт ли он при реальном дефекте, понятна ли причина падения, работает ли отдельно и в параллели? Не проверяй только внутренние вызовы, если важен результат для пользователя. Сохраняй трассы и отчёты падений в CI, не секреты.
Ловушка: Мок-собеседование означает тренировочное интервью. Mock в автотестах означает тестовую замену: это разные контексты одного английского слова.
12. Производительность, восстановление и уверенный ответ Middle
Нагрузочный тест проверяет поведение при заданном профиле работы; стрессовый исследует пределы и отказ; длительный прогон помогает увидеть накопление ресурсов. Пользователи и запросы в секунду не взаимозаменяемы: один пользователь может ждать, а другой отправлять много запросов. Профиль должен описывать операции, интенсивность, данные, длительность и среду.
Для учебной LMS зададим: 100 активных учеников читают уроки, каждый в среднем делает запрос раз в 10 секунд; отдельно 20 учеников одновременно отправляют ответы. Нельзя заменить это сотней одинаковых GET и объявить платформу готовой. Кроме задержек проверяем ошибки, корректность сохранения попыток, очередь обработки и восстановление после снижения нагрузки.
RPO — допустимая потеря данных, выраженная временным интервалом; RTO — целевое время восстановления. При сбое в 10:00 копия на 09:50 соответствует потере последних 10 минут, восстановление к 10:40 занимает 40 минут. Сравнивать нужно с согласованными целями. Сам факт существования файла резервной копии не доказывает возможность восстановить согласованные данные.
Вопрос на собеседовании
Как ответить на «когда можно заканчивать тестирование», не сказав просто «когда нет багов»?
Разобрать ответ и уточняющий вопрос
Назову согласованные критерии выхода: проверенные критичные сценарии, допустимое состояние дефектов, покрытые риски и известные ограничения. Затем покажу фактические результаты и оставшиеся риски. При изменении объёма или среды пересмотрю вывод. Отсутствие найденных ошибок не доказывает их отсутствие; выпуск является решением с известной неопределённостью.
Интервьюер уточняет: До релиза 30 минут. Полная регрессия занимает день. Что делать?
Уточнить изменения и цену отказа, выбрать короткий набор по критичным рискам, сообщить, что не проверено. Для необратимой миграции или денежной операции риск может требовать переноса выпуска. План отката, наблюдение после выпуска и ограниченный rollout помогают, но не превращают непроверенное поведение в проверенное.
Что здесь важно разработчику
Для изменений схемы проверь совместимость старой и новой версии приложения, порядок миграции и возможность восстановления. Rollback кода не всегда отменяет преобразование данных. Продемонстрировать восстановление на изолированной копии полезнее, чем назвать его «предусмотренным».
Ловушка: Уверенный Middle не обязательно отвечает быстрее. Сильный ответ делает явными допущения, приоритеты и ограничения доказательств.
Как заниматься без заучивания готовых реплик
- Первый проход: объясни один раздел своими словами и выпиши непонятные термины. Не переходи к двадцати определениям подряд.
- Практика: возьми условия примера и составь таблицу «подготовка → действие → ожидаемое → доказательство». Для SQL выполни запросы в собственной учебной базе с указанными данными.
- Самопроверка: до открытия разбора ответь на основной и уточняющий вопросы. Затем сравни не формулировки, а наличие правила, примера, проверки результата и ограничений.
- Перенос: замени магазин на CRM или LMS. Объясни, что в методе сохранилось и какие бизнес-правила изменились. Это проверяет понимание лучше повторения текста.
- Возврат: на следующем занятии разбери тот же риск с другими данными без подсказки. Если можешь объяснить, почему альтернативный ответ неверен, понимание стало устойчивее.
Оцени ответ по четырём признакам: понятное правило, конкретные данные, наблюдаемый результат, честные ограничения. Это ориентир для самостоятельной проверки, не автоматическая оценка квалификации. Разборы в статье открываются без регистрации; отдельного сохранения ответов на этой странице нет.
Частые вопросы о подготовке
Что учить Junior QA в первую очередь?
Начни с требований, ожидаемого результата, тест-дизайна, уровней проверки и отчёта о дефекте. Затем свяжи их с HTTP, правами доступа и простыми SQL-запросами. На каждый термин нужен свой разобранный пример. Приоритет корректируй по описанию вакансии, а не по длине общего списка.
Чем ответ Middle отличается от ответа Junior?
Названия должностей у компаний различаются. Полезный ориентир: Junior объясняет проверку с понятными условиями, Middle дополнительно обсуждает зависимости, риски, стоимость проверки, конкуренцию и ограничения результата. Это не официальная шкала и не требование знать все технологии.
Нужна ли теория тестирования разработчику?
Да: она помогает выбрать уровень теста, определить ожидаемый результат независимо от реализации и понимать, чего не доказывает заглушка. Для собеседования разработчика полезно уметь объяснить границы транзакций, изоляцию данных тестов, нестабильные проверки и обратную связь CI. Эта статья не заменяет подготовку по конкретному языку.
Нужно ли запоминать ответы дословно и получать сертификат?
Дословное повторение быстро ломается на уточняющем вопросе. Лучше воспроизвести логику на других данных. Сертификат может быть требованием отдельной вакансии, но сам по себе не заменяет практику; необходимости покупать его для использования этого руководства нет.
Теория становится рабочим инструментом, когда помогает выбрать следующую проверку и объяснить её результат. Подготовь один собственный разбор с данными и доказательствами, затем переходи к следующему риску.