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

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

S>>Кто же против? Мой тезис в другом: парадигма при прочих равных может иметь не только минусы.

I>Может, но мне кажется что это всегда зависит от задачи.
Конечно

S>>Опа, из отсутствия такого кадра, кто бы на 100% времени занимался exploratory тестированием и выделенных тестировщиков не следует отсутствие контроля качества.

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

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

S>>Выделенные тестировщики и exploratory тестирование не помогут решить это эффективным образом. Т.е. ресурсы, спущенные на это будут значительные, но радикальное улучшение качества обновлений это вряд ли повлечет. Те сценарии, которые автотест прогоняет за пол часа, живой человек будет гнать столько времени, что за это время выйдет еще пара релизов.

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

>>Не говоря о том, что бы зациклить что-то, что бы убедиться в отсутствии гонок.

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

>>Да, конечно, он сможет заметить что-то, проверка чего в сценарий не заложена.

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

I>Другое дело, если у вас сервис, где нет особой интерактивности — такие вещи хорошо тестируются авто-тестами. Но в сложных больших системах даже здесь выделяют АПИ-тестировщиков.

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

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