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

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

Контроль качества нужен ради этих самых гарантий

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

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

Что у вас за софт такой ?

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

Так контроль нужен ради гарантий У вас только п.2.

Вполне возможно, у вас как раз тот случай, что хорошо ложится на автотесты. Но таких проектов вообще говоря меньшинство.

I>>Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
I>>Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.
S>Определенные баги вылазят при активной эксплуатации на 10К машин за месяц-два. И стреляют 1-2 раза. Такие не найдешь с помощью 3х нормальных тестировщиков, если мы говорим о тестировании руками. А нормальные тестировщики, которые будут писать код для стресс нагрузок, полагаю, могут стоить подороже некоторых нормальных разработчиков.

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

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

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

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

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

Как я могу чего либо утверждать, если мне неизвестна ваша система?

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

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

Контроль качества нужен ради этих самых гарантий

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

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

Что у вас за софт такой ?

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

Так контроль нужен ради гарантий У вас только п.2.

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

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

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

I>>Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
I>>Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.
S>Определенные баги вылазят при активной эксплуатации на 10К машин за месяц-два. И стреляют 1-2 раза. Такие не найдешь с помощью 3х нормальных тестировщиков, если мы говорим о тестировании руками. А нормальные тестировщики, которые будут писать код для стресс нагрузок, полагаю, могут стоить подороже некоторых нормальных разработчиков.

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

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

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

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

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

Как я могу такое утверждать, если мне неизвестна ваша система?