Вольный перевод фрагмента из книги Дж. Уиттакера "Exploratory testing" с примерами из личной практики
Входные данные (далее - ВД) можно определить следующим образом: это стимул, который исходит из внешней среды и вынуждает приложение реагировать определенным образом.
Для тестирования ВД мы используем позитивные и негативные тесты. И если с первыми все более-менее понятно, то со вторыми возникает вопрос: что именно подразумевать под некорректным вводом?
В любом ПО некорректный ввод - это то, что разработчик (аналитик, архитектор, etc.) определил как некорректный ввод.
Разработчики создают код, который обрабатывает ошибки и сообщает о них пользователю. Но, в зависимости от различных обстоятельств, такой код может быть либо написан на скорую руку, либо не реализован вовсе. Об этом никогда не стоит забывать при тестировании ВД.
Чаще всего используется 3 механизма определения обработчиков ошибок: фильтры, проверки и исключения.
Фильтры - это механизмы, которые предотвращают некорректный ВД. Если ВД достигает кода приложения, то он трактуется как разрешенный, и никаких других проверок не производится. Например, если в поле предусмотрен только ввод целочисленных значений, то сколько бы пользователь ни нажимал на буквы или символы, поле будет оставаться пустым и принимать только цифры. Выбор из списка - вариант фильтра, который позволяет выбрать только валидные значения.
С точки зрения тестирования, в фильтрах проверяется следующее:
1. Нет ли ошибок в реализации фильтра, вызванных человеческим фактором (неточное ТЗ, неверная трактовка с точки зрения разработчика и т.д.) Если разработчик неправильно отделил множество корректных значений от множества некорректных, это может вызвать серьезный баг. С одной стороны, невалидное значение может попасть в код приложения. С другой стороны, у пользователь может столкнуться с тем, что не сможет ввести валидные данные.
Один из примеров моей практики - валидация номера телефона, который вводит оператор, оформляя обращение клиента. Изначально приложение создавалось для России, и при вводе номера телефона первый символ обязательно должен был быть 7. После того, как в компании появились клиенты из других стран, у них возникли серьезные проблемы.
2. Можно ли обойти фильтр? Копипаст - самый распространенный вариант, как обойти фильтр.
Проверки ввода
Проверки ВД - часть кода программы и представлены структурами If / Then / Else (Case, Select и т.д.). Они принимают ввод, и ЕСЛИ он валидный, ТО выполняется процедура, ИНАЧЕ появляется сообщение об ошибке и исполнение кода прекращается. Здесь особенно важно проверить граничные значения, поскольку есть вероятность ошибки кода (закодили < вместо <=).
При такой реализации пользователь обязательно должен получать сообщение об ошибке. Они обычно указывают, почему ВД невалидный и как это исправить. В свою очередь, сообщения об ошибках - ключ к исследовательскому тестированию. Можно проверять различные ВД и устанавливать, насколько сообщения понятны и описывают ли они именно ту ошибку, которую допустил пользователь.
Обработчики исключений
Обработки исключений похожи на проверки ввода, но они не проверяют каждый ВД, а проверяют нечто ставшее причиной отказа целой процедуры.
Это значит, что сообщение об ошибке, обработанное таким образом, будет более обобщенное. Т.к. ошибка могла произойти где угодно, сложно сообщить больше чем "произошла ошибка", т.к. код обработчика не может определить, где именно возникла проблема.
Стандартные или нестандартные ВД?
Под стандартными ВД можно понимать те, которые не имеют экстраординарного формата или значения, и могут быть спокойно переварены ПО. Стандартные ВД - это те, которые ожидаются разработчиками и те, что обычно используют пользователи.
Нестандартные ВД - это все остальное. К ним можно отнести все комбинации с клавишами Ctrl, Alt, Esc, попытки ввести в поле скрипт и т.д.
Из личной жизни: пользователь заходил на сайт со смартфона и сохранял в полях анкеты смайлики, поскольку клавиатура смартфона позволяла это сделать. Не спрашивайте, что потом видел тот же пользователь, открывая свою анкету с компьютера.