Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.
Пока придумывают архитектуру будущего кода, стоимость уже дороже. Представьте, что архитектор уже придумал, как это будет выглядеть, а вы хотите изменить фундамент:
Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.
Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?
Потому что пока мы на этапе тестирования нашли проблему, то да, придется исправлять много кода, но все же этот код написан в последний месяц (или сколько времени у нас занимает выпуск одной версии продукта).
А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.
Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…
Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!
Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Пока придумывают архитектуру будущего кода, стоимость уже дороже. Представьте, что архитектор уже придумал, как это будет выглядеть, а вы хотите изменить фундамент:
Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.
Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?
 |
| Картинка из книги Lee Copeland |
А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.
Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…
Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!
Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Оль, радость этого графика будет не полной, если забыть про второй, о котором все забывают.
ОтветитьУдалитьЯ про стоимость поиска ошибки.
Человек, способный обнаружить ошибку в требованиях, как правило, системный аналитик - очень дорогая штука, как правило - отсутствующая.
Программисты, умеющие в архитектуру - 1 на 50 или 1 на 100 и стоят не меньше.
Система автоматизированного тестирования, которой пользуются программисты для раннего обнаружения ошибок тоже очень дорога.
и так далее до пользователей, которые ищут почти бесплатно.
Так что правильный график больше напоминает не экспоненту, а параболу, в вершинекоторой наша с тобой профессия.
Хорошее замечание, спасибо! :)
УдалитьНужно принимать во внимание, что выводы, сделанные из этого графика сильно зависят от масштаба "релиза". Давай, для примера, считать, что на картинке представлен 3-х месячный релиз, стоимость нахождения бага в нём ~1000$. Если вместо этого сделать 3 релиза (раз в месяц), то стоимость нахождения бага в релизе снизится до условных $300, а на стадии тестирования до $30. Уже не так много... Едем дальше и релизим раз в неделю - стоимость бага в релизе и на стадии тестирования сокращается до $70 и $7 соответственно. Если будем релизить каждый день - $14 и $1.4. Разница в стоимости уже не тысячи долларов, а 3 чашки кофе...
ОтветитьУдалитьДругое интересно наблюдение - я ни разу не видел подобного графика с реальными цифрами. Ну т.е. со стороны он выглядит довольно логично, но как он выглядит на самом деле - никто никогда не считал.
Не уверена в «никто и никогда» :) Не просто так ведь книги пишут. Хотя во времена Lee Copeland-овской книги, вполне возможно, про релизы «раз в день» речь и не шла, скорее waterfall.
УдалитьНо тем не менее, какая разница? 14 и 1.4$ — это если ты нашел минорный баг, который хопа, и поправил. А на моих картинках проблема более видна))) Чем больше кода написано в момента выхода бага — тем сложнее вносить изменения, потому что ты пытаешься изменить фундамент, на котором ого-го сколько стоит. И это уже не $14, а намного дороже
У Вас опечатка: "С проблемами ошибки в требованиях приходитЬся мириться..."
ОтветитьУдалитьКнига с картинками это супер) Будем ждать, удачи!))
Спасибо, исправила))
Удалить