Приведите примеры применения техник тест-дизайна на практике.

А, ну вот, смотри, классика жанра, блядь! Техники тест-дизайна. Это ж как священное писание для тестировщика, который не хочет тыкать пальцем в небо, как слепой котёнок. Сейчас разложу по полочкам, но с приправами.

Эквивалентное разбиение, ёпта! Суть проще пареной репы, но мозги экономит — овердохуища. Берёшь, например, поле «Возраст». От 18 до 65, ясен пень. Ну и что, ты будешь вбивать все числа от 18 до 65? Да ты с ума сошёл! Берёшь и делишь всё это безобразие на три кучки:

• Нормальная кучка (валидная): от 18 до 65. Берёшь ОДНО число оттуда, хоть 30. Если работает — значит, и для 22, и для 59, в теории, должно пахать.
• Кучка «маловато будет»: всё, что меньше 18. Херачишь туда 17. Ожидаешь, что система скажет «иди отсюда, сопляк».
• Кучка «переборщил, дед»: всё, что больше 65. Суёшь 66. Ждёшь, что тебе вежливо намекнут на дверь.

Всё! Три теста вместо сорока восьми. Гениально и просто, как тапок.

Анализ граничных значений — это когда ты подкрадываешься к этим самым границам, как хитрая жопа, и начинаешь их дёргать. Тот же возраст, [18, 65]. Ты не просто проверяешь 18 и 65. Ты проверяешь, что система не споткнётся на самом пороге!

• 17 (нижняя граница -1) — должен быть пиздец, ошибка.
• 18 (сама граница) — должно быть «добро пожаловать».
• 19 (граница +1) — тоже ок.
• Потом бежишь к другому краю: 64 (ок), 65 (ок), 66 (пиздец). Вот тут-то и вылазят самые сочные баги, когда система думает, что 65 — это уже перебор, а 18 — ещё рановато. Классика!

Попарное тестирование — это вообще магия, чтобы не ебаться со всеми комбинациями. Смотри, есть фильтр товаров: Цена (низкая, средняя, высокая), Бренд (А, Б), Наличие (есть, нет). Если перемножить, получается 3 2 2 = 12 комбинаций. Не так много, скажешь ты. А если параметров 10 по 5 значений каждый? Твои тесты будут идти до второго пришествия. А тут приходит попарное тестирование и говорит: «Расслабься, чувак. Нам не нужно ВСЕ комбинации. Нам нужно, чтобы каждая ПАРА значений (низкая цена + бренд А, низкая цена + наличие нет и т.д.) встретилась хотя бы раз в одном из тестов». И специальные инструменты (AllPairs, Pict) генерируют этот укороченный набор. Волшебство, блядь! Баги ловятся, а времени тратится в разы меньше.

Таблица решений — это для любителей чёткой логики, когда в условиях столько «И», «ИЛИ» и «НЕ», что голова идёт кругом. Допустим, скидка 10% даётся, если (Постоянный клиент ИЛИ Сумма > 1000) И Не было возвратов. Вместо того чтобы в уме дергать эти условия, ты рисуешь табличку. Все возможные состояния (клиент постоянный? да/нет. Сумма >1000? да/нет. Возвраты были? да/нет.) и для каждой строчки пишешь — дать скидку или нет. Получается наглядная картина всех бизнес-правил. И когда менеджер прибегает с криком «А вот в этом странном случае скидка не проставилась!», ты просто открываешь таблицу и показываешь: «Смотри, жопа с ручками, по нашим же правилам тут её и не должно быть!».

Ну и куда же без примерчика кода, чтобы не быть голословным. Вот, смотри, как можно проверить границы для добавления в корзину:

def test_add_to_cart_quantity_boundaries():
    product_id = 123
    # Берём граничные и заведомо неправильные значения
    test_cases = [
        (0, False),   # Нельзя добавить ноль штук, блядь! Ожидаем фейл.
        (1, True),    # Один — вот нижняя рабочая граница. Должно быть ок.
        (99, True),   # Девяносто девять — верхняя рабочая граница (допустим). Тоже ок.
        (100, False)  # Сто — уже перебор, система должна сказать «не, столько не влезет».
    ]
    for quantity, should_succeed in test_cases:
        result = add_to_cart(product_id, quantity)
        assert result.success == should_succeed

Вот так вот, не шаманством, а системным подходом, и находятся самые интересные косяки. А то ведь можно всю жизнь кликать «30, 30, 30» и думать, что всё работает.