LINUX.ORG.RU

История изменений

Исправление vostrik, (текущая версия) :

Вообще, если гранулярность нормальная, то для любого модуля тесты должно быть можно написать «за присест».

вот это - очень оптимистичное допущение

Я бы в этом случае выбрал те модули, что находятся в активной разработке, а также те, что написаны недавно (т.к. их вероятность изменения выше) - и начал бы тестировать их (полностью, сперва один, потом второй, потом третий, к следующему переходим когда закончили с предыдущим). Почему выбираются именно эти (активные)? Потому что пользы от их тестирования больше. Если у нас какойто модуль написан 10 лет назад, с тех пор не менялся и еще столько же не будет - то, ну, его тестирование можно на эти десять лет спокойно и отложить, ничего не потеряв.


ага, а потом на интеграции случится bigbadaboom, потому что старые модули с новыми не очень-то совместимы

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

good practice - не оценивать риски в одно лицо, как минимум - бизнес-аналитик либо продукт овнер, тестировщик, знакомый с проектом, девелоперы. роль ТСа в данном случае просто наблюдать и запоминать.

Исходная версия vostrik, :

Вообще, если гранулярность нормальная, то для любого модуля тесты должно быть можно написать «за присест». Я бы в этом случае выбрал те модули, что находятся в активной разработке, а также те, что написаны недавно (т.к. их вероятность изменения выше) - и начал бы тестировать их (полностью, сперва один, потом второй, потом третий, к следующему переходим когда закончили с предыдущим). Почему выбираются именно эти (активные)? Потому что пользы от их тестирования больше. Если у нас какойто модуль написан 10 лет назад, с тех пор не менялся и еще столько же не будет - то, ну, его тестирование можно на эти десять лет спокойно и отложить, ничего не потеряв.

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

good practice - не оценивать риски в одно лицо, как минимум - бизнес-аналитик либо продукт овнер, тестировщик, знакомый с проектом, девелоперы. роль ТСа в данном случае просто наблюдать и запоминать.