Главная / Блог / Почему тестовые наборы неэффективны

Почему тестовые наборы неэффективны, и как предотвратить кучу проблем при тестировании

Почему тестовые наборы неэффективны, и как предотвратить кучу проблем при тестировании

Smartiqa Failed Testsuits
Дата: 10 июля 2020
Автор: Антон Катин
Сквозное тестирование (E2E), проводимое, например, с помощью Selenium, часто не дает нужного результата и попросту выходит из строя. И хотя подобных случаев вагон, их все-таки можно разделить на две отдельные группы по причинам их возникновения.
Итак, группы следующие:
1
Тестовый набор «разъелся» и потерял прежнюю стабильность.
Он не может стабильно стартовать, выбрасывает кучу ложных срабатываний и начинает работать настолько медленно, что о своевременном тестировании можно и не мечтать. Когда сроки горят, то многие начинают думать, что создание качественного и надежного тестового набора — вещь далеко не первостепенная.
2
Тестовый набор не обновляется вместе с расширением тестируемого ПО.
Как результат — тестовый набор устаревает и более не отражает реального положения дел.

Невероятно важно поддерживать актуальность своих тестов, особенно если речь идет об E2E, ведь он тестирует все приложение и имитирует поведение пользователя, позволяя приблизиться к «боевым» условиям использования ПО.

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

Создание продуманного тестового набора

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

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

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

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

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

Переосмысление процесса обслуживания в три категории

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

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

1. Build-to-build

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

2. Stability

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

3. Maintenance over time

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

Анализ продукта

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

Выставление рамок

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


Подводя итог, хотелось бы процитировать одного известного швейцарского врача: «Все – яд, все – лекарство; то и другое определяет доза».
10 ИЮЛЯ / 2020
Как вам материал?

Читайте также