От требований до продакшена. QA понимает, где теряется логика, где ломается интеграция и где страдает пользователь.

«Не описано» — не значит «не важно». Тестировщик замечает пробелы раньше, чем они становятся проблемой.

Не функциями, а поведением. Это фундамент для продуктового мышления.

Кто пострадает? Какой масштаб? Можно ли выпускать? Это уже уровень принятия решений, а не просто проверки.

QA регулярно задаёт вопрос: «А человеку это вообще удобно?»

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://api.example.com

— DNS — время резолва
— Connect — установка соединения
— TTFB — время до первого байта
— Total — полный ответ

— быстрый smoke перед релизом
— сравнение dev / stage / prod
— проверка деградации после изменений
— аргументированный баг «API отвечает 1.8s вместо 300ms»

try {
    service.createUser(null);
} catch (Exception e) {
    // ничего не делаем
}

assertThrows(IllegalArgumentException.class, () -> {
    service.createUser(null);
});

Environment — «для конкретного стенда»
Global — «для всего и сразу»

systemctl status app-name --no-pager

journalctl -u app-name --since "2 hours ago" --no-pager | tail -n 80

— своя зона ответственности проседает
— фокус распыляется
— задачи закрываются в последний момент
— команда привыкает, что вы подстрахуете всегда