Как устроен веб-сайт и из чего он состоит для работы и использования пользователем?
Что проверяют
Понимаете ли вы путь запроса от браузера до базы и обратно настолько, чтобы локализовать баг: во фронтенде он, в API или в данных. Почти всегда следом просят рассказать, что происходит после ввода адреса в строку браузера.
Как отвечать
Опишите слои по ходу запроса и у каждого назовите, что на нём проверяет тестировщик:
- браузер: HTML задаёт структуру, CSS внешний вид, JavaScript поведение. Из разметки строится DOM, по нему идёт отрисовка. Здесь живут вёрстка, кроссбраузерность, адаптив, клиентская валидация форм;
- сеть: DNS превращает домен в IP-адрес, дальше соединение TCP и TLS для HTTPS, затем HTTP-запрос с методом, заголовками и телом. Ответ приходит с кодом: 2xx успех, 3xx редирект, 4xx ошибка клиента, 5xx ошибка сервера;
- входная точка: CDN отдаёт статику, балансировщик или обратный прокси вроде nginx распределяет запросы по серверам;
- бэкенд: приложение на Java, Python, Go или другом языке принимает запрос, проверяет права, выполняет логику и обычно отдаёт JSON через REST API;
- данные: база (PostgreSQL, MySQL), кэш (Redis), очереди для фоновых задач;
- состояние пользователя: куки, сессия или токен,
localStorageв браузере.
Сильный ход: показать, как вы этим пользуетесь. Открываете DevTools, вкладку Network, смотрите запрос и ответ. Если сервер вернул верные данные, а на экране ерунда, баг во фронтенде. Если ответ уже неверный, заводите дефект на бэкенд и прикладываете запрос, например скопированный как cURL.
Где спотыкаются
Ограничиваются тройкой HTML, CSS, JavaScript и молчат про сервер и базу. Для тестировщика это половина картины.
Путают коды ответа: 401 означает, что пользователь не аутентифицирован, а 403, что прав недостаточно. И 404 не всегда баг сервера, иногда фронтенд просто собрал неверный адрес.
Проверяют только интерфейс. Клиентская валидация обходится прямым запросом, поэтому те же ограничения обязан проверять бэкенд, и это тоже надо тестировать.