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

I>>Это неверная аналогия.
S>Верная.

Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
Факт №2 — правильное питание может гарантировать исключительно отсутствие или своевременное обнаружение определенных проблем, связанных с этим самым питанием.
Пример №1 если ты не употребляешь алкоголь, то у тебя не будет алкогольных заболеваний печени, а печень будет работать лучше.
Пример №2 если ты ешь столько, сколько необходимо, то не будет проблемы лишнего веса. Из этого не значит, что ты проживешь 90 лет. Просто такой фактор, как лишний вес, у тебя играть не будет.

Вобщем, из твоего примера очень похоже, что гарантии в твоем понимании есть нечто, никак не связаное с продуктом, эдакая маркетинговая сказочка

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

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

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

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

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

Цель — гарантии, но при этом цель не является обязательной

I>>Задачи тестирования —
I>>1 сделать эту долю максимально возможной
I>>2 проверить, что все это решено, учтено и тд
S>Это необязательно задачи тестирования. Часть задач вполне можно переложить на компилятор, библиотеки, подходы к разработке.

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

I>>Дядин или нет — дело десятое. Ощущение, что ты на тестирование смотришь как на чтото лишнее
S>Не знаю, откуда оно у тебя.

А это следует из твоего заявления, что де тестирование нужно только когда на дядю работаешь.

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

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

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

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

I>>Для примера — если заказчик будет хранить у вас данные, скажем, по медицинскому страхованию, но он из за одного фейла с порчей или раскрытием данных засудит вас по самые нидерланды. Раскрытие одного только документа может потянуть лет на пять вашей разработки на троих вместе взятых.
S>Не переживай. У нас нет ключей от файлов заказчика.

У вас нет ключей == у вас нет некоторого ничтожно малого подмножества уязвимостей. А что с остальными уязвимостями?

I>>Лично я внятный контроль качества вижу в серьёзных продуктовых конторах, т.е. "на себя". Энтарпрайзу до таких высот как до небес. В энтерпрайзе можно увидеть проекты вообще без тестирования, абы картинка была красивая. Для серьезной продуктовой конторы это смерть от имиджевых потерь. Как только юзеры догадаются, что контора продает пустышки, на ней сразу ставят жирный чорный крест.

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

Требует! Нужен поиск новых, неожиданных проблем, а не просто многократное повторение, что регрессии не обнаружено.
У вас ведь не конвейер по производству молочных продуктов. Типа, конвейер чист, обслужен, игредиенты в порядке, тех процесс в норме — значит всё хорошо.
У вас принципиально отсутствует такой конвейер, т.к. вы занимаетесь разработкой программного обеспечения.

S>>>Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.

I>> А я и не решаю. Я рассказываю, что такое ручное тестирование и почему его нельзя заменить авто-тестами. Эти методики решают разные классы задач, которые есть всего лишь слабо пересекающиеся множества.
S>Как мило с твоей стороны. Местами это весьма неслабо пересекающиеся множества.

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