Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Вы не занимаетесь непрерывным тестированием, если не проводите тестирование до, во время и после каждого изменения в программном обеспечении.
Для проведения непрерывного тестирования необходимо предпринять следующие действия:
1. Создайте качественную среду
Команда QA не “отвечает за качество”, не создает проблемы, которые влияют на качество, и не устраняет эти проблемы. Она просто находит их.
Хотя поиск ошибок является важным шагом в разработке ПО, многие из этих ошибок можно выявить раньше, поэтому необходимо приступать к тестированию непосредственно в начале процесса разработки.
Качественный код начинается с проектирования ПО. Лучше всего, чтобы организация внедрила практики разработки на основе поведения (BDD): разработчики, тестировщики и владельцы продукта согласовывают функциональность и тесты до написания кода.
2. Сборка и непрерывная интеграция
Автоматизация сборки и создание конвейера непрерывной интеграции (CI) являются ключевыми моментами для успешного проведения непрерывного тестирования. В то время как может быть трудно обеспечить начало тестирования до написания кода, достаточно просто убедиться в том, что после того, как разработчики добавили код в систему контроля версий, началось тестирование.
Тестирование на уровне разработчиков очень важно, поскольку оно обеспечивает быструю обратную связь и гарантирует, что на самом низком уровне ваш код делает то, что ожидается.
3. Внедрите виртуализацию, эмуляцию и симуляцию
Быстрые циклы обратной связи являются ключом к НП. Лучший способ получить быструю обратную связь в рамках DevOps-пайплайна – тестировать только то, что необходимо тестировать, на минимальном приложении.
Часто это означает, что вместо того, чтобы потратить 20 минут на создание полного стека приложения, вы запускаете только API и проводите тестирование API. Если есть возможность, используйте облачные сервисы для быстрого развертывания приложения, а затем, в целях экономии средств, закройте приложение после завершения работы.
При тестировании всего приложения обратите внимание на то, какую обратную связь вы действительно ищете:
- Для веб-приложения действительно ли вам нужен полноценный браузер Chrome для запуска тестов, или для начального тестирования достаточно драйвера HtmlUnit?
- Предоставляет ли такая симуляция достаточно информации для принятия решения о продолжении работы или прекращении?
- Если у вас приложение с большим количеством микросервисов, нужно ли вам запускать их все или можно обойтись имитацией некоторых из них для ускорения работы?
- Если у вас мобильное приложение, можете ли вы использовать эмулятор вместо реального устройства? Что будет потеряно, и будет ли это заметно?
Секунды, которые можно сэкономить за счет использования более быстрых устройств и инструментов, складываются в минуты и часы в процессе сборки, что означает ускорение цикла разработки и экономию денег.
4. Добро пожаловать, контейнеры
Docker – одна из новых технологий и удобных способов использования контейнеров для облегчения тестирования. В то время как контейнеризация удобна сама по себе, возможность загрузить приложение и запустить его в любом месте точно таким же образом делает тестирование намного проще. Это помогает избежать такого выражения, как “It works on my machine”, что означает “У меня все работает”.
Размещение приложения в контейнере, будь то Docker, Mesos или LXC, позволяет проводить тестирование везде и всюду.
Можно использовать ещё более продвинутый подход и применить контейнеризацию для ваших тестов. Это не только упрощает запуск тестов в рамках пайплайна, но и не требует настройки машины, то есть любой член команды может загрузить и запустить ваше приложение и контейнеры для тестирования, а также получить показатели качества без сложной настройки системы.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
5. Используйте среды, похожие на производственные
Одним из самых больших преимуществ создания конвейера развертывания является возможность автоматического развертывания вашего ПО быстрым, повторяющимся способом. В идеале вы развертываете программу на одной системе, запускаете тесты, получаете обратную связь, затем все повторяется.
Однако необходимо убедиться, что все среды максимально приближены к производственным условиям. Если вы знаете, что настройка не будет соответствовать конечному состоянию, пользы от тестирования будет мало. Хотя это может потребовать дополнительных ресурсов, вам не всегда нужно полномасштабное развертывание для каждой среды.
Рисунок 1 : Масштабирование развертывания для постепенного приближения к производственному , чтобы лучше имитировать тестирование, подобное производственному.
Это также означает, что при проектировании и разработке тестов следует учитывать доступ, который вы будете иметь в каждой среде, и данные, которые вы хотите/необходимо тестировать. Как вы можете/должны предоставлять эти данные? Являются ли эти тесты разрушительными для данных или даже для приложения?
Проектирование с учетом этих факторов обеспечит возможность выполнения ваших тестов в любой среде, что позволит проводить больше проверок качества на протяжении всего процесса разработки.
6. Управляйте тестовыми данными
Работа с тестовыми данными – одна из самых больших проблем в организациях. Слишком часто люди не задумываются о том, какие данные необходимы для тестирования. В результате организации используют для тестирования неполные, неизвестные или слишком большие данные.
При разработке теста, будь то автоматизированного или ручного, необходимо обратить внимание на данные, которые нужны для реализации функциональности.
Если вы запускаете только один тест, и этот тест требует только одного пользователя, не тратьте время на загрузку миллиона пользователей в систему. И наоборот, если вы проводите тестирование на более продвинутом этапе, и производительность играет важную роль, убедитесь, что вы используете набор данных, который должным образом нагружает систему. В таком случае нескольких пользователей, скорее всего, недостаточно.
7. Автоматизируйте тестирование ниже уровня UI
При тестировании ваше приложение – это не только пользовательский интерфейс. У вас, вероятно, есть несколько API, бэкенд и база данных, и все они нуждаются в тестировании. Тестирование на более низких уровнях, помимо упрощения процесса реализации, также позволяет проводить проверки на более ранних этапах разработки приложения.
Рисунок 2 : Вместо тестирования на уровне UI , что требует большого времени и затрат, рекомендуется чаще проводить тестирование на более низком уровне.
Подобно базе данных или бэкенду, UI не обязательно должен быть полностью разработан, чтобы создать API и начать его тестирование. Таким образом, вы сможете начать тестирование быстрее, что и является целью.
Заключение
Не забывайте о создании конвейера CI ; сделайте качество основной целью для всей команды; автоматизируйте, эмулируйте и моделируйте как можно больше; используйте контейнеры, среды тестирования, похожие на производственные; и тщательно управляйте тестовыми данными.
Самое главное, помните, что для непрерывного тестирования необходимо начать тестирование на ранних этапах разработки ПО.
Успешного тестирования!
Перевод статьи Max Saperstone «Seven key enablers for continuous testing».