Компании и менеджеры по тестированию хотят получать максимальную отдачу от фреймворка автоматизации тестирования, когда продукт уже достиг стабильного состояния. Встает дилемма, нужно ли покупать что-то или создавать свой собственный фреймворк.
У обоих подходов есть свои плюсы и минусы. Компании всегда хотят принять правильное решение, чтобы не рисковать временем и деньгами. Так что же лучше – покупать или создавать самим? Постараюсь ответить на этот вопрос ниже.
Преимущества использования фреймворка для автоматизации
У фреймворка для автоматизации тестирования есть множества плюсов. Он позволяет добиваться результатов экономя время и силы. Код становится понятнее и его легко переиспользовать.
Кроме того, так вы можете снизить затраты на тестирование, поскольку не нужно нанимать много людей для выполнения тысяч тестов. Есть множество доступных лицензированных и бесплатных фреймворков. Проблема в том, чтобы выбрать правильный, тот, который будет отвечать потребностям вашего проекта. Задача еще сложнее – применить выбранный фреймворк для существующего проекта и сконфигурировать его в соответствии с реальными потребностями.
Покупать или создавать фреймворк для автоматизации?
Мое мнение таково, что оба подхода приемлемы, поскольку весь вопрос в потребностях проекта. Какой из этих подходов выбрать в вашем случае – вопрос нелегкий.
Если вы что-то покупаете, у вас два есть два пути: покупка фреймворка с открытым исходным кодом или коммерческий лицензированный фреймворк. Открытый фреймворк можно просто поставить и использовать. Например, если код тестов лежит на GitHub, можно быстро создать дашборды, а для выполнения тестов понадобится всего несколько конфигураций. В обоих вариантах есть большое разнообразие отчетов о тестах, которые крайне привлекательны для менеджеров.
Создание собственного фреймворка подарит вам иной опыт. Вы сами будете контролировать свой код. Вы сможете применить настройки и конфигурации в коде. Вы не ограничены количеством функций, которые вы можете добавлять и редактировать. Фреймворк будет адаптирован к конкретным потребностям проекта, следовательно, будут удовлетворяться специфические потребности, недостижимые в коммерческом фреймворке.
Чтобы решить, покупать или создавать свой фреймворк для автоматизации, рассмотрите правило 3C (Cost, Customization ease, Control) – стоимость, легкость кастомизации, контроль. Давайте разложим обе стратегии по этим трем метрикам:
Стоимость
Вам нужно учитывать затраты сил и времени, которые команды затрачивают на создание решения. Есть непредвиденные затраты на внедрение решения для автоматизации, которые необходимо учитывать. Команды должны написать код для создания тест-кейса, все отладить, выполнить и обработать ошибки.
Отчеты должны генерироваться с помощью кода и отвечать потребностям руководства. Код требует поддержки, поскольку тест-кейсы меняются, а вслед за ними и сценарии. Могут потребоваться дополнительные усилия для интеграции с инструментами CI/CD и DevOps. Если текущая команда не умеет писать код, могут понадобиться новые сотрудники.
Все это приводит к росту стоимости проекта. И затраты могут расти, если для выполнения этих тестов вам понадобится дополнительная инфраструктура. Необходимость масштабирования возникает естественным образом всякий раз, когда объемы тестирования и его производительность увеличиваются.
Все эти расходы покрываются, когда мы покупаем готовый фреймворк для автоматизации после его оценки в соответствии с потребностями продукта. Ряд коммерческих фреймворков автоматизации тестирования предоставляют множество функций, которые значительно упрощают автоматизацию задач тестирования.
Нет необходимости нанимать разработчика с большим набором навыков для автоматизации тестов и управления ими. Большая часть автоматизации может быть выполнена любым членом команды. Так не только выходит дешевле, но и разработчики могут сосредоточиться на создании функционала проекта вместо работы над автоматизацией тестирования.
Легкость кастомизации
Даже при оценке коммерческих фреймворков вам надо помнить про легкость кастомизации.
Несмотря на ограниченные возможности, нужно понять, как их кастомизировать под нужды проекта. Если прогнозируемое увеличение масштаба слишком велико, что требует большого количества надстроек, у нас может возникнуть соблазн создать свой собственный фреймворк, который будет дополнять ваш продукт.
Однако, если кастомизаций не нужно много, правильнее будет заплатить за готовое решение.
Контроль
В случае с коммерческим решением для автоматизации, именно его поставщик отвечает за добавление и поддержку дополнительных функций, ориентируясь на свои собственные сроки. Несмотря на то, что большинство вендоров не взимают дополнительную плату за такие обновления, у вас отсутствует контроль за сроками выпуска версий.
Опять же, вы получаете выгоду от коллективной обратной связи и запросов функций от клиентской базы. Ваша команда может извлечь выгоду из опыта и инноваций, которые возникают у этой большой группы ваших коллег по отрасли.
С другой стороны, самостоятельно созданный фреймворк дает команде полный контроль, и вы можете дописывать новый функционал по мере необходимости.
Итак, кто же победил?
Создавайте свой собственный фреймворк для автоматизации тестирования, если:
Проект очень сложный и относится к специфической области;
В будущем запланировано активное развитие;
Компания выделила достаточный бюджет;
У вас есть квалифицированные сотрудники, которые могут быстро писать, настраивать и поддерживать скрипты.
Коммерческие или открытые фреймворки станут отличным вариантом, если:
Проект относится к популярной области, например, электронная коммерция или софт для больницы;
Бюджет ограничен;
Сроки выхода на рынок поджимают и от команд ждут быстрых доставок.
Внимательно рассмотрите все вышеперечисленные факторы, и тогда вы сможете ощутить все преимущества автоматизации в своем проекте.
Материал подготовлен в рамках курса «Python QA Engineer».