Проблемы и лучшие практики настройки тестового стенда / тестовой среды (окружения):
В ряде случаев тестировщики сталкиваются с тем, что их дефекты воспроизводятся из-за проблем с окружением. В результате разработчики не берут в работу такие дефекты.
Поэтому помимо таких аспектов, как планирование различных тестовых сценариев и понимание продукта, значительное количество времени должно уделяться настройке тестового стенда или тестовой среды. Тестировщики также должны направить свои усилия на создание эффективных тестовых данных.
Тестовый стенд – это двухэтапный процесс, состоящий из настройки тестовой среды и создания тестовых данных.
В этой статье мы рассмотрим общий процесс настройки тестовой среды, наиболее распространенные проблемы при настройке, а также рекомендации, которые следует учитывать при создании тестового стенда для предотвращения этих проблем.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
Что такое тестовый стенд и тестовая среда?
В общем смысле тестовый стенд можно определить как вид среды разработки, в которой разработчики могут свободно тестировать свои модули без какого-либо вмешательства со стороны команды тестирования.
Однако, тестовый стенд предназначен не только для команды разработчиков, но и для команды тестирования. Поскольку тестовый стенд – это не что иное, как платформа, предназначенная для тестирования программного обеспечения/продукта, его также можно назвать тестовой средой.
Любой тестовый стенд или тестовая среда должны быть настроены в соответствии с целями тестирования программного обеспечения. В этом случае тестовый стенд рассматривается как совокупность тестовой среды и тестовых данных.
Компоненты тестовой среды
Каждый тест имеет свои специфические требования к тестовой среде. Но в самом широком смысле любой тестовый стенд/тестовая среда будет состоять из аппаратного и программного обеспечения, а также сетевых компонентов.
Известный факт, что значительная часть времени тестировщика уходит на решение проблем с тестовой средой. А это, в свою очередь, влияет на производительность и сроки проведения тестирования. Хотя для каждой команды тестирования характерны свои проблемы, некоторые из них могут быть общими.
Основные проблемы, с которыми обычно приходится сталкиваться:
1. Удаленная среда
Тестовые среды чаще всего размещаются географически удаленно от команд тестирования. Это становится большой проблемой в случае возникновения любых неполадок, связанных с аппаратным обеспечением, прошивкой, программным обеспечением, сетями и т.д.
Поэтому тестировщикам приходится в значительной степени полагаться на команды поддержки в местах размещения тестовых сред. Это, в свою очередь, может отнять много времени в процессе тестирования и привести к срыву сроков, особенно в случае разницы в часовых поясах.
2. Совместное использование тестовых сред
Согласно общепринятой норме среда разработки, тестовая и продакшн среды должны быть разделены. Но обеспечивать ресурсами индивидуально каждую команду крайне невыгодно, поэтому в реальности такой идеальный сценарий достигается крайне редко. В результате команды разработки и тестирования чаще всего используют ресурсы одной и той же среды.
Следовательно, если разработчики и тестировщики конкурируют за одновременное использование одних и тех же ресурсов, это приводит к хаосу и разногласиям между участниками.
3. Неэффективное планирование использования ресурсов
В некоторых ситуациях возникает необходимость совместного использования ресурсов различными командами тестирования. В этом случае неэффективное планирование использования ресурсов помимо конфликтов между командами приводит также к нестабильности среды.
Следствием этого является то, что прогон одного и того же сценария может каждый раз приводить к различным результатам. Тогда велика вероятность того, что такой баг не будет принят разработчиком на исправление.
4. Сложная тестовая конфигурация
Иногда конфигурация тестового стенда или тестовой среды оказывается слишком сложной. Это создает ряд проблем, поскольку команде тестирования требуются необходимые навыки для её понимания. Но тестировщикам не всегда хватает базы знаний для работы с требуемой конфигурацией. В таких случаях они могут сами вызвать ошибки на тестовом стенде, неправильно настроив его. А это, в свою очередь, может сильно повлиять на результаты выполнения тест-кейсов.
5. Сложность настройки
В некоторых случаях для каждого тест-кейса может потребоваться слишком сложная настройка тестовой среды. Это может быть связано с наличием большого количества совместно используемых технологий. Ещё одной причиной может быть необходимость совместной работы нескольких компонентов в случае интеграционного тестирования.
В этом случае каждый из компонентов должен работать идеально, чтобы обеспечить стабильность результатов. Это связано с тем, что один компонент может формировать входные данные для следующего.
Лучшие практики настройки тестовой среды
Мы рассмотрели в общих чертах проблемы тестовой среды, с которыми сталкивается тестировщик до или в начале тестирования. Поскольку идеальных условий не существует, то эти проблемы, возможно, будут присутствовать и в будущем.
Поэтому ниже представлено несколько советов по эффективной настройке тестовой среды.
Совет 1. Повышение уровня знаний
Всегда начинайте с основ и с самого очевидного! А это изучение требований к продукту и подготовка детальных тест-кейсов. В данном случаем наилучшее решение – это включение в тест-кейсы подробной информации о тестовой среде. В то же время нет гарантий, что после этого тестировщик не потратит некоторое время на анализ того, какая тестовая среда и конфигурации могут потребоваться.
Этого можно избежать, пообщавшись с командой разработчиков для получения необходимой информации. Главным результатом будет обнаружение проблем с настройкой в самом начале цикла тестирования. Это, в свою очередь, даст время на поиск и получение необходимой помощи для устранения проблем. В результате чего время тестирования не увеличится.
Еще один положительных эффект – повышение уровня знаний команды тестирования и, как следствие, возможность избежать ненужных дефектов.
Совет 2. Проверка доступности ресурсов
Еще один важнейший пункт – убедиться в том, что ресурсы, которые вы собираетесь использовать для тестирования, доступны. В случае если система должна быть интегрирована с другими устройствами, проверьте их связь друг с другом с помощью ping или telnet.
Если системы должны взаимодействовать друг с другом и находятся за брандмауэрами, убедитесь, что они могут пройти аутентификацию через эти брандмауэры с помощью базовых опций безопасности (BSO). В этом случае также стоит проверить наличие прокси-серверов. Если вы заметили, что некоторые устройства недоступны или требуют аутентификацию через BSO, можно направить соответствующий запрос в службу поддержки.
Данный совет особенно полезен, когда тестовая среда находится в отдаленных локациях. Он также позволит заранее определить доступ для команды тестирования к какому-либо ресурсу или репозиторию.
Совет 3. Проверка сети и/или хранилища данных
Этот совет является практически продолжением предыдущего, но требует проведения более тщательных и глубоких проверок. Во-первых, убедитесь в том, что сеть имеет необходимую пропускную способность. Стоит также определить, требуется ли для проведения тестирования подключение к Интернету. Обязательно найдите способ проверить правильность сетевой топологии между устройствами.
Во-вторых, если цель тестирования предполагает необходимость в каком-либо хранилище, убедитесь в наличии хранилища и сетевого подключения. В основном это является обязанностью администратора, однако, наличие знаний в этой области будет являться большим плюсом.
Совет 4. Проверьте наличие необходимого аппаратного и программного обеспечения, а также лицензий
Часто случается так, что тестировщики приступают к работе, не проверив необходимое аппаратное и программное обеспечение, которое может потребоваться. В результате, уже в процессе тестирования они понимают, что определенная функциональность доступна только на более высоком уровне аппаратного или программного обеспечения.
В этом случае тестировщик отмечает блокирующий момент, который препятствует проведению дальнейшего тестирования. Поэтому нужно заранее делать записи о необходимом аппаратном и программном обеспечении.
Во многих случаях обновление аппаратного/программного обеспечения может быть сопряжено с простоями. Следовательно, тестировщик должен учитывать эти моменты при планировании.
Кроме того, для некоторых программных продуктов могут понадобиться лицензии, что может потребовать согласований и других действий со стороны юридического отдела. Этот процесс, возможно, займет несколько дней, поэтому его также необходимо планировать заранее.
Совет 5. Браузеры и версии
Тестирование, которое вы проводите, должно отражать действия конечного пользователя. Он в свою очередь может использовать любые браузеры и их версии. Поэтому, во-первых, необходимо определить различные типы браузеров, которые будут использоваться для тестирования, а также установить их локально.
Во-вторых, нужно решить, какие версии браузеров необходимы. Оптимальный вариант – начать с браузера более ранней версии, обеспечив тем самым обратную совместимость, а затем обновиться до последней версии.
Совет 6. Планирование использования тестовой среды.
Данный этап приобретает особую важность, когда несколько команд должны иметь доступ к одному и тому же набору ресурсов. Например, при проведении сквозного (end-to-end) тестирования. Кроме того, внутри одной и той же команды может быть несколько участников, у каждого из которых есть свои цели в рамках одной и той же настройки.
В этом случае одно из возможных решений – разработка подхода к разделению времени, при котором определенная команда или человек использует один и тот же набор ресурсов в первой половине дня, а остальные – во второй. В промежутке может быть время, где каждый из них может выполнять независимые тесты, которые не будут влиять на другие.
Это не только уменьшит хаос и конфликты между участниками, но и обеспечит стабильность тестовой среды на длительный срок.
Совет 7. Инструменты автоматизации и их конфигурации
При проведении тестирования не избежать регрессионных тестов, которые необходимо автоматизировать. Команда тестировщиков должна определить, какой вид автоматизации они хотели бы реализовать, а также выбрать и настроить необходимые для этого инструменты.
Однако, это не является обязательным условием для обеспечения готовности тестовой среды к тестированию.
Заключение
Приведенные рекомендации могут быть полезными для определения уровня готовности тестовой среды к проведению тестирования.
Несомненно, каждая команда сталкивается со своим уникальным набором проблем. Поэтому приведенные выше советы могут быть адаптированы и изменены в соответствии с потребностями определенной команды.
Перевод статьи «How To Effectively Prepare “Test Bed” And Minimize The Test Environment Defects (Part 1)».
Статья ни о чем