Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Мы, как тестировщики и автоматизаторы, часто обдумываем "Счастливый путь" – сценарий, которым пользователь с наибольшей вероятностью воспользуется в нашем приложении. Создавая автоматизированные UI-тесты, мы стремимся убедиться, что эти сценарии автоматизированы, а автоматизируя API, хотим проверить, что каждая конечная точка вернет "200 ОК" или схожий успешный ответ.

Однако о негативном тестировании тоже важно думать – как при ручном, так и при автоматизированном тестировании, и вот почему:

Наши автоматизированные тесты могут проходить по неправильным причинам

Когда я только начинала писать автоматизированные UI-тесты на JavaScript, я не понимала концепцию контейнеров. Я просто предполагала, что если я запрашиваю нахождение элемента, то элемент не будет возвращен, пока не будет найден. Я была так рада, когда мои тесты начали проходить с зеленым "успешным" результатом, пока коллега не предложил попробовать заставить тест упасть, задав ему другое утверждение для проверки. Тест снова прошел, потому что просто удостоверялся в существовании контейнера, а оно всегда возвращалось как истина. Я получила ценный урок – никогда нельзя предполагать, что автотесты правильно работают только потому, что они успешно проходят. Убедитесь, что вы проверили сценарии, при которых ваши тесты обязаны упасть, и проверьте, что они действительно падают. В этом случае вы удостоверитесь, что действительно тестируете то, что планировали протестировать.

Негативное тестирование может выявить неправильную обработку ошибок, которая может повлиять на пользователя

При тестировании API любая клиентская ошибка должна возвращать ответ уровня 400, а не 500. Если в ходе негативного тестирования ошибки 403 теперь приходят как 500, это может означать, что код перестал правильно справляться с таким сценарием использования. Ответ 500 от сервера может помешать пользователю получить информацию, которая нужна ему для исправления ошибки – или, что еще хуже, приложение может упасть.

Негативное тестирование может выявить уязвимости безопасности

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

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

Негативное тестирование хранит чистоту базы данных

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

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

Иногда пользователи идут по негативному сценарию

Очень легко – особенно в гонке тестирования новой фичи, дабы успеть к дедлайну – забыть проверить пользовательские сценарии, при которых пользователь нажимает на кнопки отмены или удаления. Однако люди делают это постоянно – подумайте о ситуациях, когда вы хотели что-то заказать онлайн, а затем передумали и удалили товар из корзины. Представьте свое раздражение, если он не удалится, или если кнопка отмены не очистит форму, чтобы дать вам возможность начать заново. Пользовательский опыт в этой области не менее важен, чем при "счастливом пути".

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

Обсудить в форуме