По сравнению с использованием среды DEV для тестирования даже при том, что это имеет последний код
Я хочу знать то, что является профессионалами и доводом "против", если QA имеет их собственную Тестовую среду. Как это должно работать? Кто должен сделать развертывание на нем? Это должно иметь последний код? Как это приносит пользу QA или разработчикам, или это приносит пользу кому-либо?
На ум приходят несколько мыслей:
Фундаментальный принцип, лежащий в основе тестирования QA, заключается в том, что QA-специалист не должен иметь предвзятых представлений о том, что вы сделали в коде.
Если бы программисты объективно относились к собственному коду, вам не понадобился бы отдельный отдел контроля качества.
Отдельная среда также позволяет QA проверять проблемы установки и выполнение всех требований к программному обеспечению.
Обычно вы настраиваете отдельную среду контроля качества, потому что вы хотите предоставить тестировщикам изолированную среду для тестирования, чтобы разработчики и тестировщики могли работать в в то же время.
Среда DEV, как правило, нестабильна, что очень затрудняет QA прохождение всего цикла тестирования, особенно регрессионного тестирования. Если отдел контроля качества попытается провести полный регрессионный тест в системе, которая постоянно меняется, им будет невозможно достоверно заявить, что все функции «работают» в любой момент времени.
Я не вижу недостатков в наличии отдельных сред. В идеале, разве у каждого человека не было бы одной или нескольких сред своих , которые он мог бы использовать по своему усмотрению? Зачем ограничивать обе группы, заставляя их совместно использовать одну среду?
DEV - это место, где разработчики собирают свой код вместе. Вполне вероятно, что DEV находится в постоянном состоянии текучки. В то время как QA должен быть немного более стабильным. Таким образом, QA с меньшей вероятностью столкнется с кодом, который еще не готов, а разработчики смогут собрать свой код для тестирования до того, как QA получит его в свои руки.
Предоставление им собственной среды означает, что они могут избежать проблем с ее работой на моем компьютере. Они могут выполнить чистую установку, и она не удастся, если у них нет DLL или других требований, которые могут быть доступны в коробке разработчика. Сейчас есть несколько причин не делать этого, хотя бы через виртуализацию. Как указывает ваш вопрос, они и ваши клиенты вряд ли будут работать на переднем крае вашего дерева разработки. но помеченный релиз, который на несколько версий отстает от разработки.
Для нас мы делаем запланированные релизы в среду "QA", в то время как мы продолжаем разработку в нашей среде разработки. Таким образом, не происходит дублирования, и они имитируют реальную пользовательскую среду.
Помимо прочего, уже упомянутого в этой статье, одним очень важным аспектом является то, что вы можете протестировать развертывание кода, имея отдельная среда тестирования. Например, если есть важное изменение конфигурации (например, требуется обновление системной библиотеки или новая таблица базы данных), вам необходимо протестировать это, прежде чем переносить код в производственную среду.
При развертывании кода от разработчика к тестированию вы можете автоматически проверить, все ли зависимости / изменения конфигурации учтены. Для этого важно, чтобы среда тестирования была как можно ближе к производственной среде.