Извиняюсь за небольшое отсутствие, включаюсь в процесс изучения и повторения😄😄😄
#выжимкаинформации из одной презентации про #дефекты
В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.
🖍Причина 1 – Нехватка времени.
В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ.
🖍Причина 2 – Дефект вовсе не дефект.
Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!» или «Это не дефект, а фича!» или «Это не баг, а фича!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.
🖍Причина 3 – Устранять неисправность слишком рискованно.
К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.
🖍Причина 4 – Это того не стоит.
Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков.
🖍Причина 5 – Неэффективный отчет о дефектах.
Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта, как слишком рискованный для устранения или просто как не стоящий усилий по устранению.
#выжимкаинформации из одной презентации про #дефекты
В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.
🖍Причина 1 – Нехватка времени.
В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ.
🖍Причина 2 – Дефект вовсе не дефект.
Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!» или «Это не дефект, а фича!» или «Это не баг, а фича!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.
🖍Причина 3 – Устранять неисправность слишком рискованно.
К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.
🖍Причина 4 – Это того не стоит.
Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков.
🖍Причина 5 – Неэффективный отчет о дефектах.
Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта, как слишком рискованный для устранения или просто как не стоящий усилий по устранению.