В 2022 году друг Никита скинул мне статью от Ozon Tech. Называлась она сухо, в духе “Нефункциональное тестирование: полный разбор теории и практики”. Я открыл из вежливости, а закрыл уже с пониманием, чем хочу заниматься следующие пять лет. Ссылка для тех, кто тоже хочет провалиться в эту кроличью нору: https://habr.com/ru/companies/ozontech/articles/662800/

До этого я, как и многие QA, жил в парадигме “нажал кнопку: получил ответ”. Но Блэк и ребята из Ozon разложили по полкам то, что обычно скрыто за ширмой “производительности”. Оказалось, что нагрузочное тестирование: это зонтичный термин для десятка разных активностей, где ты изучаешь не баги, а поведение системы под давлением.

Вот что отпечаталось в памяти сильнее всего:

1. Spike testing: это не просто “дадим трафика побольше”. Это резкий импульс, после которого система должна вернуться в норму. Мы однажды уронили бэкенд не во время скачка, а именно на фазе восстановления: она оказалась дороже самого пика.

2. Soak testing (тестирование стабильности): единственный способ поймать утечку памяти, которая на обычных прогонах маскируется. Если ваш тест длится 15 минут, вы не видите проблему, которая проявится на 90-й.

3. Tip-over testing: самый жестокий и честный вид. Вы намеренно давите систему до отказа, чтобы найти самое слабое звено. Это не баг-репорт, а хирургия архитектуры.

Статья дала главное: язык. Я перестал говорить “сайт тормозит” и начал оперировать понятиями перцентилей, деградации и утилизации ресурсов. С тех пор нагрузочное тестирование перестало быть для меня просто видом QA: это теперь способ смотреть на систему глазами SRE-инженера.

А какая статья или книга в своё время перевернула ваше представление о профессии?

#loadtesting #performancetesting #qaengineer #sre #ozontech #habr #soaktest #spiketesting #softwaretesting #nonfunctionaltesting #career #engineering