Негативные тесты для чайников

Что такое негативные проверки в тестировании? Это такие действия по отношению к продукту со стороны пользователя, которые не были предусмотрены изначально. Например, калькулятор ожидает от юзера ввода чисел, а не букв. Ввод в него букв будет негативным тестированием.

В идеале к негативным проверкам тестировщики переходят уже после позитивных. 

Простейший пример: форма регистрации. Если мы вводим корректные данные и нажимаем кнопку «отправить», те должны успешно передаваться на сервер. Такая проверка называется позитивной. 

А противоположной этому будет негативная проверка: к примеру, ввод в поле регистрации некорректного е-мэйл адреса типа ivanov#mail.ry. 

Ожидаемых результатов в негативном тестировании может быть несколько:

  1. Fail — этот результат мы получаем, когда система не знает, как реагировать на неожиданный поворот событий. Разработчики не добавили в продукт ответна негативный тест.
  2. Success — разработчики заложили реакцию на негативный тест. Например, всплывающее окно-предупреждение о некорректно заполненной форме. В таком случае мы будем ожидать появления окна после негативной проверки.

Еще немного о негативном тестировании из нашей преподавательской практики.

Одному студенту была не понятна разница между багом и негативным тестом в нашем тренажере-калькуляторе.  Для обучения начинающих тестировщиков мы используем собственноручно написанный кредитный калькулятор. В него для расчета кредита по условиям можно ввести сумму не менее 100 000 рублей. 

Ввод в калькулятор меньшей суммы (например, 99 000) считается негативным тестом, а вот то, что калькулятор продолжает работать при таких условиях — уже баг. 

Иногда в начале обучения бывает сложно уловить эту тонкую грань: где — еще тест, а где — уже баг.

Вот как объяснил это наш эксперт, тренер и автор вебинаров курса ПОИНТ Игорь Савченко:

«Этап тестирования и этап написания тестов —  это два разных этапа.

Представьте, что у вас еще нет продукта. Вы только увидели информацию о нем, и ваша задача — написать негативные проверки. Вы еще не знаете, как выглядит продукт, как он себя ведет. Вы опираетесь на ТЗ и здравый смысл.

Сейчас вы опираетесь на то, что уже «щупали» продукт (калькулятор) и знаете, как он себя ведет. Это этап тестирования.

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

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


К выяснению фундаментальной разницы подключились и остальные ученики:

Кстати, иногда очень полезно сравнить QA-термины с более понятными вещами! Воспринимать новое тогда становится заметно легче.

Пример с шарлоткой крут! Можно немного его расширить: если по рецепту в яблочный пирог входят яйца, мука, сахар и яблоки, а мы вместо сахара добавили перец, это негативная проверка. Если при этом пирог не в курсе, что его поперчили, и продолжает быть сладким, это баг!

А вы бы хотели научиться тестированию ПО в команде с неравнодушными сокурсниками и тренерами, которые всегда поддержат, ответят, объяснят и «на пальцах», и серьезно? Присоединяйтесь к экспресс-курсу для новичков Jedi Point. Старт 24 апреля!