Вопросы на собеседовании: QA-инженер

Обеспечение качества, контроль качества и тестирование работают с качеством на разных уровнях.

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

Тест-кейс представляет собой документированную и воспроизводимую проверку одного сценария.

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

Позитивное и негативное тестирование проверяют поведение с корректными и некорректными данными соответственно.

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

Анализ граничных значений проверяет края допустимых диапазонов, где часто возникают дефекты.

• Для диапазона от 1 до 100 полезно проверить 0, 1, 2, 99, 100 и 101.
• Эти значения лучше выявляют ошибки на единицу, чем случайное среднее значение вроде 50.
• Границы также есть у длины строк, дат, размеров файлов и пагинации.

Разбиение на классы эквивалентности сокращает множество входных данных до небольшого набора проверок.

• Данные объединяют в группы, которые система должна обрабатывать одинаково, и проверяют по одному представителю каждой группы.
• Для допустимого возраста от 18 до 65 это значения ниже 18, внутри диапазона, выше 65 и нечисловой ввод.
• Вместе с анализом граничных значений техника даёт хорошее покрытие без проверки каждого значения.

Smoke, sanity и регрессионное тестирование различаются прежде всего охватом и целью.

• Smoke-тестирование быстро проверяет критические сценарии новой сборки и показывает, можно ли начинать глубокое тестирование.
• Sanity-тестирование точечно подтверждает работу конкретного исправления или изменения.
• Регрессионное тестирование широко проверяет, что последние изменения не сломали существующую функциональность.

Функциональное тестирование проверяет, что делает система, а нефункциональное оценивает, насколько хорошо она это делает.

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

Тестирование чёрного, белого и серого ящика различается уровнем знания внутреннего устройства системы.

• Чёрный ящик проверяет поведение через интерфейсы по требованиям и входным и выходным данным без знания кода.
• Белый ящик использует структуру кода для покрытия веток и путей, обычно в юнит-тестах разработчиков.
• Серый ящик использует частичное знание архитектуры, схемы базы данных или контрактов API для точных сценариев.

Уровни тестирования находят разные дефекты на разных масштабах системы.

• Юнит-тесты изолируют отдельные функции и быстро и дёшево находят логические ошибки.
• Интеграционные тесты проверяют совместную работу компонентов и выявляют несоответствия контрактов или форматов данных.
• Системные и сквозные тесты охватывают полные сценарии, но проверки нижних уровней быстрее и стабильнее, поэтому в пирамиде их больше.

Верификация проверяет, правильно ли создан продукт, а валидация проверяет, тот ли продукт был создан.

• Верификация сравнивает реализацию со спецификацией через ревью и тестирование по требованиям.
• Валидация подтверждает, что результат решает реальную проблему пользователя.
• Функция может точно соответствовать ошибочной спецификации, поэтому пройти верификацию, но не пройти валидацию.

Повторное тестирование подтверждает конкретное исправление, а регрессионное проверяет его влияние на остальную систему.

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

Исследовательское тестирование объединяет изучение продукта, проектирование и выполнение проверок в одной структурированной сессии.

• Тестировщик следует за результатами без фиксированного сценария и меняет пути и данные по мере появления новых подсказок.
• Подход полезен при слабой документации, нехватке времени или устаревших тест-кейсах.
• Это не случайные клики, потому что у хорошей сессии есть цель, ограничение по времени и заметки о покрытии.

Я превращаю каждое проверяемое требование в связанный с ним набор сценариев.

• Я выделяю проверяемые утверждения и покрываю позитивные сценарии, негативные и граничные данные и переходы состояний.
• Неоднозначности я уточняю у аналитика или разработчика, а не закладываю предположения в тест-кейсы.
• Каждый кейс я связываю с требованием, чтобы были видны пробелы покрытия и устаревшие кейсы без актуальной цели.

Подходящая глубина документации зависит от сложности, риска и контекста команды.

• Чек-листа достаточно для простых функций, опытных команд, smoke-проверок и задач, где особенно важна скорость.
• Полные тест-кейсы нужны для сложных сценариев, требований комплаенса, обучения новичков и долгосрочной воспроизводимости.
• Зрелые команды сочетают оба формата, а не описывают каждую проверку максимально подробно.

Тестирование может выявить дефекты, но не способно доказать их полное отсутствие.

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

Ошибка, дефект и отказ представляют собой этапы причинно-следственной цепочки.

• Ошибка является человеческим промахом, например неверным пониманием спецификации.
• Такой промах может создать дефект в коде или устройстве продукта.
• Отказ возникает, когда дефект проявляется и вызывает неверное поведение, хотя в неиспользуемом коде дефект может долго оставаться скрытым.

Баг проходит этапы регистрации, триажа, исправления, проверки и закрытия.

• После регистрации он проходит триаж и может быть назначен, отклонён, признан дубликатом или отложен.
• Разработчик исправляет баг и отмечает его решённым, после чего QA повторно проверяет его на обновлённой сборке.
• Успешная проверка ведёт к подтверждению и закрытию, неуспешная к переоткрытию, а отклонение и перенос сохраняют принятые решения.

Severity описывает техническое влияние бага, а priority определяет срочность исправления для бизнеса.

• Сбой в редко используемом старом отчёте может иметь высокую severity, но низкий priority.
• Опечатка в названии компании на лендинге может иметь низкую severity, но высокий priority.
• QA часто оценивает severity, а продакт-оунер или лид задаёт priority с учётом бизнес-контекста.

Хороший баг-репорт позволяет разработчику воспроизвести проблему без дополнительных вопросов.

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

Я регистрирую плавающий баг со всеми доступными доказательствами, а затем системно ищу условие его появления.

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