Итак, группы следующие:

Проблемы, безусловно, возникают у всех, но ведь можно же как-то снизить их число? Конечно, и многое зависит от изначально правильного состава тестового набора, его обслуживании и команды, о чем я вам сейчас и расскажу.

Хорошо функционирующий тестовый набор требует осознанности и правильной расстановки приоритетов. В связи с тем, что E2E достаточно объемный, он зачастую требует дорогостоящего обслуживания и больших временных затрат. Самый лучший способ разгрузить обслуживание E2E — понять, для чего вы на самом деле используете этот вид тестирования.

Многие организации запускают бесчисленное количество ненужных им E2E тестов. Они запускают их для одного несоразмерного этому тесту приложения (даже не размером с SAP или Salesforce).

На вопрос «Почему бы вам не заменить E2E на низкоуровневые тесты?» они часто отвечают, что «им так сказал их Product Manager». Техлид прекрасно понимает, что это напрасная трата ресурсов, но иерархия в команде не оставляет ему права голоса (удивительно, на самом деле).

Google поделился своим представлением о качественном тестовом наборе еще несколько лет назад. Известная компания предлагает структуру пирамиды, при которой существует лишь ограниченное количество E2E-тестов, достаточное количество интеграционных тестов и большое количество юнит-тестов.

Итак, когда нужно прибегать к E2E тестам? Точно не тогда, когда ваше решение выглядит как стрельба из пушки по воробьям (искусственным, конечно). Следует придерживаться философии «всегда используйте низкоуровневые тесты там, где это возможно».

Использование E2E критически обусловлено только в тех случаях, когда вы не имеете представления о том, как работает приложение или набор функций в целом, пока не протестируете все вместе от и до.

Также известны случаи, когда обслуживание тестов было провальным и неэффективным вследствие того, что не было расстановки приоритетов. Разработчики просто получали список необходимых изменений, и, что вполне очевидно, делали сначала то, что проще, а не то, что важнее в данный момент.

Разделение обслуживания на три категории позволит упорядочить работу для каждой из категорий, разделяя приоритеты и компетенции.

Эта категория несет в себе мысль о стабильной связи между командой разработчиков и QA. В частности, когда происходит изменение пользовательского интерфейса (UI), многие тесты выходят из строя. Поэтому особенно важна своевременная осведомленность тестировщиков о предстоящих изменениях, чтобы они были готовы сразу же ответить набором качественных тестов.

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

С ростом приложения и его функционала растет и количество тестов, и это нормально. Но то, что вы добавляете больше функций, не значит, что конечный пользователь продолжает использовать все функции. Я хочу навести вас на мысль о том, что нужно выстраивать приоритеты внутри тестового набора — чему-то уделять больше внимания, а чему-то, соответственно, меньше. Однако это не панацея, и вы можете просто со временем увеличивать свою QA команду для того, чтобы покрывать все потребности проекта.

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

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