Любой тестер, будь то мануальный или автоматизатор, постоянно задумывается о так называемом «счастливом пути» – идеальный тестовый сценарий, которым конечный пользователь 100% воспользуется при взаимодействии с предлагаемым ему ПО.

Работая над автоматизацией проверок, тестировщики надеятся, что все UI-проверки будут автоматизированы, а при проверке API – каждая точка вернет значение «200 ОК» или другой успешный ответ.

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

Любые автоматизированные тесты могут выполняться по неправильным причинам

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

Пример: если группа автоматизированных UI-тестов на базе JavaScript. Проверки выполняются успешно, но только по одному заданному сценарию. А вот если попробовать «завалить» тесты, то на выходе получаются совершенно иные результаты.

Очень важно в такой ситуации проверять не только то, что тесты могут «упасть», но еще и [highlight dark=”no”]достоверность[/highlight] такого «падения». При таком подходе будет ясно, что вы проверяете то, что изначально планировалось протестировать.

Негативная проверка может найти неверную обработку ошибок

Например, во время тестирования API любая пользовательская ошибка должна возвращать ответы уровня 400, но никак не 500. Если в процессе негативного тестирования ошибки уровня 403 отображаются как 500, можно с твердостью судить о том, что программный код перестал корректно справляться с запрограммированным сценарием использования.

Получение ответа 500 со стороны сервера может помешать клиенту получить данные, которые требуются ему для исправления ошибки – или, что еще страшнее, приложение банально может «лечь».

Сравнение позитивного и негативного тестирования

С помощью негативного тестирования можно отыскать потенциальные уязвимости безопасности

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

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

Негативное тестирование сохраняет чистоту БД

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

Чем больше негативного тестирования будет проведено для ввода, тем больше будет уверенность в ответственного тестера в том, что данные полностью валидны и корректные.

Порой пользователи непринужденно выполняют негативное тестирование

Очень просто – особенно в процессе своеобразной гонки проверки новой фичи, чтобы успеть к намеченному сроку дедлайна – совершенно забыть выполнить проверку пользовательских сценариев, при которых пользователь кликает на кнопки отмены и удаления (например, форм обратной связи). Но люди делают такие вещи постоянно – ведь нередки ситуации, когда вы что-то оформили на покупку в онлайн магазине, добавили товар в корзину, а потом передумали и всё удалили.

В общем, процесс тестирования – это постоянный поиск неожиданного поведения системы с целью найти больше багов, чем это может сделать пользователь ПО. Когда на проектах процедура негативного тестирования идет вместе со сценариями счастливого пути, можно на 100% удостоверится, что клиент в будущем не столкнётся с непредвиденными сюрпризами.