Позитивные и негативные проверки

Разработчик показывает форму регистрации: вводишь email, пароль, имя — жмёшь «Зарегистрироваться» — аккаунт создан. Работает. Он доволен, тестировщик открывает форму и первым делом стирает email. Потом вставляет пароль из одного пробела. Потом жмёт кнопку регистрации дважды подряд, пока страница ещё грузится. На третьей попытке падает ошибка 500, и в базе остаётся наполовину созданный аккаунт без пароля.

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

Требование описывает удачу

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

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

Позитивная проверка: подтверждаем задуманное

Позитивная проверка (её ещё называют проверкой по счастливому пути) — это тест с корректными, ожидаемыми данными в рамках того, что описано в требовании. Открыл форму, ввёл реальный email и нормальный пароль, нажал кнопку — аккаунт появился. Позитивная проверка отвечает на вопрос «работает ли то, что заказали?».

Негативная проверка: ищем то, что не предусмотрели

Негативная проверка — это тест с некорректными, неожиданными или пограничными данными, которые в требовании не упомянуты. Пустой email, пароль из пробелов, число вместо имени, двойной клик по кнопке. Негативная проверка отвечает на другой вопрос: «что произойдёт, если пользователь поведёт себя не так, как мы надеялись?».

Пользователи ведут себя не так, как мы надеялись, постоянно: опечатываются, торопятся, используют форму не по адресу устройства, теряют связь на середине действия. Это не редкость — это будни продакшена.

  Что покрывает требование, а что реальность пользователя

  Требование:            "пользователь вводит email и пароль"

  +----------------------------------------------+
  |            ПОЗИТИВНЫЙ СЦЕНАРИЙ                |
  |   email: ivan@mail.ru   пароль: Qwerty123     |
  +----------------------------------------------+

  Реальность пользователя (негативные сценарии):
  +---------------+  +----------------+  +----------------+
  | email: пусто  |  | пароль: " "    |  | email: 300 букв |
  +---------------+  +----------------+  +----------------+
  +----------------+  +------------------+  +----------------+
  | клик x2 подряд |  | обрыв сети       |  | email без "@"   |
  +----------------+  +------------------+  +----------------+

  Требование описывает один прямоугольник сверху.
  Тестировщик отвечает за все прямоугольники снизу.

Семь источников негативных проверок

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

  1. Пустое значение. Поле осталось незаполненным или очищено уже после ввода.
  2. Значение на границе длины. Слишком короткое (один символ) или слишком длинное (тысяча символов) для этого поля.
  3. Неверный тип данных. Буквы там, где ждут число; дата там, где ждут текст.
  4. Неверный формат. Email без «@», телефон без кода страны, дата 31.02.2027.
  5. Спецсимволы и потенциальные инъекции. Кавычки, теги, SQL-конструкции в обычном текстовом поле.
  6. Прерванное или повторное действие. Обрыв соединения на середине отправки формы; двойной клик по кнопке, пока запрос ещё выполняется.
  7. Действие без прав или не по порядку. Попытка зайти в личный кабинет без регистрации; попытка оплатить курс, не выбрав тариф.

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

Применяем список к реальному полю

Возьмём поле «Email» в форме регистрации на нашем учебном полигоне. Требование: «пользователь вводит email, система проверяет его формат и создаёт аккаунт». Прогоняем поле через семь категорий.

  • Позитив: ivan.petrov@mail.ru — аккаунт создан.
  • Пустое значение: поле оставлено пустым — ожидаем сообщение «заполните email», а не создание аккаунта без адреса.
  • Граница длины: email из 300 символов — ожидаем корректную ошибку, а не обрыв формы.
  • Неверный тип: в поле вставлен номер телефона — ожидаем отказ по формату.
  • Неверный формат: ivan.petrov.mail.ru без «@» — ожидаем отказ с понятным текстом ошибки.
  • Спецсимволы: ivan'--@mail.ru — ожидаем, что символы обработаются как обычный текст, а не сломают запрос к базе.
  • Повторное действие: два быстрых клика по кнопке «Зарегистрироваться» — ожидаем ровно один созданный аккаунт, а не два и не ошибку сервера.

Ни одно из этих шести негативных ожиданий не написано в требовании прямо. Тестировщик формулирует их сам — из знания, как обычно ведут себя реальные пользователи и реальные сети.

Итог:
— позитивная проверка подтверждает, что задуманное сценарии работает;
— негативная проверка ищет то, что требование не упомянуло;
— семь категорий (пусто, границы длины, тип, формат, спецсимволы, прерывание/повтор, доступ без прав) — систематический способ находить негативные сценарии для любого поля или действия.

