Тестирование (QA): вопросы на собеседовании

Три понятия вложены друг в друга:

• Тестирование — проверка соответствия продукта требованиям через выполнение сценариев. Узкая деятельность.
• QC (Quality Control) — контроль качества готового продукта: тестирование плюс анализ результатов, метрики дефектов. Ориентирован на продукт.
• QA (Quality Assurance) — обеспечение качества на всех этапах: процессы, ревью требований, стандарты, предотвращение дефектов. Ориентирован на процесс.

Верификация — «правильно ли мы делаем продукт?»: соответствует ли он спецификации и требованиям.
Валидация — «тот ли продукт мы делаем?»: решает ли он реальную задачу пользователя.

Пример: форма регистрации полностью соответствует ТЗ (верификация пройдена), но пользователи бросают её на третьем шаге из-за лишних полей (валидация провалена).

Что стоит добавить: хороший QA начинается до написания кода — с проверки требований. Ошибка, найденная в требованиях, стоит в разы дешевле, чем та же ошибка в продакшене. Это принцип раннего тестирования — один из семи принципов тестирования ISTQB.

По объекту:

• функциональное — что система делает;
• нефункциональное — как она это делает: производительность, нагрузка, безопасность, удобство, совместимость, локализация.

По уровню: модульное (unit), интеграционное, системное, приёмочное.

По знанию кода: чёрный ящик (без доступа к коду), белый ящик (с анализом кода), серый ящик (частичное знание — например, структуры БД и API).

По целям прогона:

• Smoke — быстрая проверка, что сборка вообще работает и критичный функционал доступен. Если smoke упал, тестировать дальше бессмысленно — сборку возвращают.
• Sanity — узкая проверка конкретного исправления или изменения после небольшой правки.
• Регрессионное — проверка, что изменения не сломали то, что работало раньше. Самый объёмный вид, поэтому его в первую очередь автоматизируют.
• Повторное (re-test) — проверка, что конкретный исправленный баг действительно исправлен.

По способу: ручное и автоматизированное; исследовательское (exploratory) — тестирование без заранее написанных кейсов, одновременное изучение продукта и поиск дефектов.

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

Граничные значения — ошибки чаще всего прячутся на границах классов: разработчик пишет > вместо >=. Проверяем саму границу и соседние значения.

Пример: поле «возраст» принимает целые числа от 18 до 65.

Граничные значения: 17, 18, 19 и 64, 65, 66.

Плюс невалидные классы, о которых часто забывают: пустое поле, отрицательное число, дробное 18.5, текст abc, пробелы, очень длинное число, специальные символы.

Зачем это на собеседовании: проверяют, умеете ли вы минимизировать число проверок, не теряя покрытия. Сказать «проверю все числа от 1 до 100» — плохо; обоснованно выбрать 10–12 значений — хорошо.

Смежные техники: таблица решений (комбинации условий), попарное тестирование (pairwise — покрывает все пары параметров минимальным числом тестов), диаграммы состояний и переходов.

Структура баг-репорта:

1. Заголовок — что, где и при каких условиях. «Корзина: кнопка «Оформить» неактивна после удаления товара». Не «Ничего не работает».
2. Окружение — версия сборки, браузер или устройство, ОС, стенд.
3. Предусловия — тестовый пользователь, данные.
4. Шаги воспроизведения — нумерованные, минимальные, однозначные.
5. Фактический результат.
6. Ожидаемый результат — со ссылкой на требование.
7. Вложения — скриншот, видео, логи консоли, HAR-файл с сетевыми запросами.
8. Серьёзность и приоритет.

Серьёзность (severity) — насколько дефект влияет на систему. Оценивает тестировщик: blocker, critical, major, minor, trivial.
Приоритет (priority) — как срочно исправлять. Определяет менеджер или владелец продукта, исходя из бизнеса.

Они независимы:

• высокая серьёзность, низкий приоритет — приложение падает при редком действии в скрытой админке, которой пользуются раз в год;
• низкая серьёзность, высокий приоритет — опечатка в названии компании на главной странице перед запуском рекламной кампании.

Главное качество баг-репорта — воспроизводимость: разработчик должен повторить проблему по вашим шагам без уточняющих вопросов.

Типичный путь бага в трекере (Jira, YouTrack):

1. New — тестировщик завёл дефект.
2. Open / Assigned — ответственный подтвердил и назначил разработчика.
3. In Progress — исправляется.
4. Fixed / Resolved — разработчик считает, что исправил, сборка передана на проверку.
5. Re-test / In Testing — тестировщик проверяет исправление и проводит регрессию вокруг.
6. Closed — исправление подтверждено.
7. Reopened — при повторной проверке дефект воспроизводится, возвращается разработчику.

Альтернативные исходы:

• Rejected / Not a bug — поведение соответствует требованиям. Если вы не согласны — обсуждаете со ссылкой на требование или с аналитиком;
• Duplicate — уже заведён;
• Cannot Reproduce — не удалось воспроизвести. Сигнал дополнить окружение, логи, видео;
• Deferred / Won't Fix — решено исправлять позже или не исправлять вовсе.

Что показать на собеседовании: понимание, что статусы и переходы настраиваются под процесс команды, а ответственность тестировщика не заканчивается на заведении бага — он проверяет исправление и следит, чтобы дефект не вернулся в следующих релизах.