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

I>>Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.
·>Я не понимаю что ты хочешь сказать. Вроде начали с того, что некое гипотетическое изменение, о ужас, роняет 100500 тестов. И теперь их все надо фиксить. А то что вручную тоже _надо_ (хотя, конечно, можно и забить) проверить эти же 100500 случаев — ты не вспоминаешь. И да, падение 100500 тестов бывает обычно в приложении целиком.

цитирую себя "регрессию нужно детектить автотестами"
снова цитирую себя "новые баги ищутся только руками"

I>>Какие именно для тебя детали критичны — никто не знает.
·>Это уж вообще крутая отмаза. Так можно что угодно отмазать: и команда, сидящая этажом выше, и коллега за соседним столом, и "я вчерашний" — всё 3rd-party-like.

Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.

I>>Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.
·>Близкое к бесконечному количество кейсов автоматически тестировать на порядки проще. У нас более +10к функциональных тестов, включая всевозможные API и WUI, занимает ~25 минут на кластере... Вручную это займёт месяца два, полагаю.

API никто в своём уме в ручную не тестирует.
Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.

·>Понятно сейчас. Ты просто отвечал на вопрос который я не задавал, поэтому я и не понимал ответы. Я масштабы и так представляю. Не понимаю только зачем ты это упомянул. Ты, вроде, наоборот ручное тестирование защищаешь, а приводишь аргументы в пользу автоматического — чем больше масштаб, тем более эффективно авто, чем ручное.

Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?

I>>Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде
·>Разве неочевидно, что "кастомная схема навроде" никоим образом эвентами не является?

Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.

I>>Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.
·>Разные типы тестов имеют разные цели, средства, сильные и слабые стороны. Ты говоришь слишком общими словами, поэтому смысла никакого.

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

I>>Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
·>Разные задачи — разные решения. Не всё имеет смысл формализовать моделями.

Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.

I>>1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
·>В типичной разработке 90% ошибок — простейшие случаи. Этот узкий класс ошибок является самым массивным.

В типичной разработке ошибок становится больше в зависимости от сложности, при чем зависимость сильно нелинейная. И вот эту самую сложную часть тесты ловят хуже некуда.

Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".

I>>Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.
·>Чтобы всё это имело смысл сразу — нужно разрабатывать софт для Ядерных Реакторов с циклом релизов раз в 10 лет. Чтобы взять паттерн матчинг, надо чтобы у тебя была лапша if-else сразу, в 500-страничном фича-реквесте.

Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд

I>>Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.
·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.

Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
Изменилось требование "операция должна начинаться с А, включать Б, заканчиваться С" и теперь все авто-тесты которые имеют к этому отношение, надо взять и пределать, потому что они отвалились.

I>>·>Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.
I>>Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять.
·>Коммиты о затратах не говорят. Может корреляция и есть, но зависимости нет.

И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.

I>>Например я хочу знать наиболее проблемные компоненты.
·>Проблемность компонент смотрится в issue tracker. Я же говорю, что для проблем (issues) у нас есть issue tracker. А аннотации в коде — для разработки новых историй (фичи).

Вашего трекера недостаточно. Истории не с нуля пишутся, а с изменением и использованием кода готовых компонентов.

I>>Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.
·>У нас нет code ownership. Ещё мы часто в парах работаем...

А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.

·>А такие как в UI допустимые задержки позволяют и не знать о целом классе проблем.

Ты выйди в реальный мир и позапускай самый разный софт. Через одну софтины лагают и даже тормозят нещадно.
Твоё сравнение с сервером не работает. Ресурсы используются принципиально иначе.
На сервере ты никогда не вгружаешь вагоны данных целиком. Для UI это вобщем норма. Позволяет реализовать адские возможности в той же визуализации.

I>>·>В общем да, проблемы есть, и нетривиальные. Но всё решаемо.
I>>Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
I>>Следует ли из этого, что и самосвал песчинок ничего не весит ?
·>Они весят, но весят в другом месте, не там где мы измеряем.

Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."


