Даже без полноценного performance engineering QA должен понимать базовые признаки проблем производительности API. Медленный или нестабильный backend влияет не только на “скорость”, но и на UX, таймауты, очереди, retries и каскадные сбои.
На что смотреть
- →Latency: сколько занимает ответ.
- →Stability: насколько поведение предсказуемо при росте нагрузки.
- →Timeouts и деградация под конкуренцией.
- →Размер payload и стоимость сериализации.
Типовые сигналы риска
- →Один и тот же endpoint иногда отвечает быстро, а иногда резко медленно.
- →Фильтры, сортировка и пагинация резко деградируют на большом объёме данных.
- →Тяжёлые response bodies или неэффективные запросы к базе.
- →Поведение меняется при одновременных запросах и background load.
Что может сделать QA без full perf lab
- →Сравнивать время ответа между сценариями и версиями.
- →Замечать аномалии на тестовых и staging-окружениях.
- →Поднимать perf-риск раньше, если endpoint по дизайну выглядит тяжёлым.
- →Готовить meaningful scenarios для performance-специалистов или k6/JMeter suites.
Performance basics для QA — это умение видеть симптомы рано. Часто уже на обычном функциональном тестировании можно заметить паттерн, который позже вырастет в серьёзный инцидент.