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

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

S>>Контроль — это процесс. А гарантии — необязательный результат этого процесса.

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

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

S>>Да нечего там особо руками делать. Только если сценарии писать.

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

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

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

Мы их не ищем, они нас сами находят ))) На самом деле, часть будущих проблем видно на этапе разработки.

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

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

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

Уж какой проект есть. Надеюсь, бенефиты я продемонстрировал.

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

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

S>>Конечно. Но вместе с трудом придется разделять и мотивацию к нему.

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

Так делается, когда продукт дядин. Будут проблемы — наймем кого надо и он будет делать то, что надо, а не то, что ему интересно.

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

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

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

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

I>Очевидно, что такие вещи тестировщик делает не руками. Но сценарий и ожидания новые, ранее не зафиксированы ни одним из авто-тестов.
Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.