I>>Глядишь, через 5-6 поколений архитектур приблизишься к успеху
·>DDR3 это пиковая 2666 MB/s (мегабайт в секунду), т.е. 20 гигабит в секунду, уже Ethernet 100-гигабитный не новость. Не знаю что ты такое насчитал или в каком поколении ты живёшь. Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
1 2666 это пиковая. Реальная много меньше
2 кроме UI есть и другие потребители шины
Более того, на данный момент в большинстве платформ тебе
1 не хватит адресного пространства
2 OS не сможет переварить данные если ап хватит
Итого — твои цифры взяты от балды.

I>>Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.
·>Логично, но именно 99% проблем когда берёшь либу, сабж в том числе, именно регрессия.

Это статистика от балды. По опыту предыдущих проектов, после перехода на новую версию UI либы тестеры всегда находили целую кучу _новых_ багов, при том что вендор гарантировал обратную совместимость. Что характерно, такие баги сложнее всего фиксить.

·>Что можно писать код не поддающийся авто-тестированию? Да запросто. Но правильная идея в том, чтобы так не делать. У нас любая история начинается с вопроса "а как мы это покроем тестами?"

А ты в курсе, что это _удорожает_ разработку ? Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?

I>>Если нет UI то мануальщику там делать нечего.
·>UI есть, и дофига. Но некоторые функции не вынесены в UI, аутентикация или аудит, например. И мануальщики тестируют очень просто, сам наблюдал: открывают SQL Console, копипастят из вордового документа запрос и долго тупят над ошибками если что-то пошло не так.

А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

I>>3. Ты снова забыл про разную цену ошибок
·>Для меня неочевидно, что ручное тестирование дешевле автоматического.

Потому что ты никак не поймешь — рич UI и серверный бакенд это две разные вселенные.
В UI у тебя никогда не будет четкого набора требований.
Постоянно будут изменения "подвинь, перенеси, убери, подкрасы, выдели"
Регулярно будут изменения "давайте попробуем новый flow" — вот это убивает все твои тесты.
Скажем, один скрин в визард добавить гарантировано ломает вообще все тесты для этого визарда.
Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.

I>>Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.
·>Я на 100% уверен, что у них на несколько порядков больше убитых на ранней стадии уродцев, чем доживших до вывода юзерам.

И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.

·>Далеко не всегда.
·>Классический пример — ну потопали американцы на пыль на булыжнике, ну воткнули там свой флажок, толку-то от этих уродцев-марсоходов?

Марсоходы как раз никакие не уродцы.

I>>Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.
·>Менеджеры — это не технология. Технология это их репозиторий и тулзы вокруг него.

Ога, так прям и вижу — дать тебе 2тб репу, так в в секунду любой компонент раздраконишь. Чтото мне кажется, будешь писать письма. Кому ? Девелопер может быть занят, ибо у него явный блокер от другой тимы. Итого — тебя поставили в очередь. Всё. Хочешь побыстрее — надо учиться писать письма вверх-вниз по стеку.

I>>А сетевой трафик это UI ? А место на диске ? А память ? А проц ?
·>Нет, но мне удивительно, что мануальные тестеры UI-аппликух приносят баги с невалидным json от сервера. Хо-хо! Мрак. Жуть. И тут кто-то мне рассказывал про протоколы, инварианты и формальные модели.

Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.

I>>Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно
·>Или новая либа стала куда-то лезть в интернет..

Открой для себя прокси-сервер.

I>>"Автоматизировать" человеческий фактор пока еще никто не научился.
·>Человеческий фактор можно минимизировать.

Это юзеров на софтварные модули заменить ? Интересная идея.

I>>Сначала ты сказал, что вторники никто не проверил. А оказалось, планировщик был не той системы. Жутко хитрый — это значит, что количество багов в коде примерно равно количеству багов в коде тестов.
·>Комбобокс кликался (что ж ему не кликаться — стандартный виндовый контрол), но неправильно функционировал в дальнейшем. А авто-тестов не было... Это было лет 15 назад, когда об этом и не слыхали.

Пудозреваю, дело совсем не в автотестах. Такие вещи сначала прокликиваются руками, а уже по результатам строятся авто-тесты.

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

I>>Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.
·>Я не понимаю что ты хочешь сказать. Вроде начали с того, что некое гипотетическое изменение, о ужас, роняет 100500 тестов. И теперь их все надо фиксить. А то что вручную тоже _надо_ (хотя, конечно, можно и забить) проверить эти же 100500 случаев — ты не вспоминаешь. И да, падение 100500 тестов бывает обычно в приложении целиком.

