Есть когорта QA-специалистов, которые твердо уверены в том, что практика тестирования на рабочем сайте это не очень хорошо: с его помощью не получится предотвратить попадание ошибок конечным клиентам; это лишь банально констатирует их наличие. Также, тестировщик вынужден отрываться от классического рабочего процесса и методик проверки, которые он использует в повседневной практике.
Зачем нужно тестировать на рабочем сайте, если в тестовой среде все выглядит красиво и работает?
Традиционно, в процессе создания любого программного обеспечения должны быть развернуты несколько виртуальных окружений, в которых веб-продукт может одновременно разрабатываться и тестироваться.
Классическая система проверки ПО подразумевает создание отдельного окружения, чаще всего это называется QA environment (тестовая среда), где можно спокойно проверять доработанный или новосозданный функционал, и не бояться, что ошибки попадут к конечному пользователю.
Когда тестирование на рабочем сайте крайне необходимо?
Проблемы в различии тестового и рабочего окружений
Тестовая среда зачастую считается банальной копией рабочего окружения, которая не видна конечному пользователю, но максимально похожа на конечную версию продукта. Когда программное обеспечение очень сложное и большое, техническая поддержка такого веб-продукта становится очень трудоемким и финансово затратным процессом (и не всегда можно найти рациональность в подобной процедуре).
К примеру, есть проект, на котором на тестовой стадии используются объёмные тестовые сценарии для проведения функционального тестирования. Оно не обладает такой же технической базой как рабочий сайт, но это не мешает проводить функциональные тесты.
Почему не проще скопировать рабочую среду на тестовое окружение? Ответ очень прост: достаточно представить себе сколько необходимо ресурсов чтобы скопировать, допустим, Facebook, со всеми его мощными и производительными серверами. Фактически, потребуется развернуть копию такого же приложения. Это очень и очень дорого.
Также в этом случае стоит отдельно отметить то обстоятельство, что при интеграции с другими сервисами, пользователь получает различные настройки для тестирования и реального технического окружения (яркий пример – использование стороннего API).
Конечно же, говорить что тестовая среда бессмысленная вещь – не нужно. Просто никогда не будет 100% уверенности в том, что если проверки прошли успешно в тестовом окружении, они будут настолько же успешны в среде других сервисов.
Здесь на сцену как раз и выходит процесс тестирования в рабочей среде.
Настоящие многоуровневые задачи и технические сложности
Некоторую группу багов можно отыскать только после длительного отслеживания работоспособности системы на основе многозадачности и повышенной нагрузки.
Подобные ситуации касаются быстродействия системы, устойчивости ПО, стабильности его функционирования и потенциальных утечек памяти.
Проблемы при развертывании
Как известно, развертывание – это особый процесс установки корректно работающей новой версии ПО внутри инфраструктуры рабочей среды. Логично предположить, что наиболее оптимальный способ найти ошибки при развертывании – проводить процесс тестирования во время непосредственного развертывания.
Небольшой Итог
Все мы прекрасно понимаем, что все ошибки найти на рабочем сайте не получиться, и даже самое тщательное тестирование на тестовом не уберегает от багов в «боевой среде».
Если такие дефекты будут находить клиенты, это может негативно сказаться на репутации компании.
А значит, тестирование на рабочем окружении – «must-have» для любой уважающей себя QA организации!
Оставить комментарий