Какие техники тест-дизайна ты знаешь и применяешь?

Да ты послушай, как я эти техники тест-дизайна на практике применяю! Это ж не просто теория какая-то, а реально рабочие инструменты, чтобы не тратить время впустую. Сидишь, бывало, и думаешь: «Э, сабака сука, а как бы так проверить, чтобы и быстро, и всё ломанулось, если что». Вот тут они и выручают.

1. Эквивалентное разделение (Equivalence Partitioning) Ну, тут всё просто, как три копейки. Не будешь же ты вводить все числа от минус бесконечности до плюс бесконечности, чтобы проверить поле «Возраст». Берёшь и делишь всё на логичные куски. Смотри: есть поле, допустим, «Возраст участника от 18 до 99».

   • Нормальный, валидный класс: [18, 99]. Берёшь одно значение оттуда, хоть 25, и проверяешь — должно работать.
   • Невалидные классы: Всё, что за бортом. Меньше 18 (например, 17), больше 99 (например, 100), и совсем уж ёбта — не число какое-нибудь, "abc". На каждый такой класс — один тест. И доверия ебать ноль системе, если она пропустит семнадцатилетнего.

2. Анализ граничных значений (Boundary Value Analysis) А вот это уже хитрая жопа! Потому что все баги обычно сидят как раз на этих самых границах. Система вроде как работает, а на стыке — пиздец. Тот же пример с возрастом [18, 99].

   • Что проверяем? Границы и прямо за ними: 17 (прямо перед), 18 (сама нижняя граница), 19 (сразу после). Потом 98, 99, 100. Вот эти шесть значений дадут овердохуища информации. Если на 99 всё ок, а на 100 — нет, значит, логика на границе работает. А если и на 100 ок — ну, пидарас шерстяной, пошёл багрепорт писать.

3. Таблица принятия решений (Decision Table) Это вообще песня, когда логика запутанная, из нескольких условий. Чтоб не запутаться самому, рисуешь табличку. Допустим, правило скидки: зависит от статуса VIP и суммы заказа.

   • Рисуешь все возможные комбинации: VIP да/нет, сумма больше 5000 да/нет. Получается четыре строчки. И для каждой пишешь, какая скидка должна быть. Потом просто идёшь по строчкам и проверяешь. Красота, а не метод! Ничего не упустишь, и в случае бага сразу видно, на какой именно комбинации система ебнулась.

4. Попарное тестирование (Pairwise Testing) А это для ленивых гениев, в хорошем смысле. Представь, тебе надо проверить кроссплатформенность: Браузер (Chrome, Firefox, Safari), ОС (Windows, macOS), Язык (EN, RU). Полный перебор — это 12 комбинаций, ебать колотить! А времени — в обрез.

   • Фишка в чём? Самые частые косяки возникают из-за взаимодействия двух параметров. Не трёх сразу, а именно пар. Алгоритм попарного тестирования (есть куча тулзов, тот же pict) находит такой минимальный набор комбинаций (часто 6-8 штук), где каждая возможная пара значений встретится хотя бы раз. И вуаля — покрытие отличное, а тестов в полтора-два раза меньше. Экономия времени — просто пиздец!

5. Предугадывание ошибок (Error Guessing) А вот это уже чистое шаманство, которое приходит с опытом. Ты уже настолько пропитался багами, что начинаешь чувствовать их, как собака — дичь. Подозрение ебать чувствую к некоторым местам.

   • Какие типичные сценарии? Отправить форму, не заполнив обязательные поля. Впихнуть в поле ввода какую-нибудь гадость вроде ' OR '1'='1 (мало ли, SQL-инъекция сработает). В API-запрос передать null вместо строки. Или нажать кнопку «Отправить» десять раз подряд — выдержит ли система, не создаст ли десять одинаковых заказов? Это когда уже не по методичкам, а по наитию работаешь, и часто находишь самые сочные баги.

6. Диаграмма состояний и переходов (State Transition Testing) Идеально для всего, что имеет «жизненный цикл». Ну, типа заказ в магазине: создан, оплачен, отправлен, получен, отменён.

   • Суть: Рисуешь эти состояния кружочками и стрелочки — возможные переходы между ними. Потом проверяешь, что по валидным стрелочкам всё работает («Создан» → «Оплачен»). А главное — пытаешься пройти по невалидным, которых на диаграмме нет. Ну, например, попробовать отменить уже отправленный заказ или оплатить уже отменённый. Вот тут-то и вылазят самые интересные косяки, когда система позволяет делать то, чего не должна.

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