Что такое классы эквивалентности, я думаю, все знают. И даже успешно применяют…
И именно поэтому, во избежание эффекта пестицида, советуется, используя эту технику, каждый раз выбирать разные значения диапазона. А если вы автоматизируете приложение — использовать рандомные значения.
Все почему? Потому что бывают в коде баги аля «от 10 до 100 все хорошо, но вот на 25 программа падает…»
И вот например. Есть у вас приложение. В котором часто используются стандартные шаблоны для шапки — щелкаете по колонке отчета, а вам предлагают отсортировать по возрастанию, по убыванию, ну или по значению.
Что же стоит протестировать?
Можно разбить на классы эквивалентности «фильтр/не фильтр». И протестировать все, что хочется, на одном фильтре:
- Отсортировать по возрастанию
- По убыванию
- Повводить туда верную информацию
- Повводить несуществующее значение
- …
И правда, зачем, например, выполнять одни и те же тесты для колонок «Название банка» и «Ближайшая станция метро»? И там и там текст, грид один и тот же. Зачем проверять?
И все-таки, присмотритесь к колонкам повнимательнее — вдруг все-таки можно их разбить на подклассы? Вдруг там есть колонки, в которых не просто строка отображена? А, например, дата. Как будет проходить сортировка по дате? Вы уверены, что она будет абсолютно корректна?
Или, например, текст. Есть простой текст, а есть гиперлинками. Вот казалось бы, и там и там текст. А на гиперлинке приложение — БАХ — и упало. Но перед тем, как бежать заводить багу «Ааааа, кошмар, паника, фильтрация не работает!!!», правильный тестировщик вначале проверит, а действительно ли вообще нигде фильтрация не работает? И сильно удивится, что в соседней колонке все… Хорошо!
А вот ведь как… Вот так тестируешь, тестируешь… И так и сяк и наперекосяк… А потом начинаешь верить, что этот стандартный грид работает нормально, его можно поделить на «фильтр/не фильтр» и все ок. Но это опасно тем, что на ошибку наткнется пользователь…
Вывод — не верьте даже «проверенным средствам»!