пятница, 23 марта 2018 г.

Стоимость исправления ошибки на разных этапах разработки ПО

Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.

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


Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.



Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?

Картинка из книги Lee Copeland
Потому что пока мы на этапе тестирования нашли проблему, то да, придется исправлять много кода, но все же этот код написан в последний месяц (или сколько времени у нас занимает выпуск одной версии продукта).

А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.


Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…

Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!


Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!


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

6 комментариев:

  1. Оль, радость этого графика будет не полной, если забыть про второй, о котором все забывают.

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

    Программисты, умеющие в архитектуру - 1 на 50 или 1 на 100 и стоят не меньше.

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

    Так что правильный график больше напоминает не экспоненту, а параболу, в вершинекоторой наша с тобой профессия.

    ОтветитьУдалить
  2. Нужно принимать во внимание, что выводы, сделанные из этого графика сильно зависят от масштаба "релиза". Давай, для примера, считать, что на картинке представлен 3-х месячный релиз, стоимость нахождения бага в нём ~1000$. Если вместо этого сделать 3 релиза (раз в месяц), то стоимость нахождения бага в релизе снизится до условных $300, а на стадии тестирования до $30. Уже не так много... Едем дальше и релизим раз в неделю - стоимость бага в релизе и на стадии тестирования сокращается до $70 и $7 соответственно. Если будем релизить каждый день - $14 и $1.4. Разница в стоимости уже не тысячи долларов, а 3 чашки кофе...

    Другое интересно наблюдение - я ни разу не видел подобного графика с реальными цифрами. Ну т.е. со стороны он выглядит довольно логично, но как он выглядит на самом деле - никто никогда не считал.

    ОтветитьУдалить
    Ответы
    1. Не уверена в «никто и никогда» :) Не просто так ведь книги пишут. Хотя во времена Lee Copeland-овской книги, вполне возможно, про релизы «раз в день» речь и не шла, скорее waterfall.

      Но тем не менее, какая разница? 14 и 1.4$ — это если ты нашел минорный баг, который хопа, и поправил. А на моих картинках проблема более видна))) Чем больше кода написано в момента выхода бага — тем сложнее вносить изменения, потому что ты пытаешься изменить фундамент, на котором ого-го сколько стоит. И это уже не $14, а намного дороже

      Удалить
  3. У Вас опечатка: "С проблемами ошибки в требованиях приходитЬся мириться..."
    Книга с картинками это супер) Будем ждать, удачи!))

    ОтветитьУдалить