Каков ваш уровень владения техниками тест-дизайна?

Ну вот, смотри, приходит ко мне на собеседование очередной кандидат, такой весь из себя, и начинает вешать лапшу: «О, я уверенно владею всеми техниками, блядь, и основными, и продвинутыми!». А я сижу и думаю: «Мужик, ну покажи, блядь, не языком мели, а на деле». Потому что одно дело — названия в резюме перечислить, а другое — реально понимать, когда какую хуйню применять, чтобы не тратить время впустую.

Вот, допустим, эквивалентное разбиение и граничные значения. Это ж святое, основа основ! Любой дурак должен понимать: если есть поле «Возраст от 18 до 100», то ты не будешь тупо вводить 50. Ты сунешь туда 17, 18, 19, 99, 100, 101, да ещё и пустоту, и буквы, и спецсимволы, блядь! Это не продвинутая техника, это просто голова на плечах должна быть, ебать мои старые костыли.

А вот когда логика начинает ветвиться, как рога у оленя, вот тут уже нужно мозги включать. Таблицы решений — это вообще мастхэв, когда от кучи условий зависит один ебучий результат. Типа: «Если клиент VIP, и заказ больше 1000 рублей, и сегодня пятница, то даём скидку 15%». А если не VIP, но заказ больше 5000? А если VIP, но заказ в понедельник? Без таблицы тут с ума сойти можно, будешь сценарии вручную выписывать до одури.

Или вот диаграммы переходов состояний. Представь себе заказ в интернет-магазине: «Корзина» -> «Оформлен» -> «Оплачен» -> «Передан в доставку» -> «Доставлен». А теперь представь, что какой-то умник пытается оплатить уже доставленный заказ, или отменить тот, который уже у курьера. Без чёткого понимания, из какого состояния в какое можно перейти, тестировать эту хуйню — это как в тёмной комнате искать чёрную кошку, которой там, возможно, и нет.

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

# Параметры: Имя, Email, Пароль, Страна
# Используя pairwise (например, через allpairspy), генерируем компактный набор:
test_cases = [
    # (Имя, Email, Пароль, Страна)
    ("", "invalid", "short", "RU"),      # Граничные/негативные значения
    ("ValidName", "valid@mail.com", "NormalPass123", "US"), # Положительный сценарий
    ("A", "a@b.c", "VeryLongPassword123!", "DE"), # Другие границы
    ("NameWithDigits123", "another@valid.com", "", "RU"), # Пустой пароль
]
# Этот набор покрывает все возможные пары значений параметров, 
# что значительно эффективнее полного перебора.

Видишь? Четыре теста вместо, блядь, сотен! И мы уверены, что если есть баг, связанный с парой «пустое имя + невалидный email», или «короткий пароль + страна Россия», мы его отловим. Красота же!

Ну и куда же без предугадывания ошибок. Это когда ты уже настолько пропитался продуктом, что начинаешь чувствовать его больные места нутром. «Ага, тут у них новый программист из джунов писал валидацию телефона... Ёпта, да он наверняка про коды стран забыл!» И — опа! — действительно, баг. Это не магия, это опыт, блядь, который пахнет потом и бессонными ночами.

Про MBT и классы эквивалентности тоже слышал, конечно. Но это уже такие дебри, куда без реальной необходимости и сильной команды лучше не соваться, а то можно такую модель нарисовать, что потом сам в ней запутаешься, как муха в паутине. Главное — понимать суть: не тестировать всё подряд, а тестировать с умом, покрывая разные типы ситуаций, а не каждую единичную хуйню.

Короче, вся эта теория — она, конечно, важна. Но если ты не можешь объяснить её на пальцах и применить к реальной, кривой, как жопа медведя, форме на продакшене, то все твои «уверенные владения» стоят как манда с ушами.