Негативные тест кейсы используются для проверки работоспособности приложения при условии поступления на его вход «неправильных» данных. Такие тест кейсы должны обязательно использоваться в ходе тестирования. Ниже приведены десять самых популярных негативных тестовых сценариев:

Внутренние одинарные кавычки (Embedded Single Quote) – У большинства SQL баз данных возникают проблемы при наличии одинарных кавычек в запросе (например, Jones’s car).
Используйте одинарные кавычки при проверке каждого поля ввода работающего с базой данных.

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

Типы данных полей (Field Type Test) – В спецификации вашего приложения должны быть четко определены типы данных для каждого из полей (поля даты/времени, числовые поля, поля для ввода номера телефона или почтового кода и т.д.)
Проверяйте, что каждое из полей позволяет вводить или сохранять данные только определенного спецификацией типа (например, приложение не должно позволять вводить или сохранять буквы или специальные символы в числовых полях).

Размер поля (Field Size Test) – В спецификации вашего приложения должно быть четко определено максимально допустимое количество символов в каждом из полей (например, количество символов в поле с именем пользователя не должно привышать 50).
Проверяйте, что приложение не позволяет вводить или сохранять большее количество символов, нежели указано в спецификации. Не забывайте и о том, что данные поля, не только должны правильно функционировать, но и предупреждать пользователя об ограничениях, например, с помощью пояснительных надписей или сообщений об ошибках.

Числовые граничные значения (Numeric Bounds Test) – Числовые поля вашего приложения могут иметь ограничения допустимых числовых значений. Эти ограничения могут быть указаны в спецификации вашего приложения либо вытекать из логики работы программы (например, если вы тестируете функциональность связанную с начислением процентов на счет, то вполне логичным будет предположение, что начисленные проценты не могут принимать отрицательное значение).
Проверяйте, что приложение выдает сообщение об ошибке в случае, если значения лежат за пределами допустимого диапазона (например, сообщение об ошибке должно появляться при вводе значений 9 или 51 в поле с допустимым диапазоном значений от 10 до 50, либо при вводе отрицательного значения в поле, значения которого должны быть положительными).

Числовые ограничения (Numeric Limits Test) – Большинство баз данных и языков программирования определяют числовые значения как переменные с некоторым типом (например, integer или long integer), которые, в свою очередь, имеют ограничения допустимых числовых значений (например, значения integer должны находиться в диапазоне от -32768 до 32767, а long integer от -2147483648 до 2147483647).
Проверяйте граничные значения используемых переменных, для числовых полей, граничные значения которых четко не определены спецификацией.

Граничные значения даты (Date Bounds Test) – Очень часто в приложениях существуют логические ограничения для полей содержащих дату и время. Например, если вы проверяете поле содержащее дату рождения пользователя, то вполне логичным будет запрет ввода еще не наступившей даты (т.е. даты в будущем), либо ограничение на ввод даты отличающейся от сегодняшней более, чем на 150 лет.

Валидность даты (Date Validity) – Поля даты всегда должны иметь проверку валидности введенных значений (например, 31-10-2009 – не валидная дата). Также, не забывайте и о проверке дат в високосном году (годы кратные 4м и кратные 100 и 400 одновременно - високосные).

Веб сессии (Web Session Testing) – Множество веб приложений используют браузерные сессии для отслеживания пользователей вошедших в систему, применения специфических настроек приложения для конкретного пользователя и т.д. При этом, многие функциональные части системы не могут или не должны работать без предварительного входа в систему. Проверяйте, что функциональность или страницы, находящиеся за паролем, недоступны пользователю не прошедшему авторизацию.

Изменения производительности (Performance Changes) – Для каждой новой версии продукта проводите ряд тестов производительности (например, скорость добавления, удаления или изменения различных элементов на странице). Сравнивайте результаты с тестами производительности предыдущих версий продукта. Подобная практика позволит вам заранее выявить потенциальные проблемы производительности, вызванные изменениями кода в новых версиях продукта.