Ты уже знаешь, что тестирование абсолютно необходимо для обеспечения качества софта, и умеешь писать простые тесты. Существует классификация тестов, по которой все они делятся на две категории: позитивные и негативные. Обе категории одинаково важны, но позитивное тестирование всегда было более распространенным, и на то есть причины.
Ознакомившись с методологией негативного тестирования, ты узнаешь, почему QA избегают негативных тестов, и узнаешь чего от них ожидать, поймешь, чем хороши негативные тесты.
- Что такое негативное тестирование
- Почему тестировщики его не любят
- Техники негативного тестирования
- Сценарии
- Разница между позитивным и негативным тестированием
- Преимущества и недостатки негативного тестирования
Итак, что такое негативное тестирование
Тестирование в целом — это проверка, работает ли софт должным образом, соответствует ли требованиям заказчика; как софт выдерживает челенджи и нестандартные ситуации.
Негативное тестирование олицетворяет “негативный подход” к тестированию. Его можно назвать “тестированием на сбой” или “тестированием на пути ошибок”. Его цель — найти негативные стороны приложения, путем написания специфического тест-кейса; другими словами, все крутится вокруг того как приложение реагирует на некорректные данные, и в таком подходе есть смысл, как будет видно далее.
Почему тестировщики не любят негативное тестирование
Несмотря на то, что подход имеет преимущества, такое тестирование не взыскало популярности у тестировщиков. Они избегают его, потому что считают, что другие методы позволяют добиться лучших результатов — и быстрее. А скорость разработки сейчас крайне важна.
Некоторые тестировщики вообще смотрят на этот подход как на бесполезную трату времени и денег. И действуют только в рамках позитивного тестирования.
Недостаточность скиллов и знаний о преимуществах такого подхода мешает им применять его. А правда в том, что негативное тестирование, если хорошо организовано, ведет к высокому качеству софта, при малых усилиях. Такое тестирование по возможности должно внедряться в процессы в QA-отделе, потому что оно:
- Повышает ответственность в команде
Команда становится ответственной, давая клиентам хорошо проверенный софт. Негативное тестирование, в качестве дополнения к позитивному, как будет понятно ниже, бывает незаменимо в повышении стабильности приложения. Как ты уже хорошо знаешь, невозможно полностью избежать ошибок, но вполне возможно минимизировать их, и негативное тестирование — путь к этому, достаточно прямой, и достаточно короткий.
- Клиенты довольны
Как ни банально звучит, негативное тестирование повысит конечное качество софта, что скажется на customer satisfaction. Особенно это будет заметно в кейсах онлайн-магазинов и вообще е-коммерции.
Негативное тестирование это вещь, в которую можно и нужно инвестировать, невзирая на возросшие расходы.
Техники негативного тестирования
Далее приведены техники, применяемые при негативном тестировании.
- Анализ граничных значений
Метод подразумевает написание тест-кейсов в стандартном для тестировщиков виде: проверка значений, выходящих за пределы, например для поля со значениями от 1 до 100.
- Разделения по классам эквивалентности
Метод проверки функциональности, путем группирования тестовых значений по нескольким “классам эквивалентности”.
- Угадывание ошибок
В ходе процедуры тестировщик задает специальные условия, выдающие сообщения об ошибке. Если возможно, тестировщик пытается идентифицировать и исправить проблему не допуская падения приложения.
- Чеклисты
Базовый, и все еще критически важный метод в QA, документирующий условия, в которых проводится тестирования. Обычно применяется в работе в команде.
- Антипаттерны
Если есть паттерны дизайна, то могут быть и антипаттерны. Если паттерн — лучший способ решить проблему, то антипаттерн — решение которое точно не работает. Антипаттерны — идеальный источник негативных тестов.
- Исследовательское тестирование
Метод, повышающий скиллы тестировщика, и его понимание приложения, в процессе работы. Применяется параллельно с другими тестами. Делает «общую картину» приложения яснее — в каких условиях приложение работает, в каких нет.
- Небольшая автоматизация
Отлавливаются ошибки с памятью, грубые ошибки в коде, и другие проблемы, потом неожиданно возникающие на проде. Несколько сотен или тысяч раз проводится прогонка, чтобы посмотреть, что происходит с приложением.
Ввод случайных данных, которые могут вызвать неожиданные сбои, крэши системы, и другие ошибки. В этом методе нет “ожидаемых результатов” (в отличие от других негативных тест-кейсов). Грубо говоря, это просто наблюдение, а что случится, когда подаются какие-то произвольные данные.
- Тестирование перехода состояний
Техника поиска багов, построенная на концепции, что софт в момент времени должен пребывать в одном конкретном состоянии. Приложение должно быть в своем нормальном состоянии, пока не появится проблема.
Сценарии
Далее потенциальные ситуации, когда случаются (могут случиться) ошибки и крэши:
- Сбор данных из обязательных полей
Есть много софта, и веб-страниц, в которых самой важной частью являются поля ввода, заполняемые пользователем. При негативном тестировании пишутся тесты, оставляющие обязательные поля пустыми.
- Несооответствие между типом данных и типом поля
Большинство форм и диалогов способны получать данные в определенной форме; самые частые это текст, число, дата и время. Пишется тест-кейс, в котором в поле вводятся данные другого типа, и проверяется реакция приложения.
- Допустимые границы и лимиты
В большинстве приложений в полях ввода принимаются только данные в заданном диапазоне, или текст определенного формата. Пишутся тесты, в которых вводятся значения выше или ниже диапазона.
- Разрешенное количество символов
Есть страницы и приложения, поля ввода в которых принимают лишь определенное количество символов. В негативном тесте вводится запрос с бОльшим количеством символов.
- Тестирование сессий
В некоторых браузерах для входа на некую страницу требуется ввести сначала логин пользователя. Пишется тест, пытающийся открыть страницу без логина.
- Специфические данные
Существуют приложения и страницы с полями ввода, принимающими данные со специфическими ограничениями. Негативный тест проверяет некорректные данные вне этих ограничений.
Разница между позитивным и негативным тестированием
“Позитивное тестирование должно проверить, что приложение нормально работает в нормальных условиях. Негативное — в ненормальных”.
| Позитивное тестирование | Негативное тестирование |
| Предполагается, что софт будет работать в стандартных условиях | Предполагается, что софт будет работать в сложных условиях |
| Считается, что софт не будет испытывать проблем в стандартных условиях | Считается, что при малейшем отклонении от идеальных условий будут сбои в приложении |
| Считается, что пользователь будет вводить только корректные данные | Считается, что пользователь может и будет вводить некорректные данные |
Преимущества негативного тестирования
- Проявляет некорректную обработку ошибок
Позволяет избежать сбоев, вызванных неправильной обработкой ошибок.
- Идентифицирует слабые места в безопасности
Негативное тестирование позволяет гарантировать, что например клиент не получит персональный аккаунт в приложении с уровнем допуска, не предусмотренным его организацией.
- Поддерживает «чистоту баз данных»
Базы данных будут в отличном состоянии, если в них только корректные данные. Негативное тестирование (почти) гарантирует, что там хранятся только корректные данные.
Недостатки
Негативное тестирование может занимать много времени, и бывает достаточно дорогим процессом.