цитирую себя "регрессию нужно детектить автотестами"
снова цитирую себя "новые баги ищутся только руками"

Кроме того, UI обычно переделывается очень сильно. И очень часто — когда меняется вообще всё. Было "три радиобатона", стало "комбобоксы", потом "грид", потом "сложная многоуровневая форма", потом "explorer-like UI". И это только одна небольшая часть приложения.
С т.з. юзера все выглядит узнаваемо, с т.з. автотестов это АДъ и Израиль. Кажды раз тебе надо переписывать 100500 тестов.

I>>Какие именно для тебя детали критичны — никто не знает.
·>Это уж вообще крутая отмаза. Так можно что угодно отмазать: и команда, сидящая этажом выше, и коллега за соседним столом, и "я вчерашний" — всё 3rd-party-like.

Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.

I>>Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.
·>Близкое к бесконечному количество кейсов автоматически тестировать на порядки проще. У нас более +10к функциональных тестов, включая всевозможные API и WUI, занимает ~25 минут на кластере... Вручную это займёт месяца два, полагаю.

API никто в своём уме в ручную не тестирует.
Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.

·>Понятно сейчас. Ты просто отвечал на вопрос который я не задавал, поэтому я и не понимал ответы. Я масштабы и так представляю. Не понимаю только зачем ты это упомянул. Ты, вроде, наоборот ручное тестирование защищаешь, а приводишь аргументы в пользу автоматического — чем больше масштаб, тем более эффективно авто, чем ручное.

Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?
Или наоборот — всё зеленое, а UI надо переделывать, ибо выглядит коряво. Переделываем форму... и твои тесты отвалились все до единого. А живому человеку — пофигу.

I>>Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде
·>Разве неочевидно, что "кастомная схема навроде" никоим образом эвентами не является?

Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.

I>>Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.
·>Разные типы тестов имеют разные цели, средства, сильные и слабые стороны. Ты говоришь слишком общими словами, поэтому смысла никакого.

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

I>>Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
·>Разные задачи — разные решения. Не всё имеет смысл формализовать моделями.

Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.

I>>1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
·>В типичной разработке 90% ошибок — простейшие случаи. Этот узкий класс ошибок является самым массивным.

В типичной разработке ошибок становится больше в зависимости от сложности, при чем зависимость сильно нелинейная. И вот эту самую сложную часть тесты ловят хуже некуда.

Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".

I>>Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.
·>Чтобы всё это имело смысл сразу — нужно разрабатывать софт для Ядерных Реакторов с циклом релизов раз в 10 лет. Чтобы взять паттерн матчинг, надо чтобы у тебя была лапша if-else сразу, в 500-страничном фича-реквесте.

Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд

I>>Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.
·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.

Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
Изменилось требование "операция должна начинаться с А, включать Б, заканчиваться С" и теперь все авто-тесты которые имеют к этому отношение, надо взять и пределать, потому что они отвалились.

I>>·>Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.
I>>Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять.
·>Коммиты о затратах не говорят. Может корреляция и есть, но зависимости нет.

И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.

I>>Например я хочу знать наиболее проблемные компоненты.
·>Проблемность компонент смотрится в issue tracker. Я же говорю, что для проблем (issues) у нас есть issue tracker. А аннотации в коде — для разработки новых историй (фичи).

Вашего трекера недостаточно. Истории не с нуля пишутся, а с изменением и использованием кода готовых компонентов.

I>>Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.
·>У нас нет code ownership. Ещё мы часто в парах работаем...

А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.

·>А такие как в UI допустимые задержки позволяют и не знать о целом классе проблем.

Ты выйди в реальный мир и позапускай самый разный софт. Через одну софтины лагают и даже тормозят нещадно.
Твоё сравнение с сервером не работает. Ресурсы используются принципиально иначе.
На сервере ты никогда не вгружаешь вагоны данных целиком. Для UI это вобщем норма. Позволяет реализовать адские возможности в той же визуализации.

I>>·>В общем да, проблемы есть, и нетривиальные. Но всё решаемо.
I>>Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
I>>Следует ли из этого, что и самосвал песчинок ничего не весит ?
·>Они весят, но весят в другом месте, не там где мы измеряем.

Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."


