Очень просто. Представьте, что вы обычный пользователь вашего будущего сервиса и проведите так называемое юзабилити-тестирование.

Включаете, смотрите, как это выглядит и как работает. Проверяете, соответствует ли входная и выходная точки заявленному действию, соответствует ли вашим ожиданиям.

Кстати, очень часто, главной проблемой не соответствия ожиданиям является не некомпетентность разработчика, а некорректно или неполно сформулированная задача.

В процессе такого поэтапного тестирования бонусом вырабатывается близкое понимание между разработчиком и заказчиком. Уже через пару таких тестов, вы, как заказчик, поймете, как лучше объяснить свои пожелания, а разработчик точнее сможет понять, что вы имели в виду.

Дать задачу, понятную к выполнению (корректные входные-выходные данные) — уже половина успеха!

Рассмотрим пример.

По итогам спринта необходимо было реализовать на сайте корзину.

Задачи на выходе: возможность просмотреть список покупок, добавленных в корзину, отредактировать его, добавить новые товаров, удалить имеющиеся, создать лист ожидания.

Можете ли вы, как пользователь, протестировать функционал и объяснить, что хотели бы изменить? Конечно!

Другой пример.

Бот для регистрации водителей в Я.Такси

Вход – ФИО, город, водительские права.

Выход – оформленные по стандарту регистрационные данные водителя и правильное распределение нужному куратору в нужный город.

Обратите внимание! Ответ по результатам тестирования должен быть развернутый, а не просто – все, ничего не работает, я не это имел в виду. Это не конструктивно.

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