эти хрупкие автотесты

Ни для кого не секрет, что одним из обстоятельств, удерживающих некоторых от создания gui-шных автотестов по типу Selenium-овских , является большая вероятность написания хрупких (fragile) тестов. И действительно , для подобного вида тестов вероятность получить хрупкий тест более высока, чем для других видов.

Посмотрим, что же делает подобные тесты хрупкими:

1. Несогласованность с разработчиками. Зачастую тестировщику-автоматизатору достается интерфейс и функционал мало пригодный для "нехрупкой" автоматизации. Например (Если говорить о web), беспорядочное отношение к именованию контролов, присовению идентификаторов важным контейнерам, таблицам и т.д. В данной ситуации необходима совместная выработка общих правил и дальнейшее соблюдение соглашений. Разработчики любят хорошие ТЗ для того, чтобы было "комфортно" программировать, а тестировщики любят предсказуемый код и интерфейсы, которые "комфортно" автоматизировать.
2. Бездумное использование "записанных" тестов. Тут лучше привести пример. Есть таблица со списком объектов из БД. Гипотетический тест проверяет то, что она содержит запись об определенном объекте. Записывалка тестов генерирует код, который ищет нужную ячейку с текстом по xpath локатору с явным индексами tr и td. Тестировщик использует сгенерированный код без изменений и через некоторое время получает провал теста. В чем дело? А просто список объектов пополнен новым и старый сдвинут. Или разработчик выводит список без сортировки и СУБД вдруг "сфетчила" записи в новом порядке. Тут, конечно, можно запросить "поддержку тестирования" в виде добавления сортировки. Но правильнее сначала отредактировать локатор , убрав индексы (если, конечно, соблюдение порядока следования записей не критично), ну а потом можно и сортировку попросить.. для предсказуемости )
3. Часто меняющиеся требования к продукту. Тут уж никуда не деться от переделывания тестов. Рынок диктует свои условия. Поменялись требования, поменялся функционал / внешний вид , меняются тесты. Если подобные правки слишком часты и накладны, то стоит подумать о том, чтобы отказаться от автоматизации данного участка.
4. Плохой дизайн тестов. Тестируемая система не менялась,  а тест то и дело проваливается. Причиной может послужить недостаточно вдумчивое проектирование теста, не учитывающее возможное изменение тех или иных внешних по отношению к тесту условий при неизменности тестируемого функционала. Грубо говоря, тестировщик создал код , похожий на тот, что создают "записывалки". Рекордеры ничего не "знают" об особенностях, которые обязан знать и учитывать автоматизатор.

Наверняка, можно еще добавить несколько пунктов. Но навскидку - приведенные кажутся мне основными.