Негативные тесты для чайников
Что такое негативные проверки в тестировании? Это такие действия по отношению к продукту со стороны пользователя, которые не были предусмотрены изначально. Например, калькулятор ожидает от юзера ввода чисел, а не букв. Ввод в него букв будет негативным тестированием.
В идеале к негативным проверкам тестировщики переходят уже после позитивных.
Простейший пример: форма регистрации. Если мы вводим корректные данные и нажимаем кнопку «отправить», те должны успешно передаваться на сервер. Такая проверка называется позитивной.
А противоположной этому будет негативная проверка: к примеру, ввод в поле регистрации некорректного е-мэйл адреса типа ivanov#mail.ry.
Ожидаемых результатов в негативном тестировании может быть несколько:
- Fail — этот результат мы получаем, когда система не знает, как реагировать на неожиданный поворот событий. Разработчики не добавили в продукт ответна негативный тест.
- Success — разработчики заложили реакцию на негативный тест. Например, всплывающее окно-предупреждение о некорректно заполненной форме. В таком случае мы будем ожидать появления окна после негативной проверки.
Еще немного о негативном тестировании из нашей преподавательской практики.
Одному студенту была не понятна разница между багом и негативным тестом в нашем тренажере-калькуляторе. Для обучения начинающих тестировщиков мы используем собственноручно написанный кредитный калькулятор. В него для расчета кредита по условиям можно ввести сумму не менее 100 000 рублей.
Ввод в калькулятор меньшей суммы (например, 99 000) считается негативным тестом, а вот то, что калькулятор продолжает работать при таких условиях — уже баг.
Иногда в начале обучения бывает сложно уловить эту тонкую грань: где — еще тест, а где — уже баг.
Вот как объяснил это наш эксперт, тренер и автор вебинаров курса ПОИНТ Игорь Савченко:
«Этап тестирования и этап написания тестов — это два разных этапа.
Представьте, что у вас еще нет продукта. Вы только увидели информацию о нем, и ваша задача — написать негативные проверки. Вы еще не знаете, как выглядит продукт, как он себя ведет. Вы опираетесь на ТЗ и здравый смысл.
Сейчас вы опираетесь на то, что уже «щупали» продукт (калькулятор) и знаете, как он себя ведет. Это этап тестирования.
А написание тестов идет до этапа тестирования, то есть логично, что мы составляем тесты на основании знаний о продукте, но не привязываем к ним фактическое поведение.
Фактическое поведение мы узнаем уже после, когда будем тестировать продукт на основании тех тестов, которые спроектировали ранее».
К выяснению фундаментальной разницы подключились и остальные ученики:
Кстати, иногда очень полезно сравнить QA-термины с более понятными вещами! Воспринимать новое тогда становится заметно легче.
Пример с шарлоткой крут! Можно немного его расширить: если по рецепту в яблочный пирог входят яйца, мука, сахар и яблоки, а мы вместо сахара добавили перец, это негативная проверка. Если при этом пирог не в курсе, что его поперчили, и продолжает быть сладким, это баг!
А вы бы хотели научиться тестированию ПО в команде с неравнодушными сокурсниками и тренерами, которые всегда поддержат, ответят, объяснят и «на пальцах», и серьезно? Присоединяйтесь к экспресс-курсу для новичков Jedi Point. Старт 24 апреля!