Привет. Обычно называю это методом тестирования всех путей. Это нужная штука, когда нужно проверить много ветвлений, так как есть вероятность, что в одной из веток может забаговать. Благо, в моей работе таких веток вариантов немного и их можно проверить все))
Да! Нередко какая-то из веток, да забывается. В том числе и в требованиях. Если условий много, комбинаций тоже будет много, тут уже лучше смотреть в сторону pairwise testing.
одного понять не могу.Изучаю эту тему и в уроках говорят, что надо удалить столбцы с одинаковыми данными на входе и результатами, оставив один. Не важно,что в остальных ячейках- результат то все равноодин и тот же. Типа это по сути одинковое поведение системы и не тратим время на одинковое тестирование. А я не понимаюю, а что если я уберу, и сделаю меньше тестов, а вдруг при программировании не учтут эту комбинацию в итоге вообще. Или я должна предположить,что они в любом случае ее разработают на основании требований, но я просто сократила время на тестирование для себя, предпологая,что сделав один подобный сценарий теста, и если там все ок, то и в тех все ок. А что если там баг, то и в тех баг. А в каких тех баг, если я их удалила из таблицы.... Почему я так переживаю за это, не знаю прям. Вот и не понимаю все эти схлопывания таблиц
Возьмите технику тест-дизайна Классы эквивалентности. Там мы тоже из 1 класса берём 1 представителя и считаем, что по результату тестирования на нем можно определить результаты тестирования на всех таких же данных. Полную уверенность, что вы отобрали тесты правильно, можно получить только, посмотрев код реализации. Напишите мне в телеграмм @lenapoploukhina конкретный пример, который вы не понимаете, попробуем разобраться.
Не поняла смысл удаления невалидных значений. Разве принцип ТПР не в том, чтобы рассмотреть все возможные комбинации условий? Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора? Просто в ситуации с покупкой в 1500 рублей может быть как ситуация с подарочной пиццей, так и возможность получения скидки (50/50). Аналогично с 7 днями: покупатель точно получает скидку 20%, но также он может в 2 случаях выбрать вместо этого пиццу в подарок. (P.S. Сталкивалась с похожей ситуацией при заказе пиццы: или применить промокод для скидки, или получить пиццу в подарок, брала то, что выгоднее). Спасибо большое за ответ и отдельная благодарность за наглядное видео!
Спасибо за такой интересный вопрос. Невалидные значения - это сочетания Тип заказа "Первый заказ" - Время повторного заказа. Они не могут по логике существовать. А удаление строк с границами - это дублирующие кейсы. Именно границы - нам достаточно проверить только 1 раз. Чтобы в этом убедиться, можно заглянуть в код приложения - там они будут проверять только 1 раз. Поэтому, если граница не работает в одном месте, она не будет работать и во всех остальных. Получается, нет смысла проверять, например, границу "7 дней" 3 раза, в целях оптимизации времени на тестирование достаточно проверить только 1 раз. Мы оставили 2 кейса с границами именно для того, чтобы проверить их по отдельности, а не вместе. Поскольку акции не суммируются. >Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора? Как раз эта ситуация объясняется в видео на примере Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб". Аналитик нам не описал это требование. Поэтому в реальности мы должны пойти к аналитику и узнать у него, какое поведение будет для этого случая. Т.е. это неполное требование. Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб" Время повторного заказа "7 дней" - Стоимость заказа "1500 руб" - это кейсы-дубликаты, исходя из всего вышенаписанного. Совет могу дать следующий. Если разработчик обычно пишет качественный код, не допускает критических или блокирующих багов - можно в целях оптимизации времени удалять дубликаты, в которых проверяются границы. В сентябре планируем выпустить видео, где подробнее на примере анализа кода расскажем про этот момент.
Я очень много раз пыталась это в своей работе использовать, но все как-то никак не получается) Так что как только появится возможность, сделаю очередной подход к снаряду)
При использовании таблицы принятия решений мы создаем все возможные комбинаций значений параметров и проверяем их. Некоторые можем удалить как дублирующие или невозможные по бизнес-логике. Но изначально количество получаемых комбинаций, т.е. тест-кейсов должно быть ограниченным, небольшим. Например, 10-15. А pairwise testing используется в ситуациях, когда у нас присутствует много параметров и их возможных значений. И в итоге получается большое количество комбинаций (будущих тест-кейсов), которые очень трудозатратно по времени проверить. Например, 100 комбинаций, 1 тысяча комбинаций или более. Поэтому при помощи специальных алгоритмов отбираются только комбинации пар значений параметров. Таким образом, мы существенно сокращаем количество тест-кейсов при таком же уровне качества.
Спасибо за разбор на примере! Очень полезно!
Пожалуйста! Следите за следующими видео, будет еще много интересного.
Привет. Обычно называю это методом тестирования всех путей. Это нужная штука, когда нужно проверить много ветвлений, так как есть вероятность, что в одной из веток может забаговать. Благо, в моей работе таких веток вариантов немного и их можно проверить все))
Да! Нередко какая-то из веток, да забывается. В том числе и в требованиях. Если условий много, комбинаций тоже будет много, тут уже лучше смотреть в сторону pairwise testing.
Просмотрев видеоурок сразу подумал об одной пиццерии в которой я работаю, описанный случай случайно не о пиццерии С****ия?)) просто интересно
Вполне возможно)))
одного понять не могу.Изучаю эту тему и в уроках говорят, что надо удалить столбцы с одинаковыми данными на входе и результатами, оставив один. Не важно,что в остальных ячейках- результат то все равноодин и тот же. Типа это по сути одинковое поведение системы и не тратим время на одинковое тестирование. А я не понимаюю, а что если я уберу, и сделаю меньше тестов, а вдруг при программировании не учтут эту комбинацию в итоге вообще. Или я должна предположить,что они в любом случае ее разработают на основании требований, но я просто сократила время на тестирование для себя, предпологая,что сделав один подобный сценарий теста, и если там все ок, то и в тех все ок. А что если там баг, то и в тех баг. А в каких тех баг, если я их удалила из таблицы.... Почему я так переживаю за это, не знаю прям.
Вот и не понимаю все эти схлопывания таблиц
Возьмите технику тест-дизайна Классы эквивалентности. Там мы тоже из 1 класса берём 1 представителя и считаем, что по результату тестирования на нем можно определить результаты тестирования на всех таких же данных.
Полную уверенность, что вы отобрали тесты правильно, можно получить только, посмотрев код реализации.
Напишите мне в телеграмм @lenapoploukhina конкретный пример, который вы не понимаете, попробуем разобраться.
Не поняла смысл удаления невалидных значений. Разве принцип ТПР не в том, чтобы рассмотреть все возможные комбинации условий? Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора? Просто в ситуации с покупкой в 1500 рублей может быть как ситуация с подарочной пиццей, так и возможность получения скидки (50/50). Аналогично с 7 днями: покупатель точно получает скидку 20%, но также он может в 2 случаях выбрать вместо этого пиццу в подарок. (P.S. Сталкивалась с похожей ситуацией при заказе пиццы: или применить промокод для скидки, или получить пиццу в подарок, брала то, что выгоднее).
Спасибо большое за ответ и отдельная благодарность за наглядное видео!
Спасибо за такой интересный вопрос.
Невалидные значения - это сочетания Тип заказа "Первый заказ" - Время повторного заказа. Они не могут по логике существовать.
А удаление строк с границами - это дублирующие кейсы. Именно границы - нам достаточно проверить только 1 раз. Чтобы в этом убедиться, можно заглянуть в код приложения - там они будут проверять только 1 раз. Поэтому, если граница не работает в одном месте, она не будет работать и во всех остальных. Получается, нет смысла проверять, например, границу "7 дней" 3 раза, в целях оптимизации времени на тестирование достаточно проверить только 1 раз. Мы оставили 2 кейса с границами именно для того, чтобы проверить их по отдельности, а не вместе. Поскольку акции не суммируются.
>Что происходит в случае возможной скидки 20% и получении пиццы: пользователь может выбрать что-то одно или ему не предоставляется право выбора?
Как раз эта ситуация объясняется в видео на примере Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб". Аналитик нам не описал это требование. Поэтому в реальности мы должны пойти к аналитику и узнать у него, какое поведение будет для этого случая. Т.е. это неполное требование.
Время повторного заказа "Более 7 дней" - Стоимость заказа "Более 1500 руб"
Время повторного заказа "7 дней" - Стоимость заказа "1500 руб"
- это кейсы-дубликаты, исходя из всего вышенаписанного.
Совет могу дать следующий. Если разработчик обычно пишет качественный код, не допускает критических или блокирующих багов - можно в целях оптимизации времени удалять дубликаты, в которых проверяются границы.
В сентябре планируем выпустить видео, где подробнее на примере анализа кода расскажем про этот момент.
Я очень много раз пыталась это в своей работе использовать, но все как-то никак не получается) Так что как только появится возможность, сделаю очередной подход к снаряду)
И пусть все получится! :)
А я думала, что эта техника называется pairwise testing 🤔
При использовании таблицы принятия решений мы создаем все возможные комбинаций значений параметров и проверяем их. Некоторые можем удалить как дублирующие или невозможные по бизнес-логике. Но изначально количество получаемых комбинаций, т.е. тест-кейсов должно быть ограниченным, небольшим. Например, 10-15.
А pairwise testing используется в ситуациях, когда у нас присутствует много параметров и их возможных значений. И в итоге получается большое количество комбинаций (будущих тест-кейсов), которые очень трудозатратно по времени проверить. Например, 100 комбинаций, 1 тысяча комбинаций или более. Поэтому при помощи специальных алгоритмов отбираются только комбинации пар значений параметров. Таким образом, мы существенно сокращаем количество тест-кейсов при таком же уровне качества.
@@qabuggage спасибо за ответ)