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

P>Сейчас здоровье стало названием соответствующей услуги.

У кого, у продавцов услуг? Мне ваши фокусы с названиями неинтересны.

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

P> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.

Чтобы посмотреть, как оно работает — можно и нужно.

P>

P>debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.

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

P>1 сколько тебе тестов понадобится, что бы задетектить любой баг в функции вида Int64 -> Int64.

А кто сказал про абсолютно любой баг? Найти абсолютно любой баг вообще в принципе невозможно, никакими средствами.

P>Тем не менее, доку пишет тот, кто запилил АПИ.

Как я и сказал — сам танцую, сам пою, сам билеты продаю.

P>1 Технический писатель не в курсе кода, это мне придется надиктовывать ему все особенности АПИ

А ТЗ у вас в принципе нет?

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

P>> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.
C>Чтобы посмотреть, как оно работает — можно и нужно.

Скорее всего тебя в код пустят только после того, как ты продемонстрируешь владение доменом.

P>>

P>>debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.

C>Идиотское у тебя определение. finding bugs — это тестирование. Найти, почему конкретно баг происходит — вот это уже отладка. Исправление бага — это опционально.

Это общепринятое.

P>>1 сколько тебе тестов понадобится, что бы задетектить любой баг в функции вида Int64 -> Int64.
C>А кто сказал про абсолютно любой баг? Найти абсолютно любой баг вообще в принципе невозможно, никакими средствами.

Именно ты и сказал:

Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.

Тут одно из трех:
1. или ты не знаешь, что такое новый, неизвестный баг, т.е. веришь в "качество это когда багов нет"
2. или не в курсе, что полное покрытие заведомо недостижимо
3. несешь пургу, абы чего накинуть

P>>Тем не менее, доку пишет тот, кто запилил АПИ.
C>Как я и сказал — сам танцую, сам пою, сам билеты продаю.

Расскажи, как надо. Откуда технический писатель узнает, что делает моё апи?

P>>1 Технический писатель не в курсе кода, это мне придется надиктовывать ему все особенности АПИ

C>А ТЗ у вас в принципе нет?

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

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

P>Скорее всего тебя в код пустят только после того, как ты продемонстрируешь владение доменом.

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

P>Это общепринятое.

Говоришь за всех? Дурная привычка. Определений этого конкретного понятия — много разных.

P>Тут одно из трех:

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

P>Расскажи, как надо. Откуда технический писатель узнает, что делает моё апи?
P>Что бы диктовали, какое апи выставить наружу — такого нет. Обычно это моя забота, построить АПИ. Потому придется надиктовывать твоему техническому писателю, если вдруг приставят его ко мне.

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

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

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

Забавно, как у тебя плавно трансформируется понятие "кодинг" — теперь кодить это "джуниорам читать код"

C>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг.

А как же твоё

Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.

Не то у вас тестов нет, не то ты сам себе противоречишь.

C>Ты не знаешь где искать твои баги, потому что если знал бы — то уже исправил бы.

Ложный вывод. Знать где искать, и количество потенциальных тесткейсов это две большие разницы.
Ну вот знаем, что изменения влияют на старт приложения, например, из за загрузчика конфига.
Всех дел — стартуем сервис на всех возможных комбинациях значений. Допустим, у нас в конфиге всего 100 булевых флажков.
Вопрос — какие из 2^100 конфигураций повалят приложение на старте и сколько времени на это уйдет?

> Поэтому твоя информация тестерам в лучшем случае бесполезна, а в худшем — отправит в неверном направлении.

Если ты знаешь, что фикс точно влияет на компоненты А, Б и В, то их нужно перепроверить в обязательном порядке, а возможно и дописать необходимые тесткейсы.
Например — приложение изредка, раз в день-неделю-месяц, делает кое какие реквесты. Каким образом тестировщик узнает, что ты добавил один из таких реквестов? Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов?
Поэтому на вопрос тестировщика "а что/где поменялась" сообщаешь "телеметрия x-y-z c частотой раз в месяц начала слать вот это, включается конфигом вот так"

А вот всё остальное никто не отменял.
Собственно, сколько себя помню, тестировщики сами приходят и спрашивают, на что именно влияет фикс.
Элементарно — всегда нужно понять, стоит ли планировать регрессионное планирование после твоего фикса или хватит коротенького смок-теста, + пара-тройка новых автоматических тестов.

Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение.

C>Не доходит?

Похоже, тестирование у вас там отменили.