Контрольный вопрос. Пользователь ввёл в форму регистрации ровно то, что описано в требовании: корректный email и пароль из 8 символов. Это проверка:

АПозитивная
БНегативная
ВНи та, ни другая — это не тест

Подсказка: Сравни сценарий с требованием: он идёт по ожидаемому пути или нарушает условие?

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Какой из вариантов — негативная проверка поля «Возраст», в которое по требованию нужно ввести число от 18 до 99?

АВвести 45
БВвести 18
ВВвести «сорок пять»

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

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Поле «Пароль» по требованию должно принимать от 8 до 20 символов. Какие из проверок — негативные (выбери все подходящие)?

Выберите все верные варианты.

АПароль из 12 символов
БПароль из 3 символов
ВПароль из 500 символов
ГПустое поле пароля

Подсказка: Негативная проверка выходит за рамки того, что требование считает корректным вводом.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Как называется проверка, при которой мы намеренно вводим данные, не предусмотренные требованием, чтобы увидеть реакцию системы? Ответь одним словом.

Подсказка: Слово из этого урока, противоположное слову «позитивная».

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Пользователь дважды быстро нажал кнопку «Оплатить», пока первый запрос ещё обрабатывался сервером. К какой из семи категорий негативных проверок это относится? Впиши название категории так, как оно дано в уроке (два-три слова).

Подсказка: Категория про действие, которое повторили прежде, чем завершилось первое.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. На нашем учебном полигоне есть поле «Номер телефона» с требованием «10 цифр без кода страны». Тестировщик вводит в это поле букву «А» вместо цифры. К какой из семи категорий относится эта проверка? Ответь одним-двумя словами, как в уроке.

Подсказка: Речь про несоответствие ожидаемому виду данных: не число, а буква.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. Требование: «Поле «Название курса» в каталоге принимает текст до 100 символов». Тестировщик вводит в это поле ровно 250 символов. К какой из категорий негативных проверок из урока относится эта проверка? Ответь одним словом.

Подсказка: 250 символов — это всё ещё текст, просто длиннее ожидаемого.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. На полигоне есть поле «Промокод» в форме оплаты курса. Требование: «пользователь вводит код из 6 латинских букв и цифр, система применяет скидку». Придумай пять негативных проверок для этого поля — по одной на разные категории из урока (не повторяй одну категорию дважды). Для каждой укажи: что вводим и какой реакции системы ожидаем. Формат ответа — нумерованный список из 5 пунктов.

Принято, если: (1) указана пустая проверка (поле не заполнено); (2) указана проверка на длину короче или длиннее 6 символов; (3) указана проверка с недопустимыми символами (кириллица, спецсимволы, пробел); (4) указана проверка на повторное применение уже использованного или неверного кода; (5) для каждого пункта названо ожидание системы (отказ с понятной ошибкой, а не аварийное поведение).

Требование: поле «Промокод», ровно 6 символов (латиница + цифры), скидка применяется при совпадении с активным кодом в базе.

Подсказка: Вспомни список из семи категорий и возьми пять разных, подходящих именно этому полю.

✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.

Онлайн-проверка ответа появится позже

Задание. Требование на форму записи на курс: «пользователь выбирает дату начала из календаря, дата не может быть раньше сегодняшнего дня». Тестировщик вводит в поле даты значение вручную через адресную строку API, минуя календарь, и ставит дату на год в прошлом. К какой из семи категорий негативных проверок из урока относится эта проверка? Ответь двумя-тремя словами, как в уроке.

Подсказка: Обрати внимание не на саму дату, а на способ её ввода — в обход интерфейса, который и должен был не пустить прошедшую дату.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. В форме входа в личный кабинет требование говорит: «email и пароль обязательны для заполнения». Тестировщик оставляет оба поля пустыми и нажимает «Войти». К какой категории относится эта проверка? Ответь одним словом.

Подсказка: Оба поля остались незаполненными.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Почему негативные проверки в среднем находят больше багов, чем позитивные?

АПотому что негативных проверок можно придумать больше по количеству
БПотому что счастливый путь уже проверялся разработчиком при написании кода, а нестандартные случаи — нет
ВПотому что негативные проверки проще технически выполнить

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

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Что дальше

Семь категорий дают направление поиска, но не подсказывают, какие именно значения внутри категории брать: если поле принимает числа от 18 до 99, с какого именно неверного числа начинать проверку? В следующем уроке разберём классы эквивалентности — способ сократить бесконечное множество возможных значений до нескольких представителей, ничего важного не упустив.

Назад  ·  ↑ В начало урока  ·  ⌂ В начало курса  ·  Вперёд →

Школа Виктора Комлева