Привет. Пишу вам из будущего, из сентября 2020. Человечество еще живо, надежда есть. :)

Привет. Спасибо, старались :)
Касательно других типов XSS — их много и прятаться они могут в самых разных местах. Обо всем, конечно, в одной статье не расскажешь. :(
Но про это есть на курсе, о котором я упомянул. Может кому-то будет интересно :)

Привет.

Если говорить про конкретны пример, то на такую ссылку злоумышленнику придется человека как-то отправить. Либо редирект на свой сайт подложить и заманить на свой сайт. Либо сразу прислать «нехорошее письма» с ссылкой на нужный URL. Неподготовленный пользователь вполне себе может повестись на такое.

Что касается общих примеров, помимо URL самую XSS-инъекцию можно же сохранить, например, как сообщение. На том же форуме или в общем чате. Тогда любой пользователь, открывший нужную страницу получит это сообщение и JS-код.

А с продуктами всё проще, ну для Москвы и области, — есть куча доставок.

Я в целом согласен с общей мыслью. Но есть нюанс касательно доставок — а как их забирать? :)

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

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

Ну и материальная, конечно. Не все даже в дефолт-сити живут на широкую ногу. Кому-то две недели просидеть на больничном и получить ЗП по ТК может быть болезненным ударом — не на что будет заплатить за съем квартиры, на улице не хочется остаться…

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

Ась? Что Вы сказали? :)

Я так понимаю, в России пока не было зафиксировано больных?

Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.

А почему нельзя показывать пользователю варианты автомобилей вокруг только после создания заказа? Как это делает тот же Я.Такси. Тогда можно было бы отдавать их не по локации пользователя, а по локации самого заказа, который этот пользователь создал. Локацию заказа поменять у пользователя не получится, не пересоздавая заказ. Как и создавать 100500 заказов в минуту. Вот и решение.

:)

вот к примеру я хочу обновить пакет, у него в зависимостях еще 3 пакета, а у тех еще по 5, должен ли я прочитать release notes всех пакетов?

Смотреть и подробно изучать зависимости зависимостей может и не стоит. Но по какой-то причине Вы же хотите обновить этот пакет. Значит знаете зачем.

Ну и странно не почитать, что нового принесла очередная версия. Вдруг теперь можно ускорить тесты в три раза добавив какой-нибудь НЕ дефолтный флаг… откуда Вы об этом узнаете, если не прочитаете change list? :)

Моя мысль была в том, что обновлять пакеты или софт надо не потому что «надо», а с какой-то целью. Четко осознавая плюсы и минусы этого действа.

Написали интеграционные тесты, что кнопочки ищутся и тыкаются, формы вводятся и так далее, прогоняем эти тесты на каждый коммит, а при слиянии из dev в master прогоняем регресс, тогда сразу видно упадет ли этот регресс после вливания в мастер.

Это очень крутое и правильно решение. И оно всем правильное. Только стоит упомянуть, что оно довольно дорогое. Для подобные тестов на тесты надо А — выделить время в человекочасах, Б — поднять где-то аналог приложения с простыми формами, Ц — продумать сценарии, которые будут ловить не только поломанный примитивный click(), но и какой-нибудь драг-н-дроп какого-нибудь хитро сверстанного модуля. Иначе ценность этих тестов будет не очень высокой.

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

Спасибо, что разрешили :)
На самом деле мысль и правда простая. Но увы, много новичков набивает шишки, цепляя новые версии на боевые стенды и ломая тесты. Хочется им помочь освоиться. :)

А жена сама не может разве выписать рецепт? Или это не так работает?

Как я и сказал — ситуации бывают разные, процессы бывают выстроены по-разному. Так что не всем подойдет флоу, чтобы автоматизатор руками тестировал фичу вместо ручного тестировщика…
Да и в целом это просто замена исполнителя, а я выше хотел больше про процессы писать.

Навскидку, один из примеров — дорого. Бывают сервисы, которые активно выпускают новые фичи. Часто релизятся (например, в компании, где я работаю, релизы два раза в день). Проводится много А/Б-тестов на фичи. Все это покрывать UI-тестами быстро не получится. Да и смысла большого нет. Чаще всего покрывается фича в уже устоявшемся состоянии, когда все метрики по ней были собраны и было принято решение о том, как будет работать ее итоговая версия. Конечно, если от нее не решили отказаться. :)

UI-тесты на фичу зачастую (не всегда, а зачастую) пишут ПОСЛЕ релиза фичи.

Щупаешь фичу глазами, а она уже в проде и не работает. Удобно. :)

Ни разу эта тема не обсуждалась на Хабре и вот опять… :)
Но за картинки и их наглядность лайк.

Хм. Я вижу противоречие. Т.е. автоматизация не заменит ручное тестирование, но заменит ручных тестировщиков. Ок, а кто же будет проводить ручное тестирование? :)