leftCh

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

> А пожарных, которые не тушат постоянно пожары, нужно уволить...

> Ответ дал много лет назад Ашманов: "Бессмысленно муштровать исполнителей, нужно муштровать менеджеров."

Я говорила кого-то муштрировать или увольнять? Нет.

> Да, если вы не согласны, предлагаю сыграть в "сбалансированную производственную цепочку".

Не то чтобы не согласна. Просто поделилась наблюдением. А у вас был другой опыт? Когда тестировщики при загрузе 75% сию же минуту начинали работать над упавшими в очередь задачами?

> Офигенный вывод. Прям как у свидетелей иеговы. "Вы заболели грипом, значит надо верить в автотесты".

> Л - Логика!

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

TDD, автор, слабо?

Ожидания у автора неадекватные Ручное тестирование  - это не этап компиляции Проект они задерживают... А может проект задерживает низкое качество кода, который приходится пинать туда-сюда между тестировщиком и программистом?

С "бездельничающими" тестировщиками есть нежелательный побочный эффект. Если задач мало и тестировщик понимает, что успеет выполнить  все и еще время останется, он, видимо из-за своих человеческих слабостей , начинает работать медленнее. Мало-помалу он привыкает к новому расслабленному ритму и нормальная нагрузка начинает восприниматься как "перегруз" :) Так что, наверное, стоит воспринимать задержку при ручном тестировании как неизбежное зло. Выход - делать автотесты.

Предположим ваша программа работает с "тяжелыми" операциями по обновлению данных, помещая их в очередь, оттуда другой процесс/поток их берет и обрабатывает. На пиковых нагрузках ответ по тяжелой операции может прийти спустя, ну пусть, 5 минут. Как мотивировать сервер на результат, чтобы отклик не привышал 30 секунд при любых нагрузках?

Ах ну да, пользователей очереди не много, примерно 25