P>>Что бы диктовали, какое апи выставить наружу — такого нет. Обычно это моя забота, построить АПИ. Потому придется надиктовывать твоему техническому писателю, если вдруг приставят его ко мне.

C>Сколько вообще людей в вашей шарашке и какого размера проект? Хотя, учитывая твою любовь к электрону, вопрос можно считать риторическим

Судя по твоим познаниям в тестировании, шарашка это где то вокруг тебя.

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

P>Забавно, как у тебя плавно трансформируется понятие "кодинг" — теперь кодить это "джуниорам читать код"

Процитирую для тех, у кого проблемы с памятью.

P> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.

Чтобы посмотреть, как оно работает — можно и нужно.

Опять же, поменять что-нибудь и посмотреть в тестовом окружении, что сломается (если сломается) — не вижу вообще никаких проблем.

C>>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг.
P>Не то у вас тестов нет, не то ты сам себе противоречишь.

Л — Логика.

P>Всех дел — стартуем сервис на всех возможных комбинациях значений. Допустим, у нас в конфиге всего 100 булевых флажков.
P>Вопрос — какие из 2^100 конфигураций повалят приложение на старте и сколько времени на это уйдет?

Да, тяжело приходится вашим тестерам

P>Каким образом тестировщик узнает, что ты добавил один из таких реквестов?

То есть они у вас вообще не имеют никакого представления, как работает то что они "тестируют"?

P>Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов?

Действительно, как?

P>Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение.

И как оно у вас делается?

P>Похоже, тестирование у вас там отменили.

Ты будешь пытаться доказывать, что ручное тестирование выявляет все мыслимые ошибки при всех мыслимых комбинациях условий? Да или нет?

P>Судя по твоим познаниям в тестировании, шарашка это где то вокруг тебя.

Ты на вопрос не ответил.

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

C>Процитирую для тех, у кого проблемы с памятью.
Я вот помню, что мы говорили про кодинг, а ты решил дать джуниору почитать код размером с операционку.

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

C>>>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг.
P>>Не то у вас тестов нет, не то ты сам себе противоречишь.
C>Л — Логика.

Именно. У тебя в сумме вот такое
1. нет гарантий, что тесты надут новый, неизвестный баг
2. если не нашли, то тесты — отстой

Если 1 это норма, то 2 это уже безграмотность. Именно потому я привожу кейс где у нас 2^100 комбинаций.

P>>Каким образом тестировщик узнает, что ты добавил один из таких реквестов?
C>То есть они у вас вообще не имеют никакого представления, как работает то что они "тестируют"?

Забавно, что ты сам не можешь ответить.

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

process.exit(-1) // просто для примера

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

P>>Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов?
C>Действительно, как?

И снова ответа у тебя нет, о чем и речь.
В данном случае решение это вайт бокс тестирование, что очевидно. Блек боксом ты будешь искать такое до скончания времён.
Итого, здесь вайтбокс реализуется так:
— узнать у девелопера
— самому заглянуть в код изменений
Покрыть тесткейсами, прогнать вручную, и далее тесткейсы автоматизировать.

P>>Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение.
C>И как оно у вас делается?

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

P>>Похоже, тестирование у вас там отменили.
C>Ты будешь пытаться доказывать, что ручное тестирование выявляет все мыслимые ошибки при всех мыслимых комбинациях условий? Да или нет?

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

А раз у нас нет чудесного 100% покрытия всех путей выполнения, то применяют различные эвристики, например
1. блек бокс, когда тестер отталкивается от требований, явных или неявных. Пример: тесткейс для требования "юзер должен иметь возможность запретить телеметрию"
2. вайт бокс, когда тестер отталкивание от знаний о внутреннем устройстве. Пример: тесткейс для вещей вида "в файле/строчке подозрительный реквест отсылается раз в месяц"

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

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

Не вместо, а вместе. Не доходит?

P>В противном случае страховая контора разорится выплачивать пенальти.

Как быстро ты перескочил от "поиграть с кодом в тестовом окружении" к "хренак-хренак и в продакшен".

P>Именно. У тебя в сумме вот такое

У меня в сумме — "нет вообще никаких способов гарантированно найти новый, неизвестный баг". Ни автоматически, ни вручную, вообще никак. Поэтому все твои рассуждения на тему гарантированного обнаружения багов — бессмысленная демагогия.
Негарантированно — можно. В том числе и автоматически, и даже с довольно неплохой вероятностью.
Все еще не доходит?

P>Итого, здесь вайтбокс реализуется так:
P> — узнать у девелопера

