Таблица принятия решений 

Пожалуйста! Следите за следующими видео, будет еще много интересного.

Да! Нередко какая-то из веток, да забывается. В том числе и в требованиях. Если условий много, комбинаций тоже будет много, тут уже лучше смотреть в сторону pairwise testing.

Вполне возможно)))

Возьмите технику тест-дизайна Классы эквивалентности. Там мы тоже из 1 класса берём 1 представителя и считаем, что по результату тестирования на нем можно определить результаты тестирования на всех таких же данных. Полную уверенность, что вы отобрали тесты правильно, можно получить только, посмотрев код реализации. Напишите мне в телеграмм @lenapoploukhina конкретный пример, который вы не понимаете, попробуем разобраться.

Спасибо за такой интересный вопрос. Невалидные значения - это сочетания Тип заказа "Первый заказ" - Время повторного заказа. Они не могут по логике существовать. А удаление строк с границами - это дублирующие кейсы. Именно границы - нам достаточно проверить только 1 раз. Чтобы в этом убедиться, можно заглянуть в код приложения - там они будут проверять только 1 раз. Поэтому, если граница не работает в одном месте, она не будет работать и во всех остальных. Получается, нет смысла проверять, например, границу "7 дней" 3 раза, в целях оптимизации времени на тестирование достаточно проверить только 1 раз. Мы оставили 2 кейса с границами именно для того, чтобы проверить их по отдельности, а не вместе. Поскольку акции не суммируются. >Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора? Как раз эта ситуация объясняется в видео на примере Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб". Аналитик нам не описал это требование. Поэтому в реальности мы должны пойти к аналитику и узнать у него, какое поведение будет для этого случая. Т.е. это неполное требование. Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб" Время повторного заказа "7 дней" - Стоимость заказа "1500 руб" - это кейсы-дубликаты, исходя из всего вышенаписанного. Совет могу дать следующий. Если разработчик обычно пишет качественный код, не допускает критических или блокирующих багов - можно в целях оптимизации времени удалять дубликаты, в которых проверяются границы. В сентябре планируем выпустить видео, где подробнее на примере анализа кода расскажем про этот момент.

И пусть все получится! :)

При использовании таблицы принятия решений мы создаем все возможные комбинаций значений параметров и проверяем их. Некоторые можем удалить как дублирующие или невозможные по бизнес-логике. Но изначально количество получаемых комбинаций, т.е. тест-кейсов должно быть ограниченным, небольшим. Например, 10-15. А pairwise testing используется в ситуациях, когда у нас присутствует много параметров и их возможных значений. И в итоге получается большое количество комбинаций (будущих тест-кейсов), которые очень трудозатратно по времени проверить. Например, 100 комбинаций, 1 тысяча комбинаций или более. Поэтому при помощи специальных алгоритмов отбираются только комбинации пар значений параметров. Таким образом, мы существенно сокращаем количество тест-кейсов при таком же уровне качества.

@@qabuggage спасибо за ответ)