Что выступает клиентом, а что сервером

Что проверяют

Понимаете ли вы, что клиент и сервер это роли в конкретном обмене, а не типы устройств. Для тестировщика от этого зависит, куда ставить заглушку, чьи логи открывать и на чьей стороне заводить дефект.

Как отвечать

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

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

Отсюда практический вывод для тестирования: ограничения на клиенте это удобство пользователя, а не защита. Любой клиент подменяется, значит проверки обязаны дублироваться на сервере, и в чек-лист входит отправка запроса напрямую, мимо интерфейса.

Где спотыкаются

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

Считают, что запрос всегда начинает клиент. Есть вебхуки, где внешняя система стучится к нам и мы для неё сервер, есть вебсокеты и пуш-уведомления, где после установки соединения сообщения идут в обе стороны. Баг «не пришло уведомление» из-за этого ищут не в том звене.

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