Позитивные и негативные проверки: почему важно ломать программу намеренно

Зачем нам этот урок?

Представьте, что вы открыли кафе и наняли нового кассира. Вы объясняете ему, как принимать оплату картой, он кивает, всё понял. Но вы так и не проверили: а что будет, если карта заблокирована? Что если покупатель введёт неверный PIN три раза? Что если на счёте нет денег?

Именно в таких нестандартных ситуациях и прячутся проблемы. Программное обеспечение — не исключение.

В этом уроке мы разберём два фундаментальных подхода к тестированию: позитивные и негативные проверки. Вы поймёте, почему опытный тестировщик не просто проверяет, «работает ли всё хорошо», но и намеренно пытается сломать программу — и почему это не вредительство, а профессиональная необходимость.

Теория

Что такое «проверка» в тестировании?

Проверка (или тест-кейс от английского test case — буквально «тестовый случай») — это одно конкретное действие или сценарий, которое мы выполняем, чтобы убедиться: программа ведёт себя так, как ожидается.

Проверка всегда состоит из трёх частей:

Если фактический результат совпал с ожидаемым — тест прошёл ✅. Если нет — найден баг (ошибка в программе) 🐛.

Позитивные проверки: «всё как надо»

Позитивная проверка — это сценарий, где мы используем правильные, допустимые данные и проверяем, что программа выполняет свою основную задачу.

Проще говоря: мы делаем именно то, для чего программа предназначена, и смотрим — справляется ли она.

Аналогия: Вы купили новый замок для двери. Позитивная проверка — взять правильный ключ и убедиться, что дверь открывается. Логично? Да. Достаточно ли этого? Нет.

Примеры позитивных проверок

Представим простую форму входа на сайт с двумя полями: «Email» и «Пароль».

Форма входа:
[  Email  ______________________ ]
[ Пароль  ______________________ ]
[         Войти                  ]

Позитивный тест-кейс:

• Входные данные: Email = [email protected], Пароль = correctPass123
• Действие: Нажать кнопку «Войти»
• Ожидаемый результат: Система принимает данные, пользователь попадает в личный кабинет

Это и есть позитивная проверка: правильные данные → ожидаемое поведение.

Негативные проверки: «а что если...»

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

Ключевое слово здесь — намеренно. Мы не случайно ошибаемся — мы осознанно испытываем программу на прочность.

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

Что значит «корректно обработать»?

Это не значит, что программа должна «сломаться в тишине» или зависнуть. Корректная обработка — это:

• Показать понятное сообщение об ошибке
• Не дать пользователю продолжить с неверными данными
• Не упасть с непонятной надписью типа Error 500 или белым экраном

Примеры негативных проверок для той же формы входа:

Почему негативные проверки так важны?

Давайте честно: большинство разработчиков пишут код в расчёте на нормальное использование. Они думают: «Пользователь введёт email, введёт пароль, нажмёт кнопку — всё готово». Это называется счастливый путь (от английского happy path).

Но реальные пользователи:

• Делают опечатки
• Забывают заполнить поля
• Случайно вставляют лишние символы
• Иногда пытаются взломать систему (злоумышленники)
• Иногда просто ведут себя непредсказуемо

Если программа не готова к этому — она либо сломается, либо поведёт себя опасно (например, примет взлом как корректный ввод).

💡 Профессиональный принцип: Хорошее тестирование — это всегда и позитивные, и негативные проверки. Одно без другого — неполная картина.

Граничные значения: особый вид негативных проверок

Отдельного внимания заслуживают граничные значения — данные, которые находятся на самом краю допустимого диапазона.

Аналогия: Мост рассчитан на 10 тонн. Нас интересует не только «едет грузовик 5 тонн» (позитивно) и «едет грузовик 20 тонн» (явно негативно). Нас очень интересует граница: что происходит при 9,9 тонны? При 10 тоннах ровно? При 10,1 тонны?

Именно на границах чаще всего прячутся баги.

Пример: Поле «Возраст» принимает значения от 0 до 120.

Допустимый диапазон: [0 ... 120]
                      ↑           ↑
                   Нижняя       Верхняя
                   граница      граница

Что проверяем:

Как мыслить «негативно»: вопросы тестировщика

Когда вы видите любую форму или функцию, задавайте себе эти вопросы:

1. Что если ничего не ввести? — пустые поля
2. Что если ввести слишком мало или слишком много? — граничные значения
3. Что если ввести неверный тип данных? — буквы вместо цифр и наоборот
4. Что если ввести специальные символы? — !@#$%^&*, эмодзи, кириллица в английском поле
5. Что если повторить действие несколько раз? — нажать кнопку 10 раз подряд
6. Что если сделать всё в неправильном порядке? — например, перейти на страницу оплаты, не добавив товар

Пример: разбираем форму регистрации

Разберём конкретный пример от начала до конца. Перед нами форма регистрации:

Форма регистрации нового пользователя:

[ Имя пользователя ]  (от 3 до 20 символов, только латинские буквы и цифры)
[ Email            ]  (стандартный формат email)
[ Пароль           ]  (минимум 8 символов)
[ Повтор пароля    ]  (должен совпадать с паролем)
[   Зарегистрироваться   ]

Позитивные тест-кейсы

