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

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

I>>>Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
S>>Отсутствие контроля качества и гарантия качества — это не одно и то же.

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

I>>>Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
I>>>Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
I>>>Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.
S>>Отсутствие кадра, "кто бы на 100% времени занимался exploratory тестированием" не означает что никто вообще ничего никогда не проверяет.

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

I>Что у вас за софт такой ?
Корпоративная клауд файлопомойка

I>>>Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
I>>>1 новых багов нет (поиск не прекращался)
I>>>2 регрессии нет (все найденые пути-кейсы автоматизированы)
S>>Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

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

I>Вполне возможно, у вас как раз тот случай, что хорошо ложится на автотесты. Но таких проектов вообще говоря меньшинство.
I>Если у вас ажно три коммитера, это значит, что
I>1. обязанности тестеров-мануальщиков ложатся на этих трех (проектирование тестов, планирование тестирования)
I>2. обязанности тестеров-автоматизаторов ложатся на этих трех (автоматизация ключевых тест-кейсов)
I>3. нагрузочное тестирование ложится так же на этих трех
I>4. автоматизация инфраструктуры так же ложится на этих трех (опс, девопс и тд)
I>5. огромная куча рутинных задач, коих всегда около 80%, ложится на этих трех
Упс, не слышал. Наверное, те двое, кто не я, этим занимаются.
I>6. что с суппортом-траблшутингом — не ясно, кто это делает
Вместо саппорта мануал по эксплуатации. В нашем случае справляется.

I>То есть, уже в наличии совмещение большого количества ролей. Чем больше ролей совмещается, тем хуже эффективность.
I>Далее, если один разработчик решил уйти-заболеть-умереть-переехать, найти замену становится очень трудно. Тестировщики страхуют проблем при таких вот поворотах.
С уйти-заболеть-умереть согласен. Но переехать — не такая уж и проблема сегодня.
I>Далее, для вас затруднителен вариант "взять миддла-студента на вырост", т.к. такой человек может и будет вносить хаос, а контроль достаточно слабый, т.к. все держится именно на квалификации этих трех.

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

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

I>Тестировщики не гарантируют, что найдут все баги. Правильный процесс о другом — все что можно найти найти в течение разработки, будет найдено. Для этого, в частности, нужно exploratory тестирование, т.е. поиск новых багов.
I>Если вы их ищете время от времени, то результат будет соответствующий.

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

I>Если вам нужные еще и нагрузочные тесты, это отдельная песня. Что бы внятно представлять вашу ситуацию, нужно хоть как то взглянуть на неё
Думаю, это лишнее.

I>>>Живой человек вполне себе может пользоваться полуавтоматическими средствами и пытаться зацикливать всё, что угодно.
S>>С этим сложно спорить, т.к. разработчик тоже живой человек.

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

S>>Выше писал. 1-2 месяца работы 10К клиентов могут выявить баг. А могут и не выявить. Чему будет равно x-часов вручную у тестировщика?

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