Комментарии 4
Я бы не стал тыкать внутрь класса. У нас нет никакой гипотезы для выбора такого значения. 10 ничем не лучше 8. Так что если уж "усушивать" количество необходимых проверок, то достаточно двух тестов, для границы класса - 17 и 18.
На практике, конечно, ошибки будут совсем в другом месте. Например список не будет выпадать, кнопка не будет активироваться при выборе нужного значения, список возрастов будет пустой или поле будет неактивно, или не видимо, и прочее и прочее.
Как в том старом анекдоте
У нового испытательного образца советского самолета все время отрывались крылья. Лучшие инженеры страны думали-думали, как это исправить - ничего путного в голову не приходит. Приехал к ним стажер. Позвали и его на совещание. Ну он и предлагает:
- А давайте по линии слома просверлим дырочки!
- Ты что! Крылья же тогда еще легче будут отваливаться!
- Но ведь в туалетной бумаге тоже есть дырочки, но по ним-то никогда не рвется!
>либо тем, что программист может ошибиться в выборе границы и указать 17 (или 19) вместо 18.
Чаще тем, что в коде могут быть проверки "меньше границы" и "больше границы" вместо >=
А в целом можно усложнять до бесконечности: классы "не входит в допустимый диапазон (<1 и >100)", "не является целым числом", "числом в принципе" (здесь вообще раздолье для дробления)
Специально зарегистрировался на хабре, чтобы оставить этот коммент.
Храни Вас хосподь. Мб этой статьёй вы спасёте пару-тройку заблудших QA-душ, которые в какой-то момент покатились по наклонной.
Очередная "хвала" онлайн-курсам. Горе-менторы упорно продолжают учить падаванов проверять границу+1.
Привет Яндекс Практикуму и иже с ними.
17 и 18 - это и есть +/-1 на границе, тут просто самой границы нет, как интервалы на прямой с выколотой точкой. Поэтому не очень понятно, что не так с методикой граничных значений.
В целом тестировщик, как правило, отталкивается от времени, которое ему выделили на тестирование. Поэтому если есть возможность за это время проверить все варианты - проверяем все варианты. По опыту довольно часто ошибки возникают на границе и около неё. Поэтому если позволяет время в этом случае стоит проверить и 19. Все наши предположения о том, как там разработчик написал в коде могут тысячу раз быть неверными. Он возраст мог получать в виде даты и через разницу с текущей датой вычислять возраст, мог дату как строку разбирать своим кривым алгоритмом, а мог подумать что условие - это до 18 лет нельзя, значит после 19 можно.
Два или три тест-кейса для проверки граничных значений?