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

I>>Контроль качества нужен ради этих самых гарантий
S>Контроль — это процесс. А гарантии — необязательный результат этого процесса.

Гарантии это цель ради которой проводится этот процесс.

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

I>>А это примерно оно и есть. Кавалерийскими атаками эта задача не решается. Это долговременная активность, не только exploratory, а ручное вообще.
S>Да нечего там особо руками делать. Только если сценарии писать.

Это принципиально ничего не меняет. Ну не отсылаются запросы мышом, и с клавиатуры их не набирают

S>>>Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

I>>Так контроль нужен ради гарантий У вас только п.2.
S>У нас не только п.2. У нас только лишь нет кадра, на 100% занятого тестами. И даже на 30%.

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

I>>6. что с суппортом-траблшутингом — не ясно, кто это делает
S>Вместо саппорта мануал по эксплуатации. В нашем случае справляется.



I>>Фактически, ваш проект скорее всего, на мой взгляд, находится в очень хрупком равновесии. Сильно вряд ли вы можете легко и быстро заполнять вакансии, адаптироваться к новым условиям, колебаниям рынка, изменению требований и тд.

S>Наш проект пережил много таких проектов.

Пережил — это больше про спрос и соотношение цена/качество. Чем выше спрос, тем хуже может как цена/качество, так и само качество.

>Но я не очень понимаю, что именно ты предлагаешь? Видимо, создать отдел кадров для начала?

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

I>>Если вы их ищете время от времени, то результат будет соответствующий.

S>Результат пока нас устраивает.

Так про то и речь

I>>Разумеется. При этом разделение труда это естественный подход к увеличению эффективности.
S>Конечно. Но вместе с трудом придется разделять и мотивацию к нему.

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

I>>Как я могу такое утверждать, если мне неизвестна ваша система?
S>Я думаю, что дал достаточно данных что бы утверждать, что ручной тестировщик не выход в данной ситуации.

Ощущение, будто у тебя такая картина — тестировщик отсылает http запрос мышом набирая его с клавиатуры

Ручное, это значит, что сценарий и результат, определяет тестировщик в момент тестирования. А какими средствами он пользуется — мышом, клавиатурой, скриптами, вспомогательными приложениями, мониторингом, специальной админкой — дело десятое.
Например — задеплоили x для заказчика y на z виртуальных машин, дали нагрузку в половину рабочей. Ожидаем, что счетчики будут такие то и такието. Если нет, изыскиваем причины, уочняем, меняем сценарий.
Или так — при повышении нагрузки добавляем новые ноды для процессинга, при уменьшении — убираем. Проверяем, насколько эффективно это работает, соответствует ли нашим требованиями.
Или так — запретить масштабирование, проверить, как именно деградирует производительность при взрывном росте нагрузки, соответсвует ли ожиданиями.

Очевидно, что такие вещи тестировщик делает не руками. Но сценарий и ожидания новые, ранее не зафиксированы ни одним из авто-тестов.