Довольно часто процессы тестирования внутри крупных продуктов, рассчитанных на миллионы конечных пользователей, превращаются в «черный ящик». Каждый участник процесса разработки видит лишь свой узкий участок: аналитики уверены в точности и полноте требований, разработчики уверены в коде, инженеры по функциональному тестированию — в отсутствии багов в своих подсистемах, администраторы — в настройках сервера. Всем участникам кажется, что все работает нормально, но это ощущение бывает обманчивым. Именно с такой ситуацией мы столкнулись на одном из проектов. Заказчик, крупная компания с высоконагруженным продуктом, обратился к нам с запросом о проведении аудита процессов тестирования. Внутренние отчеты и метрики говорили о том, что система стабильна, но сам заказчик, выступая в роли конечного пользователя, видел обратное: продукт работал далеко не так гладко, как обещали графики и выводы в отчетах. Поэтому он решил, что внешняя экспертная оценка поможет подсветить то, что прячется, возможно, на самом видном месте.Привет, Хабр! Меня зовут Михаил Володин, я ведущий инженер отделения нагрузочного тестирования. В этой статье расскажу о реальном кейсе, когда по отчетам с продуктом все хорошо, а пользователи все равно жалуются. Нам с командой нужно было дать объективную оценку: достаточно ли текущих методов, подходов и инструментов, где скрываются слепые зоны, необходимо ли что-то менять. У меня получилось что-то вроде инструкции по проведению аудита нагрузочного тестирования. Процесс состоит из пяти основных этапов. Разберем, как проверить методологию, инструменты и саму философию подхода к нагрузке, чтобы понять, нужно ли что-то менять — и если да, то как. Читать далее