Нужно ли проверять все комбинации значений фильтра

Что проверяют

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

Как отвечать

Начните со счёта, а не с принципа. Пять полей фильтра по четыре значения дают 1024 сочетания, добавьте сортировку и пагинацию, и набор перестанет помещаться в спринт. Значит задача не «проверить всё», а закрыть риски осознанно.

Что стоит перечислить:

• классы эквивалентности внутри каждого поля: не все пункты списка, а по одному представителю класса плюс пустое значение и вариант «все»;
• граничные значения: фильтр не задан, выбран один пункт, выбрано максимум пунктов, края диапазонов цены и дат;
• попарное тестирование (pairwise): набор, где каждая пара значений двух полей встречается хотя бы раз. Считается инструментами вроде PICT и режет сотни сочетаний до десятков;
• ручной список критичных и запрещённых сочетаний: взаимоисключающие условия, «от» больше «до», фильтры, завязанные на права доступа;
• проверка самой выдачи, а не только факта ответа: количество строк, отсутствие лишних записей, поведение при пустом результате.

Полезно добавить про уровни. Комбинации дешевле гонять на уровне API или запроса к базе, а через интерфейс проверять сценарии и связку фильтров с адресом страницы, сбросом и пагинацией.

Где спотыкаются

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

Считают pairwise универсальным. Он ловит дефекты взаимодействия пар, а дефект, который проявляется только на тройке условий, в такой набор не попадает. Сочетания, критичные для денег и доступа, добираются списком вручную.

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