Примеры всегда тестируем!

Всегда проверяйте примеры. Просто ВСЕГДА!

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

И если этот пример не работает — вот где эпик фейл. Зачем работать с системой, если она на собственных данных обламывается? Так что примеры тестируем в обязательном порядке.

Но давайте разберемся, где эти самые примеры искать. Что к ним относится? Пройдемся по основным типам. 

Файл-образец

Возьмем для примера Дадату. Туда можно грузить файлики, и система «причешет» данные внутри. Как вы будете проверять, подойдет ли вам Дадата?

1. Возьмете свой файлик и попробуете сразу на нем.
2. Возьмете пример из системы.

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

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

• Скачивается (вдруг ссылка побилась??)
• Обрабатывается без ошибок, выдаёт правильный результат.

Предзаполненные поля в форме ввода

Что, если у нас просто форма ввода? И туда можно добавить пример! Вот как в Дадате сделано:

 

Все поля заполнены по умолчанию. Можно просто ткнуть на кнопку «Проверить» и посмотреть результат. А потом уже обрабатывать свои данные. И поверьте, большинство просто ткнет в кнопку для начала, просто потому, что так проще. Значит, это должно работать. Значит, нам надо этот пример проверять!

Примеры вызова API-методов

Что может быть приятнее, чем скопировать пример и отлаживаться на нем? То есть сначала послали «запрос, который 100% работает», а потом уже варьируем под свои данные.

Это очень важно для интеграции. Вы ведь пытаетесь соединить свою систему с чужой. Чужую вы почти не знаете, как она работает? Спасает только наличие ТЗ. 

Но что, если требований тааааак много и они довольно сложные, а интегрировать уже пора начинать? Сначала стоит выполнить простейший сценарий. А где его взять? Конечно, из примера! Выполняем пример вручную. Работает? Тогда пишем вызов уже из кода. Написали? Теперь уже сидим и вчитываемся подробнее, разбирая всякие альтернативные сценарии.

Именно поэтому примеры очень важны. С них начинают работу с системой.

Другие примеры 

Примеры могут быть в любой документации — лендинг-страница, пригласительное письмо, документация на работу системы... Посмотрите, сколько пунктов в этой статье, и в любом из них могут скрываться примеры! 

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

Итого по примерам

Примеры очень важны. С них начинают работу с системой.

• Если у вас их нет — просите добавить. 
• Если они есть — тестируйте их! 

Если вы делаете внешнее API для заказчика или вообще публичное, опишите его и добавьте примеров. Именно с них пользователь начнет знакомство с методом.

Но и в «простом» интерфейсе есть место для примеров. Можно облегчить пользователям жизнь, подготовив файл-образец или предзаполнив форму ввода. И они обязательно этими примерами воспользуются. Поэтому примеры мы ОБЯЗАТЕЛЬНО тестируем. Всегда. Это — лицо нашего приложения, оно должно работать.

См также:

Какая бывает документация — что еще стоит проверить

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков