logo
 
?

баги виды

Бывают баги (ошибки) разной степени вредности и сложности, некоторые из них увижу только я, некоторые — остаются от «срочносрочно» влезть в бюджет подхода и будут исправлены на доработках, но а некоторые — просто плевок в душу пользователя. Несоответствие показного контента — назначению сайта. Пример — сайт продажи услуг «создания лендингов» — с неработающим собственно лендингом.

Сапожник без сапог конечно бывает — но тут это как стоматолог с дыркой вместо зуба…

Особенно характерен для сайтов, сделанных для галочки.

Вроде как сайт и есть, и функциональность есть — но работает так, что пользоваться ею невозможно.

На скриншоте должен был быть выбор офиса в Киеве (я подозреваю).

С сайтом в этот момент работать уже не очень хочется — тк доверие к его информации подорвано более чем( Чаще всего появляются при допиливании уже готового сайта самими вебмастерами клиента.

Например на скриншоте есть один пункт меню лишний сверху.

Будем честными: пропущенный баг – это всегда повод для огорчения.

Скажем больше: попадание бага в финальную версию продукта – один из самых страшных снов тестировщика, особенно начинающего. Около 20 лет назад американский инженер и автор множества книг по тестированию и разработке ПО Борис Бейцер сформулировал правило, которое позже вошло в историю под названием «Эффект пестицида».

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

И вот вы стараетесь-стараетесь, тестируете-тестируете, а потом пользователь заявляет о критической ошибке в приложении. Говоря языком тестировщиков, если написанные тесты («пестициды») запускаются сотни раз, то они становятся менее эффективными.

В результате новые виды дефекты (вредители), которые появились в поздних версиях системы, не попадают под покрытие данными тестами и с легкостью проникают в релизную версию ПО.