Это происходит от перспективы разработчика, а не от тестера, поэтому может применяться или не применяться.
Я не могу говорить об организации в целом, но в нашем проекте мы потратили некоторое время на создание «реальных данных», которые мы загружаем в тестовую базу данных с использованием SQL-скриптов. Эти данные представляют собой комбинацию реальных данных из производственной среды и данных, которые предназначены для представления конкретных «проблемных ситуаций» в нашем продукте.
Сценарии запускаются автоматически как часть построения нашего программного обеспечения и используются автоматическими интеграционными тестами, управляемыми модульной схемой тестирования. Эти тесты будут проверять поиск, создание, редактирование и удаление данных через различные доступные интерфейсы.
Во время такой сборки и тестирования тестовая база данных несколько раз перезагружается и повторно загружается данными. Это делается для того, чтобы удалить зависимости между тестами; один тест не должен полагаться на данные, созданные или измененные другим тестом, а также потому, что данные для некоторых тестов могут отличаться от данных других тестов. Однако большинство тестов выполняется на основе тех же данных теста.
Настройка этих тестовых данных (и их поддержание) была (и иногда) несколько головной болью, но в конечном итоге она хорошо работала в нашем случае.