🟠 возвращать любые статус-коды, заголовки, JSON и задержки ответа
🟠 записывать реальные запросы и воспроизводить их позже (Record & Playback)
🟠 запускаться как отдельный сервер или встраиваться в JUnit/TestNG
🟠 моделировать последовательность событий: первый запрос → 200, второй → 500, третий → 404

docker run -p 8080:8080 wiremock/wiremock

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

SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

SELECT *
FROM orders
WHERE customer_id IS NULL
   OR total_amount IS NULL;

SELECT o.id
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.id IS NULL;

SELECT o.id
FROM orders o
LEFT JOIN order_items oi ON o.id = oi.order_id
WHERE oi.id IS NULL;

SELECT o.id,
       o.total_amount,
       SUM(oi.price * oi.quantity) AS calculated
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
GROUP BY o.id, o.total_amount
HAVING o.total_amount <> SUM(oi.price * oi.quantity);

SELECT *
FROM users
WHERE TRIM(name) = '';

SELECT user_id,
       product_id,
       COUNT(*)
FROM favorites
GROUP BY user_id, product_id
HAVING COUNT(*) > 1;

SELECT *
FROM audit_log
ORDER BY created_at DESC
LIMIT 20;

SELECT *
FROM logs
WHERE created_at >= NOW() - INTERVAL '24 hours';

SELECT u.id, u.email
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

Тест-план — что тестируем, что не тестируем, какие риски, какие ресурсы. Это стратегия, а не список тестов.

Тест-кейс — конкретные шаги с ожидаемым результатом. «Ввести email → нажать "Войти" → ожидаемый результат: редирект на дашборд.»

Чек-лист — упрощённый тест-кейс. Без подробных шагов, просто список проверок. Быстрее писать, проще поддерживать, но требует знания системы.

Баг-репорт — что сломалось, как воспроизвести, что ожидалось. Чем точнее — тем быстрее починят.

How can I check the responsiveness of my application for screen resolutions that are rarely used (e.g., 800x600 or 5K)? What testing tools and
methods should be applied for these screen sizes?

Клиент сообщает, что у него ошибка, но вы не можете её повторить. Ваши шаги?

— Resilience-тестирование становится обязательным, а не «хорошо бы»
— Тесты на отказоустойчивость, восстановление, failover — это теперь требование регулятора
— Нужна трейсабилити: от требования → к тест-кейсу → к результату → к отчёту
— Штрафы: до 2% годового оборота для организации, до €1 млн лично для руководителя