(В оригинале - It's never too early to think about performance)

Когда клиенты формулируют свои требования, в основном они затрагивают лишь те, которые относятся к непосредственной функциональности системы. Нефункциональные же аспекты, такие как производительность, гибкость, время старта, необходимость техподдержки и прочее, остаются на усмотрение арихтектора. Однако, очень часто первое тестирование нефункциональных требований отодвигается до самого последнего момента цикла разработки. Это ошибка, встречающаяся слишком часто.

Причины этого могут быть различными. Возможно, иногда нет смысла делать что-то быстрым и гибким, если оно при этом не будет выполнять основные требуемые функции. Тестирование может быть очень сложным. Возможно, первые версии системы не будут работать под максимальной загрузкой.

Однако, если вы не обращаете внимание на производительность вплоть до конца проекта, вы теряете огромное количество информации о том, когда и как производительность меняется. Если производительность играет серьезную роль для системы, то ее тестирование должно начинаться как можно раньше. Если вы используете Agile методологию, основанную на двухнедельных итерациях, то по моему мнению тестирование производительности должно начаться не позднее третей итерации.

Почему это так важно? Самая важная причина этого – то, что вы будете знать, какие именно изменения повлекли падение производительности. И вместо детального анализа всей системы целиком в случае обнаружения проблемы производительности на поздней стадии вы сможете сконцентрироваться на ключевых моментах. Тестирование производительности, начатое рано и делающееся регулярно, предоставляет вам возможность сильно ограничить диапазон изменений, повлекших снижение производительности. В ранних тестах вы можете даже не искать проблемы производительности, а получить исходную точку, с которой будете сравнивать ситуацию в дальнейшем. Ведение такой истории вам даст жизненно важную информацию для обнаружения проблем производительности и их решения.

Этот же подход применим и в случае, когда требуется протестировать то или иное архитектурное решение на соответствие требованиям к производительности. Особенно же это критично для систем со строгими требованиями.

Техническое тестирование – вещь сложная. Настройка требуемого окружения, подготовка необходимых наборов данных, определение тестовых сценариев – все это занимает много времени. Начиная тестирование производительности на ранней стадии, вы можете построить требоемуе окружение за несколько шагов, избегая аврала в случае обнаружения проблем с производительностью.

Автор оригинала - Rebecca Parsons