Позволю немного прокомментировать

Если у людей нет желания делать свою работу хорошо, то совершенно неважно, разработчики они или тестировщики, проблема в людях, а не в профессии.

Показатели "хорошей работы" в разных компаниях свои. Процент рекламаций, "объем" кода, отсутствие просроков и т.д. Что важно компании - тех и набирают.
Бывает, что приоритеты компании меняются.

Желание делать то, что ты делаешь, лучше, и начисто с минимума попыток, а не переделывать сто раз - оно вполне естественное.

Думаю, только жуткие пессимисты исходно сразу думают, что сделают задание с 5-го, 10-го ... раза.
Остальные же будут надеяться на первую и единственную итерацию. :-)

Так не могут или не хотят? Разбираться, почему не могут и решать эти проблемы.

По большому счету, не так важно, не могут или не хотят. Ведь если руководство спрашивает с них это, то "откуда ни возьмись" находится и желание, и возможность.

И наоборот, если НЕ спрашивать тесты с них, то сами юнит-тесты, опять же, "откуда ни возьмись" не появятся.

Решать проблемы программистов - точно не задача тестировщиков.

 

А если везде пропагандируется, что программисты и тестироващики должны "работать заодно", то вот после момента вопрошания у руководства "что-ж у нас качество такое плохое", боюсь, может возникнуть некоторый конфликт с этими самыми разработчиками.

А юнит-тесты за разработчиком лучше ревьюить! Причем даже за хорошим разработчиком :)
А то всякое бывает, напишут три тестика и типа спокойны :)

 

А что делать, если разработчики не могут (или не хотят) писать тесты. Ведь есть тестировщики - пусть они и проверят, и тесты создадут. И приходится смотреть (а иногда и ревьюить) код, чтобы "черный ящик" не угадывать.

Я думаю, существует такой момент: есть "качество выпускаемого продукта" и "качество архитектуры и написания кода продукта" (надеюсь формулировки понятны)

 

На "качество выпускаемого продукта" тестировщики повлиять могут, и чем они квалифицированнее - тем больше: большинство (или все) критические ошибки и часть менее критических будет выявлена и отдана на исправление программистам (что успеют - то исправят, тут уже не забота тестировщиков).

 

Но на "качество архитектуры и написания кода продукта" тестировщик практически не может повлиять, если результаты тестирования не обрабатываются отделом программирования и руководством.

 

Возможно, при участии тестировщиков на ранних этапах составления ТЗ качество кода растет - пока лично такого не замечал еще ( а заметил, что ТЗ к исполнителю может придти в таком виде, что не приходится удивляться отчего возникают "непредвиденные" сценарии, приводящие к сбоям).

 

Думаю, именно с этим связано "разочарование" у leftCh - как бы плохо ни писал код программист, но тестировщик "всего лишь" проверяет написанное, "для этого он и взят на работу". Наверно из-за этого и отношение ЗП у программистов и тестировщиков соответствующее.

 

Когда руководителю придет осознание, что качество кода - в основе, а тесты - для "подтверждения, что все хорошо" , может и тестировщики даже не понадобятся?  :-)

 

Quality Assurance - Уверенность в качестве - так называется эта профессия по-английски. А не BugFinder )

Мы это делаем не потому, что это реально круто-удобно-хорошо, а потому что других способов нет.

 

Как мне кажется, тестирование через интерфейс приложения - один из видов желательного тестирования, но не панацея от необходимости иных видов тестирования.

Точнее, чтобы покрыть только тестами через интерфейс приложения потребуется более сложные и в большем количестве тесты, чем если бы функционал тестировался бы и иными видами тестов.