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

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

I> Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
С пониманием гарантий долголетия почему-то у тебя нет проблем.

I>>>Согласно определению
I>

I>Контроль качества – деятельность,для гарантированного подтверждения ...

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

S>>Какое хорошее определение. Оно как раз показывает, что контроль качества у нас есть. Жаль, что ты с ним не согласен. Но это не моя забота.

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

Пример. Поиск багов — деятельность, направленная на получение гарантий. Согласен? Знаешь, почему эта деятельность не может гарантировать? Потому, что кроме поиска, нужен фиксинг. Почему поиск и фиксинг, вместе взятые в качестве систематической деятельности (со 100% занятости персонала), не способны обеспечить гарантии? Потому что нужно еще очень много условий. Обеспечить фиксинг более быстрый, чем поиск. но этого мало. Нужно фиксами и разработкой не внести новых багов. И этого не достаточно. Итак, почему согласно первому твоему определению контроль есть (как деятельность, направленная на получение гарантий), а гарантий еще нет? Потому, что нашли и пофиксили еще не все баги. Когда этот процесс закончится и мы, наконец, получим гарантии? Никогда. Знаешь, что будет, когда ты найдешь все баги? Найдется окружение, в котором программа будет вести себя некорректно.
Печалька, что тебе приходится объяснять такое.

S>>Цель деятельности — гарантии. Но гарантии не следуют из наличия деятельности, т.е. не являются обязательным следствием такой деятельности.

I>Цель — гарантии, но при этом цель не является обязательной
Передергиваешь. Цель не является обязательным следствием действий, направленных на достижение этой цели.

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

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

I>А это следует из твоего заявления, что де тестирование нужно только когда на дядю работаешь.
Не следует. Мое заявление было не о тестировании как таковом. Оно было ответом на твой тезис о том, как оно обычно делается.

I>>>Чему равняется цена ошибки? Какого рода данные хранят в вашем файлохранилище?
S>>Любого, мне не докладывают.

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

I>>>Вы риски заказчика разделяете или вешаете на него? Пенальти за баг на проде платите?
S>>Заказчика нет. Есть клиенты. Если клиента что-то не устраивает — он волен решать свои проблемы как-то по-другому.

I>Это какая то новая терминология. Заказчик это лицо которое например, покупает услугу, продукт и тд. Вероятно, ваши клиенты у вас ничего не покупают Откуда тогда деньги?
I>Или ты думаешь, заказчик это только тот, кто разработку заказывает ? Он может и хранение файлов заказать в вашем клауде
Я про узкий смысл слова заказчик, когда заказчик решает, каким образом должен быть выполнен его заказ, как будет определяться качество. Клиент, который получил услугу по прейскуранту и отвалил — заказчик лишь в широком смысле.

S>>Не переживай. У нас нет ключей от файлов заказчика.

I>У вас нет ключей == у вас нет некоторого ничтожно малого подмножества уязвимостей. А что с остальными уязвимостями?
Почему-то у меня возникает впечатление, что я отчитываюсь. А вроде как не обязан.
У нас есть очень большие клиенты. Со своими очень серьезными службами безопасности. Цепочки согласования у них довольно длинные, как по кол-ву людей, принимающих решение, так и по времени. Их требования нам удается выполнять. Или, лучше сказать, находить консенсус.

S>>Стопари. Тестирование у нас есть. Ты весь балаган развел лишь на почве того, что нет кадра, который бы 100% времени занимался экспл-чего-там тестированием. Но, как оказалось, приведенное тобой определение контроля качества и не требует такого кадра.

I>Требует! Нужен поиск новых, неожиданных проблем, а не просто многократное повторение, что регрессии не обнаружено.
Определение не требует. Перечитай его. "Любая систематическая деятельность, направленная".

S>>Как мило с твоей стороны. Местами это весьма неслабо пересекающиеся множества.

I>Это и есть заблуждение. Одна методка ищет и исследует, вторая — проверяет что ничего найденного не всплыло заново. Одна работает с неизвестным, другая — с известным. Соответсвенно эти вещи мягко говоря противоположны по смыслу а потому дополняют друг друга.

Ты нестрог к формулировкам. Ты утверждаешь вещи, которые расходятся со здравым смыслом. Например, из твоего требования наличия кадра, 100% времени занимающегося поиском, следует что один лишь разработчик не может обеспечить контроль качества, т.к. его деятельность не может на 100% состоять из поиска новых багов. Вместо этого определения контроля качества, которое ты приводил, не требует даже 1%. Ему достаточно просто систематической деятельности.