Нет, вайтбокс реализуется совсем не так. Девелопер — по определению источник ненадежный, поэтому и спрашивать у него скорее вредно, чем полезно. Вайтбокс реализуется так: тестер — не мартышка с клавиатурой, а человек, который понимает как работает система и что от чего зависит, и способен понять, где что и почему может сломаться. Также, он должен быть способен посмотреть код и почитать логи и хотя бы приблизительно понять, что конкретно изменилось.

P>Далее этап exploratory, где тестировщик все проверяет ручными или полуавтоматическими методами, на предмет того, а не появилось ли что новое.

Все мыслимые комбинации параметров?

P>Потому половина твоих заявлений в этом треде есть обычная безграмотность.

Нет дружок, это всего лишь твоя демагогия и большая любовь к применению straw man.

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

P>>Вместо того, что бы все нюансы и детали извлекать из кода, нужно вначале ознакомиться с доменом, хотя бы с терминологией, это самое меньшее.
C>Не вместо, а вместе. Не доходит?

Это так не работает. Фиксовать тебе никто не даст, пока ты внятно не освоишь домен.
Все дело в цене ошибки. Чем она выше, тем позже тебя пускают в код. Американское страхование это чудовищно сложная система с чудовищной ценой ошибки — кодить не зная домена никто тебе не даст. Сначала покажи, что владеешь темой, а потом уже от тебя примут фикс.

Ровно так же и с математикой — сначала покажи, что её знаешь, а потом от тебя примут фикс того или иного алгоритма.

C>У меня в сумме — "нет вообще никаких способов гарантированно найти новый, неизвестный баг". Ни автоматически, ни вручную, вообще никак. Поэтому все твои рассуждения на тему гарантированного обнаружения багов — бессмысленная демагогия.

Кто же тогда с твоего аккаунта написал вот это:

Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.

Что именно ты имел ввиду? Ты внятно можешь пояснить?

C>Нет, вайтбокс реализуется совсем не так. Девелопер — по определению источник ненадежный, поэтому и спрашивать у него скорее вредно, чем полезно.

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

P>>Далее этап exploratory, где тестировщик все проверяет ручными или полуавтоматическими методами, на предмет того, а не появилось ли что новое.
C>Все мыслимые комбинации параметров?

Все основные пути, которые зафиксированы в тесткейсах.

P>>Потому половина твоих заявлений в этом треде есть обычная безграмотность.
C>Нет дружок, это всего лишь твоя демагогия и большая любовь к применению straw man.

Факт номер 1: ты регулярно в том или ином виде транслируешь вот эту идею: "Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет."
Факт номер 2: что ты здесь подразумевал — пояснять отказываешься.
Факт номер 3: периодически ты и сам косвенно утверждаешь, что твое утверждение выше есть ересь

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

P>Это так не работает. Фиксовать тебе никто не даст, пока ты внятно не освоишь домен.
P>Все дело в цене ошибки. Чем она выше, тем позже тебя пускают в код. Американское страхование это чудовищно сложная система с чудовищной ценой ошибки — кодить не зная домена никто тебе не даст. Сначала покажи, что владеешь темой, а потом уже от тебя примут фикс.

До тебя так и не дошла разница между "почитать код и поиграть с ним" и "делать фиксы в продакшен"?

P>

P>Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.

P>Что именно ты имел ввиду? Ты внятно можешь пояснить?

Тесты должны выявлять новые баги, хотя и не гарантированно все. Но некоторые — должны выявлять. Если никакие новые баги твоими тестами не выявляются — значит, никаких тестов у тебя нет. Есть только их имитация.

Но я надеюсь, хотя бы тот факт, что ручное тестирование тоже не гарантирует выявление всех новых багов, до тебя дошел?

P>Крайне странно ждать от тестировщиков, что они смогут прочесть и понять код системы.

Если они не макако-тестеры, то не странно. Но тебе, я так понимаю, знаком только этот вид.

ZZ> Берёшь канвас, берёшь webgl, берёшь WASM

И получаешь позорнейший по производительности однопоток.

ЭФ>И получаешь позорнейший по производительности однопоток.
Замечание справедливо. Хорошо бы расковырять, как Autodesk и Figma эту ситуацию разруливают. Наверняка UI однопоточный, а для тяжелых или продолжительных операций прикручен какой-нибудь OperationQueue поверх Web Workers.

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

C>Правда, надо отдаль должное — сбер хотя бы работает в RuStore, чего нельзя сказать о многих других российских приложениях. Половина требует гуглосервисы.

Были какие-то проблемы, не встал оттуда, пришлось ставить не то из AppGallery, не то из apk.