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

По сути, предугадывание ошибки в широком смысле – это все, что делает тестировщик при составлении тестовых сценариев. Это словосочетание можно использовать для описания абсолютно всех техник тест-дизайна. Ведь основная цель этого процесса и состоит в том, чтобы определить, в каком месте и при каких обстоятельствах с наибольшей вероятностью может возникнуть ошибка, а также проверить это в процессе тестирования. Для тестировщика данный навык может стать отличным подспорьем в работе. Чтобы использовать предугадывание ошибки в тестировании, совсем необязательно иметь опыт разработки ПО. Важно понимать базовую логику написания кода и разбираться в требованиях, которые будут предъявляться к конечному продукту. Далеко не лишним будет и опыт в тестировании похожих проектов. Если же нет такого опыта – как вариант, можно воспользоваться помощью коллег, которые успешно применяют эту технику в повседневной работе. Но лучше всего, в таком случае, сконцентрироваться на других, более осязаемых техниках составления тест-кейсов, которые позволят получить более надежный результат.

Предугадывание ошибки как техника тест-дизайна

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

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

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

К преимуществам этого метода можно отнести:

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

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

Применение метода на реальных проектах

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

Сортировка. Тестируя эту функцию, необходимо учитывать распространенную ошибку среди разработчиков, когда числа «10», «11», «12» и так далее до числа «19» оказываются между числами «1» и «2». Таким образом, массив выводится в таком виде:
1
10
11
12
...
19
2
20
Поэтому при тестировании подобных массивов не стоит ограничивать диапазон вводимых данных одним десятком.

Продолжая тему массивов, можно упомянуть о сортировке размеров при тестировании интернет-магазинов. Здесь достаточно часто встречается ошибка, при которой сортировка универсальных размеров происходит по алфавиту:
L, M, S, XL, …
Тогда как правильно выстроить в порядке увеличения размера:
XXS, XS, S, M, L, XL, …

«У меня в браузере все работает». Как правило, в связи с нехваткой времени, разработчики используют для тестирования своих продуктов только один браузер. Далеко не всегда его версия совпадает с той, которая является приоритетной на проекте. Также разработка часто происходит на MacOS, где стандартом считается браузер Safari, а обновления Chrome выходят с небольшим запозданием. Из-за этого также могут возникать ошибки, так как разные браузеры могут иначе обрабатывать один и тот же код. Решение простое – уточнить приоритетность каждого браузера и выполнить тест-кейсы для каждого из них. Полезно тестировать сайт на нескольких браузерах одновременно – так будет проще заметить отличия в поведении.

Игнорирование обработки некорректных входных данных. Нередки случаи, когда разработчики намеренно не тратят время на продумывание и внедрение состояний, которые, по их мнению, невозможны. Но нужно учитывать, что продуктом будут пользоваться люди с самым разным мышлением, и они могут вводить в систему самые разные данные, которые будут некорректно обрабатываться. В этом случае задача тестировщика – предусмотреть все возможные варианты поведения пользователя и проверить их.
Например: в Украине номера телефонов мобильных операторов состоят из 12 символов, поэтому разработчик ограничивает длину поля для ввода телефона до 12. Но если поле не содержит предварительной разметки (черточек и скобок), то пользователь может вводить номер телефона самыми разными способами:

• 380yyxxxxxxx: этот вариант будет принят системой, так как был предусмотрен разработчиком;
• +380yyxxxxxxx: из-за символа «+» номер не пройдет валидацию, так как длина поля превышает ожидаемую;
• 380 yy xxxxxxx: если поле считает пробелы как отдельные символы – здесь уже 14 символов, а не 12;
• 380-yy-xxxxxxx/380(99)xxxxxxx: ситуация аналогична с описанной выше.

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