Проверять вообще все не надо :)
Вы правильно думаете, что проверять надо только наиболее приоритетное.
Надо определить ограничение и исходить из него.
Это могут быть:
1. Время
2. Пройденные бизнес-сценарии, юз-кейсы, тест-сценарии, тест-кейсы итд.
3. Требования к качеству продукта
4. Стоимость обнаружения ошибки (которая выше потенциальных убытков от ее необнаружения)
и пр.
Один из возможных вариантов действий:
1. Определяем наши ограничения по времени
2. Определяем наиболее критичные сценарии
3. Составляем по ним тесты, прогоняем.
4. Находим менее приоритетные сценарии
5. Составляем тесты прогоняем.
6. Повторяем пункты 4-5, пока не закончится время.
В ходе выполнения тестирования вы можете и не упереться в нехватку времени, если вдруг поймете, что все основные сценарии пройдены, и дальше тестировать будет уже неэффективно - мы придумаем еще 30 тестов, выполним, и вдруг выяснится, что нельзя зарегаться с иероглифами в email на портале lada-kalina-sport2.spb.ru :) Результат этого теста нам как-то не особо важен.
Андрей, спасибо за совет. Действительно, пожалуй, стоит, в первую очередь, оттолкнуться от критичных сценариев работы функционала на единицу ограниченного времени, а не на желание применить все известные методики