Здравствуйте, 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. вайт бокс, когда тестер отталкивание от знаний о внутреннем устройстве. Пример: тесткейс для вещей вида "в файле/строчке подозрительный реквест отсылается раз в месяц"