При каком типе тестирования находится больше багов: позитивном или негативном
Что проверяют
Не знание определений, а умение распознать вопрос с подвохом. Универсального правильного ответа тут нет, и смотрят, начнёте ли вы с уточнения условий или выдадите заученное «конечно, негативное». Заодно проверяют, различаете ли вы количество найденных дефектов и их значимость.
Как отвечать
Скажите прямо: зависит от зрелости функциональности и от того, как построен тест-дизайн. На стабильной части, которую разработчик уже прогнал по основному сценарию, больше находок даёт негативная проверка: границы диапазонов, пустые и предельные значения, неверные форматы, обрыв сети, нехватка прав. На свежей фиче наоборот, основной сценарий падает сразу и до негативных проверок дело не доходит.
Дальше про технику. Классы эквивалентности и граничные значения дают больше дефектов на единицу усилий, чем перебор случайных неверных вводов: ошибки живут на краях. И негативная проверка это не только поле формы, это ещё права доступа, конкурентное изменение той же сущности, повторная отправка, таймауты, внешняя система, ответившая ошибкой или промолчавшая.
Закончите приоритетом. Дефект на основном пути обычно блокирующий, а десяток негативных находок часто сводится к одной пропущенной валидации. Поэтому позитивные проверки идут первыми в смоуке и регрессе, а негативные раскрываются глубже там, где цена ошибки высокая.
Где спотыкаются
Первое: отвечают цифрой. Названная доля дефектов звучит убедительно ровно до вопроса, откуда она. Своей статистики по проектам у кандидата обычно нет, а чужая ничего не говорит про продукт, о котором спрашивают прямо сейчас.
Второе: сводят негативное тестирование к неверному вводу в форму. За пределами полей остаётся самое интересное: операция над удалённой сущностью, чужой идентификатор в запросе, параллельное редактирование, повтор платежа, недоступный сторонний сервис. Ответ про «буквы в поле возраста» выдаёт узкий кругозор.
Третье: превращают количество багов в цель. Легко завести десятки тикетов на одну причину и не заметить, что основной сценарий сломан для части пользователей. Стоит сказать вслух, что дубли схлопываются в один дефект с общим корнем, а мерой работы остаётся закрытый риск, а не счётчик в трекере.