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

I>>Именно, плановая, систематическая, цель которой — гарантированное подтверждение. Если ты не достиг цели, о качестве вообще нет смысла говорить. А если достиг, то у тебя есть точные сведения о том, какое именно качество — высокое, низкое, среднее. И если цель не достигнута, то процесс строится так, что бы получить внятное обоснование, где препятствие и как его устранить.
S>Ну, а что если цель достичь подтверждения в 2050-м году?

Значит до того говорить про качество смысла никакого нет. И про бенефиты от парадигмы — тоже

I>>Если вдруг обнаруживается, что цель недостижима, то ты получаешь гарантию — установить качество не представляется возможным.
S>И как ты обнаружишь что цель недостижима? Вот я буду 1 день в году посвящать плановой и систематической деятельности, цель которой — гарантированное подтверждение соответствия. В соответствии с определением — это и есть контроль качества. Но ты еще требуешь достижимости. Вот и доказывай теперь, почему такая деятельность не ведет к достижению.

Ты снова всё хочешь к определению привести Эти вещи, очевидно, следуют из бизнес процессов, а не из головы. В т.ч. и слова "систематически". Например, в трудовом законодательство это два и более раза год.

>И почему наличие кадра, который 100% времени будет заниматься тестированием, обязательно приведет к гарантированному подтверждению, даже если кроме этого кадра вообще никто продуктом не занимается? Жду.

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

I>>А что по твоему есть "гарантированное подтверждение" ?
S>Ты хочешь сказать, что гарантированное подтверждение это есть обещание? Ну я тогда не понимаю, обещать можно без тестирования. Все что угодно. И заплатить рубль в качестве гарантии, если выяснится, что соответствия требованием не выполнены. Чем тогда это не "гарантированное подтверждение"? И это дешевле, чем держать человека на 100% оклада.

Я тебе предлагаю для себя ознакомиться с базовыми понятиям про контроль качества. Авто-тесты это ничтожно малая вещь, которая сама по себе ничего не гарантирует и гарантировать не может. Она работает только в том случае, если есть всё остальное, и то, решает только конкретный класс проблем. Например, авто-тесты никак не помогают с дырой в требованиях, не помогают с неправильной интерпретацией в требованиях, не помогают с проблемами в приоретизации, не помогают с неверными граничным условиями, не помогают с проблемами в бюджетаих, не помогают с проблемами с квалификацией, не помогают с проблемами внедрения, траблшутинга и тд и тд и тд.

Более того, они не помогают, если нет внятного источника знаний о новых проблемах. В силу специфики разработки, разработчик не может быть таким вот источником. Вот если станок поставить штамповать детали, рабочий может спокойно контролировать качество, если все виды работ ему по силам и ЗП не зависит от вала.

I>>Наоборот. Когда ожидания адекватные, разумные, то достижение цели становится возможным. В этом случае при правильном процессе или достигаешь цель, или находишь препятствие, которое необходимо устранить.
S>Достижение цели становится возможным — это отъезд. Ты говорил о гарантиях достижения.

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

Аналогично и с контролем качества — цель есть получение гарантий соответствия требованиям, т.е. подверждение того, что продуктом можно пользоваться согласно предназначению.
Из этого не следует ,что продуктом можно гарантировано пользоваться согласно предназначению.
Если гарантий соответсвия требованиям не получил, то хрен его знает, что там будет с продуктом — может и не запустится, а может даже проработает минуту или год — а хрен его знает.

I>>Там много чего нет, это очевидно. Постановка цели сама собой подразумевает, что делаться это будет не абы как, а рационально, и цель будет адекватной условиям задачи.
S>У тебя постановка цели = обещание, или я что-то путаю?

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

I>>Ок, то есть, сказать нечего.
S>Я как раз сказал. Тебе ответить нечего.

В таком случае ты продемонстрировал что не можешь скриптануть некий неучтенный фактор, который заранее не может быть учтен, например потому, что вовсе неизвестен заранее.

S>>>Когда будут известны требования

I>>Ты ведь сказал — что можешь заскриптовать неизвестное. Покажи пример одного единственного фактора, неизвестного на момент скриптования(расширения, дополнения).
S>Я не говорил, что могу заскриптовать неизвестное. Цитату. Может быть ты подразумевал, что можешь проверить руками что-то неизвестное. Но я про заскриптовать такое не говорил.

Я говорю про неизвестные, неожиданные, неучтенные по какой либо причине факторы. И ты уверяешь, что:

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

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

I>>Всегда. Я всем говорю, что в софте гарантированно есть неожиданные баги. Чем слабее тестирование, тем выше шанс на них нарваться.

S>С твоих слов выходит, что контроль качества — бессмысленная затея, т.к. цель недостижима.

Очевидно, ты понимаешь "качественный" как такой, в котором баги отсутствуют. С т.з.качества это верх некомпетентности сказать, что баги отсутствуют.
Другой пример — безопасность, с этой точки зрения верх некомпетентности сказать, что уязвимости отсутствуют.

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

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

