и посмотреть медиа
TestGrow - pruebas de software
и посмотреть медиа
Canal de la plataforma de pruebas de software. Materiales para probadores.
Canal de la plataforma de pruebas de software. Materiales para probadores.
bot de IA para clonar texto a voz y voz en Telegram. Cree audio utilizando la red neuronal de forma rápida y fácil.
Recursos de la plataforma TestGrow para pruebas de software. Materiales útiles y consejos para especialistas en QA.
БАГ, КОТОРЫЙ «САМ ПОЧИНИЛСЯ» Всем привет! Так как большинство проголосовало за практические кейсы, то буду стараться побольше об этом писать. Сегодня хочу поговорить о ситуации, знакомой, думаю, каждому тестировщику. Ловишь баг, описываешь шаги, делаешь скриншоты, собираешь логи. А потом запускаешь тест заново, и, там тадам, бага нет. Сервис работает идеально. Что это вообще было?🤔 Такие «мистические» баги случаются чаще, чем кажется, и у них есть вполне земные причины: ⁃ Многопоточность. Два процесса обращаются к одним и тем же данным почти одновременно. В первый раз система не справилась, во второй — уже всё ок. ⁃ Нестабильное окружение. Например, проблемы с сетью, временный сбой внешнего сервиса или база, которая «подвисла» на секунду. ⁃ Кэш и асинхронность. Иногда баг проявляется только при первом запуске, пока система прогревает кэш или подтягивает данные. ⁃ Тестовые данные. Если баг завязан на конкретное состояние БД или API-ответа, он может исчезнуть после одного прогона. ⁃ Скрытый багфикc. Разработчик мог выкатывать хотфикс на прод (или даже в тестовую среду), не предупредив никого. Почему такие баги опасны? Потому что они «призрачные» и разработчики часто относятся к ним скептически: «Не воспроизводится? Значит, и нет бага». Но мы-то знаем, что случайность в IT часто становиться закономерностью. Что я советую делать тестировщику: ⁃ фиксировать всё максимально подробно (логи, скриншоты, если необходимо запись видео); ⁃ пробовать воспроизвести на разных окружениях; ⁃ проверить зависимости (база, сторонние сервисы, кэш); ⁃ заводить баг-репорт, даже если воспроизводимость низкая — с пометкой плавающий дефект. Мой личный опыт: такие баги чаще всего «возвращаются» позже, а иногда уже в проде, и тогда у команды уходит в разы больше времени на расследование. Поэтому лучше зафиксировать эту странность сразу, чем закрыть глаза и надеяться, что она не повторится. А у вас было такое, что баг «сам починился»? Как вы действуете в таких ситуациях? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний
Открыть канал и посмотреть медиаSolo los usuarios registrados pueden compartir su opinión.
¡Sé el primero en compartir tu experiencia con este recurso!