Шо,ни разу не случалось писать не зная что там будет?

Ни разу. Инфраструктура всегда заренее известна :) (там, где это имеет хоть какой-то смысл)

Может было хотя бы больше одной?

Больше одной БД? Был зоопарк БД от разных вендоров и там не имело значения что за БД "под капотом", т.к. с совтом от этих вендоров я общался через предопределенный интерфейс. Но в таких случаях вообще наплевать есть там БД или нет :)

А компостер там включали?

Нет, его не выключали.

Оставь скрипты и транспорт в покое - первых вообще нет - есть ОРМ, а второе УЖЕ признано рабочим
Но даже если принять его - работа тестера не предполагает фиксинга - только выявление проблем.

Так никто и не говорит, что тестер фиксит.

Тестер выявляет. А что нужно для выявления? - Нужно, чтобы тесты были повторяемыми и независимыми друг от друга. Добиться этого можно только одним способом - создавать новый среду перед каждым исполнением теста и после исполненения все нахрен удалять.

Т.е. перед началом теста БД должна быть девственно чиста и сначала ее заполнить необходимыми для конкретного теста данными. Можно конечно сделать это все в коде, но тут есть несколько минусов: 1) это долго ; 2) нужно читать код чтобы понять начальное состояние БД, т.е. у тебя там будет либо логика (и тогда ты не сможешь сразу однозначно сказать начальное состояние БД), либо будет огромное количество повторений кода (что усложнит сопровождение). Так что инициализировать БД удобнее SQL-скриптом (и поддерживать этот скрипт должен именно тестер).

Им осталось найти того кто сможет ЭТО грамотно описать.

Там все грамотно описано :) Это ты не умеешь читать :) Так что хорошо, что ты им не ответил - меньше работы по отсеву неадекватов :D