Автоматизация тестирования
Автоматизация тестирования абсолютно неотъемлема и необходима в современной разработке программного обеспечивания. Ее преимущества известны всем, что делает автоматизацию тестирования желанным для применения. Факт, отказ от ручного тестирования, сокращение затрат и автоматизация в спринте (in-sprint automation) подталкивают компании внедрять автоматизацию как можно скорее в собственные проекты. У каждой компании свой подход к достижению цели. Однако, они все совершают одинаковые ошибки в процессе внедрения автоматизированного тестирования.
Работая над фреймворками для автоматизированного тестирования, я пытался определить общие проблемы, с которыми сталкиваются организации, и ошибки, которые они совершают. Эти ошибки создают эффект снежного кома и влияют на возврат инвестиций (ROI) от автоматизации.
Улучшай внедрение автоматизации, избегая распространенных ошибок
Жизненный цикл автоматизированного тестирования
Для планирования, реализации и поддержки автоматизированных тестов, я разделяю автоматизацию на 4 этапа. Это помогает мне отслеживать и контролировать автоматизацию на проектах. Этапы имеют следующие названия:
Планирование автоматизации.
Проектирование/разработка автоматизации.
Внедрение и выполнение автоматизации.
Поддержка и улучшение автоматизации.
Я хотел бы представить распространенные ошибки в каждом из 4 этапов. Давайте посмотрим на них.
1. Ошибки на этапе планирования автоматизации
Не рассчитана окупаемость инвестиций (ROI).
Нет плана автоматизации/цели автоматизации.
Не определен и не приоритизирован объем тестирования перед стартом автоматизации.
Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания.
Выбран неправильный уровень тестирования для автоматизации.
Выбор инструментов, так как они open-source или бесплатные.
Выбор неправильных инструментов автоматизации.
Выбор инструментов на основе навыков команды.
1.1 Не рассчитана окупаемость инвестиций (ROI)
Первая и наиболее частая ошибка, это незнание команд окупятся ли усилия, которые вложат в автоматизацию, или нет. Первоначальная цель автоматизации, это уменьшение расходов при увеличении уровня качества. Рассчитываем мы ROI при внедрении автоматизации в проект? Если ответ нет, какой смысл в автоматизации? Это фундаментальная проверка, которую должный делать команды перед началом автоматизации.
Решение проблемы - с помощью формулы ниже рассчитать ROI в автоматизацию.
RIO = "Затраты ручного тестирования, которые уменьшает автоматизация" - ("Затраты на автоматизацию" - "Затраты на поддержку автоматизации")
1.2 Нет плана автоматизации/цели автоматизации
Они говорят "Плохой план лучше чем его отсутствие". Однако, 80% проектов используют автоматизированное тестирование без плана. Неудивительно почему так много проектов автоматизации не оправдывают ожидания. Это происходит потому что нет шагов автоматизации, неявно установлена цель или нет сигнала о готовности начать, по сути, отсутствие плана автоматизированного тестирования. Часто проекты автоматизации выполняются одновременно с ручным тестированием, но как раз определить различия этих подходов? Насколько отличается их реализация? Разве не требуется различное мышление для выполнения ручного и автоматизированного тестирования? Получается, что нужен план для каждого подхода с разными критериями успеха?
Решение проблемы - создать эксклюзивный, специализированный и исчерпывающий план автоматизированного тестирования.
1.3 Не определен и не приоритизирован объем тестирования перед стартом автоматизации
Обычно говорят "нельзя улучшить то, что нельзя измерить", что верно при запуске проектов автоматизации. Как мы можем начать ее без определения объема тестирования? Без этого мы не можем измерить и сравнить результаты автоматизации. Без определения объема мы будем неуверенными на каждом этапе тестирования.
Решение проблемы - определить объем тестирования
1.4. Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания
Был ли у вас когда-либо задокументированные требования к среде автоматизации? Мы убедились, что сложность разработки среды для автоматизации практические такая же, как и для разработки бизнес-приложений. Мы не начинаем разработку таких приложений без документации, но при этом начинаем автоматизацию без нее. Это приводит к неправильным/неизвестным ожиданиям от среды автоматизации и часто они нереалистичны.
Решение проблемы:
Среда автоматизации - не начинать разрабатывать среду автоматизации без задокументированных требований к ней и определения цели автоматизации.
Инструменты автоматизации - составить требования и ожидания от инструментов автоматизации и используйте инструменты, которые соответствуют требованиям.
1.5. Выбран неправильный уровень тестирования для автоматизации
Часто тестировщики фокусируются на автоматизации UI тестов для обеспечения end-to-end тестирования вместо интеграционных, API и БД тестов. Автоматизация нижних уровней тестирования обеспечит лучшее и детальное тестовое прикрытие с большей скоростью и меньшими затратами. UI тесты медленные и их дорого поддерживать. При этом мы не можем исключать тестирования UI, особенно для продуктов ориентированных на пользователя и продуктов Saas, но можем свести его к минимуму.
Решение проблемы - Понимать и следовать пирамиде тестирования, это фундамент успеха и эффективности автоматизации. Уделять больше внимания тестированию на низком, чем на более верхнем уровне пирамиды тестирования.
1.6. Выбор инструментов, так как они open-source или бесплатные
Основная причина неудач автоматизации - выбор инструментов или библиотек потому, что они бесплатные или имеют открытый исходный код. Хотя эти они отлично работают, если разработаны должным образом, однако в этом заключается проблема.
Разработка среды автоматизации - это, по сути, тот же процесс, что и разработка других бизнес приложений командой разработчиков. Это словно полноценный проект разработки, который должен иметь свои строгие стандарты жизненного цикла программного обеспечивания (SDLC). Разработчики среды автоматизации должны иметь тот же уровень компетенций, что и разработчики приложений. Потому, что возникает необходимость в процессах проверки кода, архитектуры, утверждении дизайна среды, тестировании, соблюдении стандартов кодирования, управлении кода и т.д. Если мы ожидаем качественный результат от автоматизации, разработанная среда автоматизации должна соответствовать всем практикам (best practices) SDLC.
Все это имеет цену и она может быть высокой. Риск провала проекта автоматизации высок, поскольку у организации всегда есть другие бизнес обязательства. Следовательно, бесплатное ПО и ПО с открытым исходным кодом не может быть "бесплатным" и существует риск неудачи, если оно не будет правильно разработано.
Решение проблемы:
Использовать best practices для разработки среды автоматизации, которым следуют разработчики бизнес приложений.
Рассмотреть платные или менее дорогостоящие инструменты на рынке, которые обеспечат экономию средств.
1.7 Выбор неправильных инструментов автоматизации
Популярный инструмент может не подходить для нашей задачи. Следовательно, команда тестирования должна сосредотачиваться на сценарии использования при выборе инструмента для автоматизации.
Решение проблемы:
Определить для чего нужен инструмент автоматизации. Определить уровень в пирамиде тестирования. Подход к выбору инструмента может быть легче, если исходить из уровня тестирования.
Применяя POC, использовать пробный период выбранного инструмента.
1.8 Выбор инструментов на основе навыков команды
Еще одна проблема заключается в выборе инструмента основываясь на навыках команды. Мир движется к no-code решениям и автоматизированное тестирования тоже. No-code инструменты автоматизации обеспечат более быструю работы без дополнительных навыков.
Решение проблемы - цель автоматизации не в улучшении навыков программирования команды, а скорее в сохранении средств ручного тестирования. Если первичная цель организации не в автоматизации тестирования, то лучше выбрать готовый инструмент, а не разрабатывать свой. Особенно для маленьких организаций лучше внедрить готовый инструмент, так как разработка и поддержка собственной среды автоматизации будет иметь низкую ROI, чем готовый платный инструмент.
2. Ошибки на этапе проектирования/разработки автоматизации
Нет дизайна разрабатываемой системы.
Нет обработки исключений.
Неправильный механизм логирования.
Нет стратегии управления кодом/ветками и управления выпуском.
2.1 Нет дизайна разрабатываемой системы
Классические проблемы с которыми сталкиваются при разработке приложений возникают и при разработке среды автоматизации. На самом деле, возможно, в большем масштабе чем разработчики приложений, потому что имеют более низкий уровень знаний. Отсутствие документации, в которой содержится информация о дизайне автоматизации приведет к некачественной разработке, потому что -
Неструктурированные модули/монолитное приложение.
Неправильные паттерны проектирования.
Неприменение best practices.
Нет процесса ревью кода.
Низкая возможность переиспользование кода.
Отсутствие модульности на функциональном уровне.
Нет этапа тестирования самой среды автоматизации.
2.2. Нет обработки исключений
Часто ошибки, которые возникают в среде автоматизации необходимо исследовать и исправить в самом коде, потому что нет обработки исключений в самом коде в первую очередь. Следовательно, в отчете после выполнения нет удобных (изящных) исключений.
Решение проблемы - все типы исключений должны быть обработаны на каждом функциональном уровне. Код должен пройти процесс ревью для исключения отсутствия обработки исключений.
2.3 Неправильный механизм логирования
Среда автоматизации должна иметь эффективную систему логирования ошибок, с помощью которой осуществляется отслеживание и исправление дефектов без просмотра кода среды.
Решение проблемы - эффективный механизм логирования с указанием успешных шагов, ошибок и предупреждений должен интегрироваться в среду автоматизации.
2.4 Нет стратегии управления кодом/ветками и управления выпуском
Среда автоматизации содержит большое количество кода. Часто возникают конфликты в коде при работе над ним нескольких разработчиков. Это приводит к неструктурированному кода и неизбежным конфликтам в нем. При написании тестовых скриптов в среде автоматизации возникают сложности, которые заставить выпускать новые версии среды.
Решение проблемы - внедрение стратегии ветвления для среды автоматизации для совместной работы и увеличения функционала. Затем применять систему управления выпуском и использовать раздельно ветку разработки и выпуска.
3. Ошибки на этапе внедрения и выполнения автоматизации
Отсутствие определения объема тестирования.
Нет стратегии управления данными.
Автоматизация больших потоков.
Не проводится проверка тестов.
3.1 Отсутствие определения объема тестирования
Отсутствие определения объема тестирования приведет к отсутствию планирования на этапе внедрения автоматизации. Мы не сможем измерить результат работы по написанию тестовых скриптов.
Решение проблемы - перед запуском тестовых скриптов должен быть определен объем для покрытия автоматизацией. Объем регрессивного тестирования должен быть определен с целью последующей автоматизации.
3.2. Нет стратегии управления данными
Среда автоматизации должна иметь правильную стратегию управления данными. Хранение данных в файлах excels, csv и т.п. устарело и замедляет выполнение тестов. Также, переменные с тестовыми данными не должны храниться в коде скриптов.
Решение проблемы - среда автоматизации должна иметь возможность хранить и предоставлять тестовые данные в удобном формате JSON, XML и т.п.
3.3 Автоматизация длинной бизнес логики
Автоматизация длинной бизнес логики может увеличить шанс неправильной отображения работоспособности тестируемого приложения, особенно в случае UI тестирования. Может быть случай, когда весь тестовый скрипт ломается из-за небольшого сбоя.
Решение проблемы - разделение длинных скриптов на маленькие поможет повысить стабильность их выполнения. Скорость прохождения набора тестов увеличится, а ошибки будут корректно указываться в точках сбоя.
3.4. Не проводится проверка тестов
Часто автоматизированные скрипты не подвергаются проверки. Ручной тестировщик проверяет сценарии во время их выполнения, но автоматизаторы часто пропускают проверку фактического результата и ожидаемого в разработанных скриптах. Следовательно, ухудшают тестовое покрытие.
Решение проблемы - получить подтверждение правильности скриптов от заинтересованного лица. Заинтересованным лицом может быть бизнес аналитик или QA.
4. Ошибки на этапе поддержки и улучшения автоматизации
Нет обновления кода скриптов при изменении функционала тестируемого приложения.
Редкие запуски тестов.
Зависимость от члена команды.
4.1 Нет обновления кода скриптов при изменении функционала тестируемого приложения
Изменения или улучшения функционала приводит к волновому эффекту. Не обновляя код тестовых скриптов приводит к их устареванию.
Решение проблемы - Среда автоматизации должна иметь возможность легко обновлять тестовые скрипты. Какая польза от среды автоматизации, если при каждом изменении функциональности приложения нужно вносить изменения в ее код для улучшения тестовых скриптов? Это худший дизайн среды автоматизации.
4.2 Редкие запуски тестов
Команда автоматизаторов должна иметь техническую возможность запускать тесты часто. Во время гибких методологий разработки, это становится наиболее важным. Редкий запуск тестов создает две проблемы:
Не реализация потенциала автоматизации и недостаточное тестирование приложения.
Мы не сможем понять насколько устарел наш тестовый скрипт относительно изменений функционала тестируемого приложения. Частый запуск тестов обеспечивает своевременную проверку актуальности тестов. Это также гарантирует, что мы постепенно обновляем скрипты, избегая их устаревания и неуправляемых изменений.
Решение проблемы - Запуск автоматизации на отдельно выделенной машине обеспечивает работу скриптов в любое время и без потери времени автоматизатора. Еще лучшим подходом является интеграция запуска тестов в CI/CD.
-
Решение проблемы -
Запуск автоматизации на отдельно выделенной машине обеспечивает работу скриптов в любое время и без потери времени автоматизатора. Еще лучшим подходом является интеграция запуска тестов в CI/CD.
4.3 Зависимость от члена команды
Другой ошибкой является зависимость от конкретного сотрудника для запуска тестов или зависимость от его учетных данных. Это ненужная зависимость, которая уменьшает гибкость автоматизации.
Решение проблемы - Создать и использовать общие ID, предоставлять доступ к приложению по общему ID и запускать тесты используя общей ID.
Вот объединенный список частых ошибок, которые возникают во время планирования и внедрения в проекты у команд автоматизации.
Планирование автоматизации
Не рассчитана окупаемость инвестиций (ROI).
Нет плана автоматизации/цели автоматизации.
Не определен и не приоритизирован объем тестирования перед стартом автоматизации.
Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания.
Выбран неправильный уровень тестирования для автоматизации.
Выбор инструментов, так как они open-source или бесплатные.
Выбор неправильных инструментов автоматизации.
Выбор инструментов на основе навыков команды.
Проектирование/разработка автоматизации
Нет дизайна разрабатываемой системы.
Нет обработки исключений.
Неправильный механизм логирования.
Нет стратегии управления кодом/ветками и управления выпуском.
Внедрение и выполнение автоматизации
Отсутствие определения объема тестирования.
Нет стратегии управления данными.
Автоматизация больших потоков.
Не проводится проверка тестов.
Поддержка и улучшение автоматизации
Нет обновления кода скриптов при изменении функционала тестируемого приложения.
Редкие запуски тестов.
Зависимость от члена команды.
Выводы
Мы пришли к выводу, что разработка среды автоматизации также сложна, как и разработка бизнес-приложений. Становится понятно почему совершается много ошибок, если процессу разработки среды не уделять должного значения, не соблюдая best practices или не используются правильные ресурсы и навыки. Также, open-source инструменты не дают ожидаемого эффекта. Если организация не заинтересована в развитии средств автоматизации тестирования, это знак к использованию готовых решений, которые обеспечат более высокую ROI за счет уменьшений расходов на разработку и поддержку собственной среды. Особенно в случае маленьких компаний будет сложно обосновать ROI, поскольку они имеют меньшую экономическую гибкость.