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

[@Alexandra03ful]

Спасибо за разбор на примере! Очень полезно!

[@qabuggage]

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

[@Dark_Moon_270]

Привет. Обычно называю это методом тестирования всех путей. Это нужная штука, когда нужно проверить много ветвлений, так как есть вероятность, что в одной из веток может забаговать. Благо, в моей работе таких веток вариантов немного и их можно проверить все))

[@qabuggage]

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

[@константинкотов-м3ы]

Просмотрев видеоурок сразу подумал об одной пиццерии в которой я работаю, описанный случай случайно не о пиццерии С****ия?)) просто интересно

[@qabuggage]

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

[@Ekaterina88008]

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

[@qabuggage]

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

[@somebody2833]

Я очень много раз пыталась это в своей работе использовать, но все как-то никак не получается) Так что как только появится возможность, сделаю очередной подход к снаряду)

[@qabuggage]

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

[@АннаГорячева-з7ц]

Не поняла смысл удаления невалидных значений. Разве принцип ТПР не в том, чтобы рассмотреть все возможные комбинации условий? Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора? Просто в ситуации с покупкой в 1500 рублей может быть как ситуация с подарочной пиццей, так и возможность получения скидки (50/50). Аналогично с 7 днями: покупатель точно получает скидку 20%, но также он может в 2 случаях выбрать вместо этого пиццу в подарок. (P.S. Сталкивалась с похожей ситуацией при заказе пиццы: или применить промокод для скидки, или получить пиццу в подарок, брала то, что выгоднее). Спасибо большое за ответ и отдельная благодарность за наглядное видео!

[@qabuggage]

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

[@miss_justice_]

А я думала, что эта техника называется pairwise testing 🤔

[@qabuggage]

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

[@miss_justice_]

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