I>>Именно, плановая, систематическая, цель которой — гарантированное подтверждение. Если ты не достиг цели, о качестве вообще нет смысла говорить. А если достиг, то у тебя есть точные сведения о том, какое именно качество — высокое, низкое, среднее. И если цель не достигнута, то процесс строится так, что бы получить внятное обоснование, где препятствие и как его устранить.
S>Ну, а что если цель достичь подтверждения в 2050-м году?

Значит до того говорить про качество смысла никакого нет. И про бенефиты от парадигмы — тоже

I>>Если вдруг обнаруживается, что цель недостижима, то ты получаешь гарантию — установить качество не представляется возможным.
S>И как ты обнаружишь что цель недостижима? Вот я буду 1 день в году посвящать плановой и систематической деятельности, цель которой — гарантированное подтверждение соответствия. В соответствии с определением — это и есть контроль качества. Но ты еще требуешь достижимости. Вот и доказывай теперь, почему такая деятельность не ведет к достижению.

Ты снова всё хочешь к определению привести Эти вещи, очевидно, следуют из бизнес процессов, а не из головы. В т.ч. и слова "систематически". Например, в трудовом законодательство это два и более раза год.

>И почему наличие кадра, который 100% времени будет заниматься тестированием, обязательно приведет к гарантированному подтверждению, даже если кроме этого кадра вообще никто продуктом не занимается? Жду.

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

I>>А что по твоему есть "гарантированное подтверждение" ?
S>Ты хочешь сказать, что гарантированное подтверждение это есть обещание? Ну я тогда не понимаю, обещать можно без тестирования. Все что угодно. И заплатить рубль в качестве гарантии, если выяснится, что соответствия требованием не выполнены. Чем тогда это не "гарантированное подтверждение"? И это дешевле, чем держать человека на 100% оклада.

Я тебе предлагаю для себя ознакомиться с базовыми понятиям про контроль качества. Авто-тесты это ничтожно малая вещь, которая сама по себе ничего не гарантирует и гарантировать не может. Она работает только в том случае, если есть всё остальное, и то, решает только конкретный класс проблем. Например, авто-тесты никак не помогают с дырой в требованиях, не помогают с неправильной интерпретацией в требованиях, не помогают с проблемами в приоретизации, не помогают с неверными граничным условиями, не помогают с проблемами в бюджетаих, не помогают с проблемами с квалификацией, не помогают с проблемами внедрения, траблшутинга и тд и тд и тд.

Более того, они не помогают, если нет внятного источника знаний о новых проблемах. В силу специфики разработки, разработчик не может быть таким вот источником. Вот если станок поставить штамповать детали, рабочий может спокойно контролировать качество, если все виды работ ему по силам и ЗП не зависит от вала.

I>>Наоборот. Когда ожидания адекватные, разумные, то достижение цели становится возможным. В этом случае при правильном процессе или достигаешь цель, или находишь препятствие, которое необходимо устранить.
S>Достижение цели становится возможным — это отъезд. Ты говорил о гарантиях достижения.

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

Аналогично и с контролем качества — цель есть получение гарантий соответствия требованиям, т.е. подверждение того, что продуктом можно пользоваться согласно предназначению.
Из этого не следует ,что продуктом можно гарантировано пользоваться согласно предназначению.
Если гарантий соответсвия требованиям не получил, то хрен его знает, что там будет с продуктом — может и не запустится, а может даже проработает минуту или год — а хрен его знает.

I>>Там много чего нет, это очевидно. Постановка цели сама собой подразумевает, что делаться это будет не абы как, а рационально, и цель будет адекватной условиям задачи.
S>У тебя постановка цели = обещание, или я что-то путаю?

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

I>>Ок, то есть, сказать нечего.
S>Я как раз сказал. Тебе ответить нечего.

В таком случае ты продемонстрировал что не можешь скриптануть некий неучтенный фактор, который заранее не может быть учтен, например потому, что вовсе неизвестен заранее.

S>>>Когда будут известны требования

I>>Ты ведь сказал — что можешь заскриптовать неизвестное. Покажи пример одного единственного фактора, неизвестного на момент скриптования(расширения, дополнения).
S>Я не говорил, что могу заскриптовать неизвестное. Цитату. Может быть ты подразумевал, что можешь проверить руками что-то неизвестное. Но я про заскриптовать такое не говорил.

Я говорю про неизвестные, неожиданные, неучтенные по какой либо причине факторы(например — фактор заранее неизвестен). И ты уверяешь, что:

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

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

I>>Всегда. Я всем говорю, что в софте гарантированно есть неожиданные баги. Чем слабее тестирование, тем выше шанс на них нарваться.

S>С твоих слов выходит, что контроль качества — бессмысленная затея, т.к. цель недостижима.

Очевидно, ты понимаешь "качественный" как такой, в котором баги отсутствуют. С т.з.качества это верх некомпетентности сказать, что баги отсутствуют.
Другой пример — безопасность, с этой точки зрения верх некомпетентности сказать, что уязвимости отсутствуют.

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