Тест-кейс 1 (позитивный): Успешная регистрация
─────────────────────────────────────────────────
Имя:           john123
Email:         [email protected]
Пароль:        mySecret8
Повтор пароля: mySecret8

Ожидаемый результат: Пользователь зарегистрирован,
                     приходит письмо на почту,
                     открывается страница приветствия.

Негативные тест-кейсы

Тест-кейс 2 (негативный): Пустое имя пользователя
─────────────────────────────────────────────────
Имя:           (пусто)
Email:         [email protected]
Пароль:        mySecret8
Повтор пароля: mySecret8

Ожидаемый результат: Форма не отправляется,
                     под полем "Имя" появляется
                     сообщение "Обязательное поле".

Тест-кейс 3 (негативный): Имя слишком короткое (граница)
─────────────────────────────────────────────────
Имя:           ab   ← 2 символа (минимум — 3)
Email:         [email protected]
Пароль:        mySecret8
Повтор пароля: mySecret8

Ожидаемый результат: Форма не отправляется,
                     сообщение: "Имя должно содержать
                     от 3 до 20 символов".

Тест-кейс 4 (негативный): Пароли не совпадают
─────────────────────────────────────────────────
Имя:           john123
Email:         [email protected]
Пароль:        mySecret8
Повтор пароля: otherPass9

Ожидаемый результат: Форма не отправляется,
                     сообщение: "Пароли не совпадают".

Тест-кейс 5 (негативный): Кириллица в имени пользователя
─────────────────────────────────────────────────
Имя:           Иван123
Email:         [email protected]
Пароль:        mySecret8
Повтор пароля: mySecret8

Ожидаемый результат: Форма не отправляется или
                     поле не принимает кириллицу,
                     сообщение: "Разрешены только
                     латинские буквы и цифры".

Тест-кейс 6 (негативный): Email без символа @
─────────────────────────────────────────────────
Имя:           john123
Email:         johnexample.com   ← нет знака @
Пароль:        mySecret8
Повтор пароля: mySecret8

Ожидаемый результат: Форма не отправляется,
                     сообщение: "Введите корректный
                     адрес электронной почты".

Обратите внимание: для каждого теста мы чётко фиксируем, что вводим и что должно произойти. Это позволяет потом объективно сравнить: программа сделала то, что требовалось, или нет.

Практика

Выполните следующие задания самостоятельно. Для этого вам понадобится только блокнот (или любой текстовый редактор) и немного наблюдательности.

Задание 1: Найдите форму и составьте список проверок

Откройте любой сайт с формой регистрации или входа (например, страницу создания аккаунта на любом интернет-магазине или новостном портале).

Посмотрите на форму и выпишите:

• 3 позитивных тест-кейса — что должно работать правильно
• 5 негативных тест-кейсов — что может пойти не так

Оформите каждый тест-кейс в таком виде:

Тест-кейс №__: [Название]
Входные данные: ...
Действие: ...
Ожидаемый результат: ...

Задание 2: Выполните негативные проверки вручную

Возьмите форму из задания 1 и реально попробуйте ввести некорректные данные:

• Оставьте все поля пустыми и нажмите кнопку отправки
• Введите в поле email что-то без символа @
• Введите очень короткий пароль (1–2 символа)

Зафиксируйте: что произошло? Показала ли программа понятное сообщение об ошибке? Зависла? Позволила продолжить несмотря на ошибку?

Задание 3: Граничные значения в поле «Возраст»

Представьте форму заказа такси, где нужно указать возраст водителя. По правилам, водителем может быть человек от 18 до 65 лет.

Составьте таблицу граничных и около-граничных значений для проверки — как в разделе теории выше. Укажите для каждого значения: это позитивная или негативная проверка, и какой результат вы ожидаете.

Подсказка: Вспомните пример с полем «Возраст» из теории и примените ту же логику к диапазону 18–65.

Задание 4 (для тех, кто хочет глубже): Думаем как злоумышленник

Представьте поле для ввода промокода в интернет-магазине. Ваша задача — придумать 10 негативных сценариев, используя следующие категории:

• Пустой ввод
• Слишком длинный промокод
• Пробелы (в начале, в конце, внутри)
• Специальные символы (!, ", <, >, /)
• Уже использованный промокод
• Истёкший промокод
• Промокод в неправильном регистре (SALE10 vs sale10)

Для каждого сценария запишите: что, по-вашему, должна делать хорошая программа?

Итоги урока

• Позитивная проверка — проверяем, что программа работает правильно при корректных данных. Это «счастливый путь».
• Негативная проверка — намеренно подаём некорректные данные, чтобы убедиться: программа не сломается и покажет понятную ошибку.
• Проверять только «счастливый путь» — недостаточно: большинство реальных проблем скрывается именно в нестандартных ситуациях.
• Граничные значения — особый вид данных, которые находятся на краях допустимого диапазона. Там баги прячутся особенно часто.
• Хороший тестировщик всегда задаёт себе вопрос: «А что если...?» — и не боится намеренно «ломать» программу, потому что лучше найти баг сейчас, чем позволить пользователю столкнуться с ним в реальности.
• Каждая проверка фиксируется в виде тест-кейса: входные данные → действие → ожидаемый результат.