>Зарплата инженера тестера по уровню должна быть такая же {и выше} как и программиста которого он проверяет.
>Другое дело в России пока нет института тестирования и соответственно нет квалифицированных спецов.
Бред. Писание тестов на работоспостобность - самая простая работа, ей занимаются подмастерья-мальчики 16 лет. Платят им вполне по заслугам. Тестировщики, выполняющие ручное тестирование - просто красноглазые, ленивые, необразованные геймеры. Им ввобще платить - не знаю за что. Они и так на монитор фапать согласны.
Нормальный профессионал пишет тесты всегда. Однако не столько для того, чтобы умиляться правилностью работы кода, а для того, чтобы синтезировать дизайн той или иной части системы. UML позволяет набросать дизайн и оценить его состоятельность ещё до того, как будет написана хоть строчка кода, но круг задач, решаемых с помощью диаграмм, сильно ограничен. Средствами UML невозможно выразить средства языка и используемые технологии, UML не поддерживает аспекты и уж тем более метаатрибуты, с помощью UML невозможно описать систему, ряд слоёв которой генерируется утилитами. В то же самое время, UML - самое развитое средство разработки ОО-дизайна. TDD позволяет получить дизайн системы прямо "на месте", она лишена недостатков, перечисленных выше, она позволяет использовать все возможности языка и технологии. Разработчик просто обязан писать тесты "вначале".

Mr MarmeladВы канешна же не правы - разработка и тестирование - совершенно разные вещи.Дабы не вводить в заблуждение туманностью вышесделанных высказываний, навеянных разноплановостью обсуждаемой в топике тематики, раскрою свою мысль на примере.
У нас: отдел планирования разрабатывает дизайн новой системы и определяет технологии, используемые в ней, отдавая всё это на разработку в виде спецификаций. Дизайн логический системы предоставляется, как правило, в достаточно общем виде, на уровне взаимодействия пакетов и ключевых абстракций в них. Конкретный вид дизайн системы приобретает в процессе именно разработки, а не планирования. Делается всё это с помощью разработки через тестирование. Прежде, чем ввести в систему новую функциональность, определяется набор правил, задающих смысловую нагрузку вносимых изменений, а также необходимые для этого модификации дизайна системы (в нулевом приближении). По этим правилам пишутся автоматические тесты, вооружившись которыми, можно начинать "причёсывать" систему и прикручивать новую фичу в положенное ей место. Продолжая процесс итеративно, получаем максимально гибкий дизайн, оставаясь в рамках спецификаций и области действия решения, сдаём релизы вовремя. Вот это - TDD.
Далее, там, где вносимая функциональность не влияет на дизайн, также пишутся автоматические тесты, диктуемые вариантами использования. Это - рутина, и сплавляется она самым молодым и бесполезным участникам проекта, поскольку, как правило, ничего более полезного они делать не умеют. Затем систему отдаём на ручное тестирование. Там сидят красноглазые подростки, думающие, что если они работают в IT-компании, то от этого они становятся мене бездарными. Их задача - колупать приложение до тех пор, пока что-нибудь не упадёт (всего-то!). При падении команде разработчиков приходит отчёт и порядок воспроизведения ошибки. Автор сбойного кода (впрочем, бывает, что и тот, кто просто оказался рядом) анализирует падение, запрягает юнгу писать тест, повторяющий имеющийся сценарий, исправляет ошибку и инициирует новую сборку. Всё.
Теперь скажите, почему же, на Ваш взгляд, тестировщики - это элита, которой д о лжно платить столь сказочные зарплаты?
Mr MarmeladВот давайте я Вам прведу пример - Вы в какой среде работаете? Назовите продукт в Котором Вы себя считаете спецом?Извольте, интересно :) Например, я вольготно чувствую себя в процессе разработки приложений на платформе Microsoft .net (применяю почти все связанные с ней технологии).