I>>Глядишь, через 5-6 поколений архитектур приблизишься к успеху
·>DDR3 это пиковая 2666 MB/s (мегабайт в секунду), т.е. 20 гигабит в секунду, уже Ethernet 100-гигабитный не новость. Не знаю что ты такое насчитал или в каком поколении ты живёшь. Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
1 2666 это пиковая. Реальная много меньше
2 кроме UI есть и другие потребители шины
Более того, на данный момент в большинстве платформ тебе
1 не хватит адресного пространства
2 OS не сможет переварить данные если ап хватит
Итого — твои цифры взяты от балды.

I>>Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.
·>Логично, но именно 99% проблем когда берёшь либу, сабж в том числе, именно регрессия.

Это статистика от балды. По опыту предыдущих проектов, после перехода на новую версию UI либы тестеры всегда находили целую кучу _новых_ багов, при том что вендор гарантировал обратную совместимость. Что характерно, такие баги сложнее всего фиксить.

·>Что можно писать код не поддающийся авто-тестированию? Да запросто. Но правильная идея в том, чтобы так не делать. У нас любая история начинается с вопроса "а как мы это покроем тестами?"

А ты в курсе, что это _удорожает_ разработку ? Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?

I>>Если нет UI то мануальщику там делать нечего.
·>UI есть, и дофига. Но некоторые функции не вынесены в UI, аутентикация или аудит, например. И мануальщики тестируют очень просто, сам наблюдал: открывают SQL Console, копипастят из вордового документа запрос и долго тупят над ошибками если что-то пошло не так.

А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

I>>3. Ты снова забыл про разную цену ошибок
·>Для меня неочевидно, что ручное тестирование дешевле автоматического.

Потому что ты никак не поймешь — рич UI и серверный бакенд это две разные вселенные.
В UI у тебя никогда не будет четкого набора требований.
Постоянно будут изменения "подвинь, перенеси, убери, подкрасы, выдели"
Регулярно будут изменения "давайте попробуем новый flow" — вот это убивает все твои тесты.
Скажем, один скрин в визард добавить гарантировано ломает вообще все тесты для этого визарда.
Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.

I>>Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.
·>Я на 100% уверен, что у них на несколько порядков больше убитых на ранней стадии уродцев, чем доживших до вывода юзерам.

И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.

·>Далеко не всегда.
·>Классический пример — ну потопали американцы на пыль на булыжнике, ну воткнули там свой флажок, толку-то от этих уродцев-марсоходов?

Марсоходы как раз никакие не уродцы.

I>>Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.
·>Менеджеры — это не технология. Технология это их репозиторий и тулзы вокруг него.

Ога, так прям и вижу — дать тебе 2тб репу, так в в секунду любой компонент раздраконишь. Чтото мне кажется, будешь писать письма. Кому ? Девелопер может быть занят, ибо у него явный блокер от другой тимы. Итого — тебя поставили в очередь. Всё. Хочешь побыстрее — надо учиться писать письма вверх-вниз по стеку.

I>>А сетевой трафик это UI ? А место на диске ? А память ? А проц ?
·>Нет, но мне удивительно, что мануальные тестеры UI-аппликух приносят баги с невалидным json от сервера. Хо-хо! Мрак. Жуть. И тут кто-то мне рассказывал про протоколы, инварианты и формальные модели.

Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.

I>>Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно
·>Или новая либа стала куда-то лезть в интернет..

Открой для себя прокси-сервер.

I>>"Автоматизировать" человеческий фактор пока еще никто не научился.
·>Человеческий фактор можно минимизировать.

Это юзеров на софтварные модули заменить ? Интересная идея.

I>>Сначала ты сказал, что вторники никто не проверил. А оказалось, планировщик был не той системы. Жутко хитрый — это значит, что количество багов в коде примерно равно количеству багов в коде тестов.
·>Комбобокс кликался (что ж ему не кликаться — стандартный виндовый контрол), но неправильно функционировал в дальнейшем. А авто-тестов не было... Это было лет 15 назад, когда об этом и не слыхали.

Пудозреваю, дело совсем не в автотестах. Такие вещи сначала прокликиваются руками, а уже по результатам строятся авто-тесты.