Impediments for Software Test Automation: A Systematic Literature Review
Аннотация
Статья представляет систематический обзор 39 публикаций, описывающих реальные препятствия при внедрении автоматизации тестирования программного обеспечения. Выделены три основные группы импедиментов: организационные, связанные с тестовой системой и связанные с тестируемой системой (SUT). На основе тематического анализа построена социотехническая модель, показывающая, как эти факторы взаимосвязаны и приводят к провалу инициатив по тест-автоматизации. Авторы формулируют рекомендации по учёту обнаруженных препятствий при планировании и оценке проектов автоматизации тестирования.
Ключевые слова: автоматизация тестирования, систематический обзор, препятствия (impediments), технический долг, социотехническая система.
1. Введение
Тестирование — один из самых затратных этапов жизненного цикла ПО. Автоматизация тестов рассматривается как способ сократить трудозатраты и повысить частоту регрессии, однако далеко не каждое внедрение оказывается успешным. Нестабильные автотесты, недостаток компетенций, слабая поддержка руководства и технические ограничения тестовой инфраструктуры нередко приводят к тому, что от автоматизации отказываются.
Цель работы Wiklund и соавторов — систематически собрать и обобщить опыт разных компаний и исследовательских групп, понять, какие именно препятствия наиболее типичны и как они взаимодействуют между собой.
2. Цели и методика исследования
2.1 Цели
- выявить и классифицировать препятствия для автоматизации тестирования ПО, описанные в научной и индустриальной литературе;
- объяснить механизмы возникновения этих препятствий и их взаимное влияние;
- предложить модель, которая помогает анализировать риски при планировании тест-автоматизации.
2.2 Поиск и отбор публикаций
Поиск работ выполнялся в базах данных IEEE Xplore, Scopus и Web of Science с использованием комбинированных запросов по ключевым словам: «software», «test automation», «impediment», «challenge», «obstacle» и др. Далее применялись критерии включения и исключения:
- рассматривается промышленный или близкий к реальному контекст;
- есть эмпирические данные (кейс-стади, отчёты, опросы);
- в тексте описаны проблемы именно автоматизированного тестирования;
- исключаются работы, посвящённые только ручному тестированию или отдельным инструментам без обсуждения препятствий.
В результате многоступенчатой фильтрации из 13 060 исходных результатов было отобрано 39 релевантных публикаций.
2.3 Тематический анализ
Для синтеза данных использовались методы тематического кодирования и мета-этнографический подход. Фрагменты текстов, описывающие негативные эффекты или проблемы автоматизации, кодировались и группировались в темы. Затем темы объединялись в более крупные категории, что позволило выделить три группы импедиментов и уточнить их подтипы.
3. Классификация препятствий
Авторы разделяют препятствия на три крупные группы. Для каждой группы приводятся характерные подтипы и типичные проявления.
3.1 Организационные импедименты
Организационные препятствия связаны с людьми, управлением и культурой компании. Наиболее часто встречаются следующие подтипы:
- Отсутствие стратегии и поддержки руководства. Автоматизация инициируется «снизу» и выполняется по остаточному принципу, без долгосрочного планирования и ресурсной поддержки.
- Нехватка времени и бюджета. Команды перегружены задачами по разработке, и на создание фреймворка и автотестов постоянно «не хватает времени».
- Дефицит компетенций. Сотрудникам не хватает навыков программирования, архитектуры тестов, работы с инструментами; обучение не закладывается в планы.
- Неверные ожидания. Руководство и команда ждут мгновенную окупаемость и 100-% автоматизацию, что неизбежно приводит к разочарованию.
- Страх и сопротивление изменениям. Тестировщики опасаются, что автоматизация приведёт к сокращениям, или воспринимают её как «навязанную сверху» инициативу.
3.2 Импедименты тестовой системы
Вторая группа препятствий относится к самой тестовой инфраструктуре и качеству тестового кода:
- Хрупкие тесты и технический долг. Скрипты создаются без архитектуры, с дублированием кода и жёсткими привязками к UI; любое изменение интерфейса ломает десятки тестов.
- Нестабильная инфраструктура. Ошибки и зависания стендов, гонки при работе с данными, сложности конфигурации приводят к ложным срабатываниям и потере доверия к тестам.
- Ограничения инструментов. Выбранный инструмент не поддерживает нужные платформы, плохо интегрируется с существующим стеком или требует сложной настройки.
- Неудобная отчётность. Если логи и отчёты трудно читать, анализ падений занимает слишком много времени и сводит на нет экономию от автоматизации.
3.3 Импедименты тестируемой системы (SUT)
Третья группа связана с особенностями самой тестируемой системы:
- Низкая тестопригодность. Отсутствуют стабильные API, идентификаторы элементов, точки расширения, что заставляет использовать нестабильные хаки в тестах.
- Сложные интеграции и зависимость от внешних систем. Тесты трудно изолировать, приходится поднимать громоздкие окружения и синхронизировать множество компонентов.
- Платформенные ограничения. Огромное количество целевых платформ (браузеры, ОС, мобильные устройства) делает поддержку единой тестовой базы очень дорогой.
- Производительность. Медленный отклик SUT ограничивает скорость выполнения автотестов, что особенно критично при больших регрессионных наборах.
4. Организационные аспекты автоматизации
4.1 Поведение и мотивация людей
Автоматизация тестирования затрагивает роли и распределение ответственности в команде. Непрозрачность целей и отсутствие диалога усиливают сопротивление: тестировщики видят в автоматизации угрозу своей работе, разработчики — дополнительную нагрузку без явной пользы. Авторы подчёркивают важность раннего вовлечения всех заинтересованных сторон и честного обсуждения целей и ожиданий.
4.2 Планирование и оценка окупаемости
В ряде работ отмечается, что компании либо вообще не оценивают окупаемость автоматизации, либо делают это задним числом. В результате решения принимаются на основе интуиции, а не данных, и проект легко становится «жертвой» очередного сокращения бюджета. Рекомендуется заранее формировать бизнес-кейс, определять целевые метрики (процент регрессии, частота релизов, среднее время прогона) и регулярно отслеживать их.
5. Качество тестовой системы
5.1 Архитектура и технический долг
Авторы подчёркивают: тестовая система — это тоже программный продукт, требующий архитектуры, рефакторинга и профилактики технического долга. Если тесты рассматриваются как «одноразовые скрипты», их сопровождение быстро становится дороже, чем выгода от автоматизации.
5.2 Инструменты и инфраструктура
В обзоре приводятся случаи, когда выбор неподходящего инструмента приводил к необходимости переписывать значительную часть тестов или даже полностью отказываться от автоматизации. Важную роль играет и инфраструктура: без стабильных тестовых стендов, конфигурационного менеджмента и мониторинга результаты автотестов трудно интерпретировать.
6. Тестируемая система и социотехническая модель
6.1 Роль архитектуры SUT
Если система изначально проектируется без учёта тестопригодности, даже очень опытная команда тестировщиков не сможет построить устойчивую автоматизацию. В ряде кейсов для успешной автоматизации приходилось модифицировать продукт: добавлять логирование, тестовые API, сервисы-имитаторы (stubs, mocks).
6.2 Социотехническая система тест-автоматизации
В статье предлагается рассматривать автоматизацию тестирования как социотехническую систему, где технические элементы (инструменты, тестовый код, инфраструктура, SUT) тесно связаны с социальными (организация, культура, навыки, мотивация). Модель подчёркивает циклические зависимости:
- низкое качество тестовой системы снижает доверие и мотивацию инвестировать;
- недостаток инвестиций не позволяет исправить архитектуру и инфраструктуру;
- это, в свою очередь, ещё больше ухудшает качество тестов.
Понимание этих циклов помогает заранее выявлять риски и устранять «узкие места».
7. Обсуждение и практические выводы
Основной вывод обзора: большинство критических препятствий имеет организационную природу, а технические проблемы часто являются следствием неправильных управленческих решений. Для успешной автоматизации необходимы:
- ясная стратегия и поддержка руководства;
- инвестиции в обучение и развитие компетенций;
- проектирование тестовой системы как полноценного программного продукта;
- учёт тестопригодности уже на этапе архитектуры SUT.
Авторы рекомендуют использовать предложенную классификацию и модель как чек-лист при планировании проектов тест-автоматизации и при ретроспективном анализе уже существующих инициатив.
8. Заключение
Систематический обзор Wiklund и соавторов демонстрирует, что автоматизация тестирования — это не только внедрение инструмента, но и комплексная трансформация процессов и культуры организации. Игнорирование организационных и архитектурных аспектов приводит к накоплению технического долга в тестовой системе и, как следствие, к провалу проектов автоматизации.
Предложенная авторами социотехническая модель и классификация импедиментов дают практикам полезный инструмент для анализа рисков, а исследователям — основу для дальнейших эмпирических работ в области тест-автоматизации.
Библиографическое описание
IMPEDIMENTS FOR SOFTWARE TEST AUTOMATION: A SYSTEMATIC LITERATURE REVIEW / Wiklund K., Eldh S., Sundmark D., Lundqvist K. // Software Testing, Verification and Reliability. – 2017. – Vol. 27, No. 8. – e1639, 20 p.
Список использованных источников
- Wiklund K., Eldh S., Sundmark D., Lundqvist K. Impediments for Software Test Automation: A Systematic Literature Review // Software Testing, Verification & Reliability. 2017. Vol. 27, No. 8. e1639.
- Dustin E., Rashka J., Paul J. Automated Software Testing: Introduction, Management, and Performance. Addison-Wesley, 1999.
- Garousi V. et al. AI-powered Software Testing Tools: A Systematic Review and Empirical Assessment of Their Features and Limitations. arXiv preprint arXiv:2409.00411, 2024.
- Graf M. Einführung und Auswertung des Nutzen-Aufwand-Verhältnisses von automatisierten GUI-Tests. Bachelorarbeit. Universität Stuttgart, 2017.
- Biffl S., Winkler D., Frast D. Testautomatisierung // Qualitätssicherung, Qualitätsmanagement und Testen in der Softwareentwicklung: Skriptum zur Lehrveranstaltung. Technische Universität Wien, 2004.