Найти баги там где их нет

[@ДмитрийМихеев-о1б]

Спасибо

[@bexcuts1568]

Спасибо за видео , очень поучительно , даже для ручника с 2х летним опытом

[@SeniorTester]

Спасибо, круто! Приятно быть полезным)))

[@black_milk_youtube]

очень полезно! можно больше такого

[@SeniorTester]

А статистика говорит, что такое как раз не заходит ((

[@black_milk_youtube]

@@SeniorTester а есть видео как писать баг репорты? такое то уж точно должно заходить в тематике тестирования

[@SeniorTester]

У меня ведь в основном автоматизация, темы по тестированию здесь плохо заходят

[@black_milk_youtube]

пойду на старый канал искать...

[@blessedman8016]

спасибо, интересно !

[@ksuksu2722]

Спасибо за полезное видео

[@diknik1148]

Не понял кейса с изменением ресурса картинки. Изменяя ресурс, вам возвращается 404 ошибка, с которой в обычной ситуации пользователь не столкнется, какой бы медленный интернет у него не был. В реальных пользовательских кейсах это будет или 403, или 5xx. Причем для каждого типа ошибки будут свои обработчики.

[@SeniorTester]

Для картинки будет 404 и страница отобразится без этой картинки. И вот этот кейс проверяет как поведёт себя страница: не поедет ли UI и не случится ли чего-то ещё

[@diknik1148]

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

[@SeniorTester]

А как лендинг может быть загружен с 500 или 403? Да и это уже работа со снифферами, а это другая тема. Да и кроме снифферов есть ещё куча способов поискать баги. Не сказал бы, что внезапная недоступность ресурса - наименее вероятный кейс

[@SeniorTester]

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