Телеграмм чат группы TeamLeadTalks страница 10575

Всегда что-то ломается и система должна реагировать на это какими-то предусмотренными действиями

13:10пожаловаться #1

unit, модульные - разработчик, success-path и основные unsuccess для интеграционных - тоже разработчик.
e2e, сложные corner-case, performance, chaos etc - QA-специалисты.
Но при этом разработчик правит их тесты при каких-то изменениях.

13:11пожаловаться #2

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

Vladimir Smirnov in Боль Тимлида

13:11пожаловаться #3

Юзеры не отправляют - потому что не сталкиваются, или что?

13:13пожаловаться #4

Простите, но это бездоказательно :)) слова ничто, воспроизведение все. Иногда автоматизировать воспроизведение сложно, но все равно воспроизведение необходимо, даже потому, чтобы в следующий раз этот же деффект не появился снова

13:13пожаловаться #5

image_2021-07-14_13-14-40.png

(56 Кб)

13:14пожаловаться #6

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

13:17пожаловаться #7

Э, для HTML есть формальное описание, в чем проблема-то?

13:19пожаловаться #8

Wingman in Боль Тимлида

записал, спасибо)

Sergey Bezrukov in Боль Тимлида

13:19пожаловаться #9

В том, что если бы браузеры не показывали невалидный ХТМЛ, то веб умер бы, не успев родиться 😊

13:19пожаловаться #10

Ааа, это да )

13:20пожаловаться #11

Люди которые "исправляют" код и при этом не могут его сломать и не понимают что он делает, вызывают у меня опасения

13:20пожаловаться #12

А если эту ошибку правит кто-то другой или это задокументированное поведение?

13:23пожаловаться #13

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

13:24пожаловаться #14

Нельзя исправить то, чего нет. Нет воспроизведения, значит нет бага

13:26пожаловаться #15

Нужны доказательства того, что баг есть, если доказательств нет, то и исправлять ничего не надо

13:27пожаловаться #16

Просто, как пример, у нас легаси генератор SQL запросов. Тестов, по-классике, нет. Уверен, что есть сложные баги, которые могут произойти в следствии "странных метаданных", но пока они не приносят проблем, так может не стоит их и трогать?

13:27пожаловаться #17

Потому что вы вносите изменения в систему, которая до этого работала корректно, тем самым увеличивая вероятность возникновения ошибки, а не уменьшая эту вероятность

13:28пожаловаться #18

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

13:29пожаловаться #19

Мне понравилось, как Виталий вбросил за таск нейминг, аля "Не работает"...)