Здравствуйте, samius, Вы писали:

I>>Так в том то и дело — оптимизировать нужно узкое место, а это в большинстве случаев далеко не парадигма.
S>Кто же против? Мой тезис в другом: парадигма при прочих равных может иметь не только минусы.

Может, но мне кажется что это всегда зависит от задачи.

I>>Если это какой нибудь сервис, где интерактива немного и он не завязан непосредственно на деньги, то бывает. Но в общем случае это не работает — отсутствие выделеных тестировщиков говорит о том, что контроля качества нет.
S>Опа, из отсутствия такого кадра, кто бы на 100% времени занимался exploratory тестированием и выделенных тестировщиков не следует отсутствие контроля качества.

Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.

Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
1 новых багов нет (поиск не прекращался)
2 регрессии нет (все найденые пути-кейсы автоматизированы)

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

Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.

>Не говоря о том, что бы зациклить что-то, что бы убедиться в отсутствии гонок.

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

>Да, конечно, он сможет заметить что-то, проверка чего в сценарий не заложена.

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

Другое дело, если у вас сервис, где нет особой интерактивности — такие вещи хорошо тестируются авто-тестами. Но в сложных больших системах даже здесь выделяют АПИ-тестировщиков.

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

Далее — принятие решения о том, что фича закончена, не у девелопера, а у тестировщика, который потратил x-часов вручную и убедился, что всё хорошо. А вот далее идет автоматизация, по ключевым точкам.