Почему это является более дорогостоящим для обнаружения дефекта позже в процессе? [закрытый]

Вы строите дом. Вы прокладываете канализационные трубы в фундамент, но одна из неизвестных вам труб заблокирована мертвым ежом.

Вы бы лучше узнали:

• Непосредственно перед заливкой бетона
• После дома закончено, и новый владелец пытается воспользоваться туалетом?

(Где-то в этой аналогии есть шутка о "переполнении стека". 8 -)

This can be illustrated in a simple (if not trivial) example.

Take a simple dialog with a message and just two buttons "OK" and "Cancel".

Assume that the error is a spelling mistake.

If this is found after the product is released then a new version of the product has to be released with all the costs associated with that. Manuals will need to be reprinted.

If this is found in final testing the manual will have to be reprinted. The code will need to be rewritten and tests re-run.

If this is found during development then there is just the cost of fixing the code.

If this is found during design then the code is written correctly first time - no cost.

1. Никто никогда не понимает код так хорошо, как вы его пишете.
2. Люди, возможно, стали зависеть от ошибка.
3. Возможно, вам придется исправить много неверных данных, которые была сохранена в результате ошибки.
4. Возможно, вам придется развернуть новую версию или патч вашего программного обеспечения.
5. Возможно, вашей службе поддержки потребуется отправить целую кучу вызовов.
6. Возможно, вам придется заполнить кучу документов, объясняющих, почему существует эта ошибка и какие проблемы она вызывает, и что вы собираетесь сделать, чтобы это никогда не повторилось.

Because more people will have spend time with the defective software.

If you fix a bug at early on you and maybe a code reviewer will spend a little time on it.

If it gets released to customers and reported as an error, you will have coded it, someone may have reviewed it, someone may have tested it, somebody may even have documented it and so forth ...

There may be other dependencies (internal or external) which will affect the fixing of a defect.

For example - If I resolve this defect, I may have to fix something else

Imagine you're writing an essay on why it's more costly to discover a defect later in the process, and you suddenly realise one of the premises on which most of your essay content is based is false.

If you're still planning, you only have the half a page of plan to change. If your essay is nearly finished, you suddenly need to scrap the lot and start over. If you've already handed it in, the error is gonna cost you your grade.

Same reason.

For a shrink-wrapped software product: Если вы обнаружите ошибку после того, как ваш продукт поступит в магазины, вам придется помочь пользователям посредством звонков в службу поддержки, предложить обходной путь или даже отозвать продукт / выпустить пакет обновления.

Для веб-сайта: Перебои в работе и задержки на сайте стоят вам денег. Потеря клиентов в результате плохой / неисправной работы сайта обходится вам дороже. Сам процесс отладки также требует больших затрат.

Because of the development process and all the work involved in fixing the defect.

Imagine you find a problem in the function you coded yesterday, you just check out, fix, check in, period. It's still fresh in your mind, you know what it is about and that your fix won't have any side effect.

Now imagine finding the same bug in six month from now. Will you remember why the function was coded that way ? Will you still be working on this project/company ? You have to open a defect report, a new version of your software have to be issued, QA needs to validate the correction. If the software has been deployed, then all instances have to be upgraded, customers will call support ...

Now it's true that the curve showing the cost are made up to illustrate the point; it actually depends on the development process.

Вероятно, это ошибка автора вопроса, но на самом деле вопрос заключается в следующем: «Почему более дорого обходится обнаружение дефекта на более позднем этапе процесса?» В этом вопросе указана стоимость обнаружения ошибка, и мы можем надеяться, что это также означает ее исправление. Большинство ответов хорошо описывают стоимость исправления и почему лучше исправлять раньше, чем исправлять позже. И я действительно не согласен ни с одним из них. Но это не весь вопрос.

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

На практике Тестируйте как можно больше, но найти эту точку баланса не так просто, как многие думают. Большинство программ слишком велики, чтобы обеспечить 100% покрытие кода. И 100% покрытие кода обычно является лишь частью всех возможных сценариев, которые код должен обрабатывать.

Еще одним фактором, влияющим на стоимость ошибки, являются коммерческие расходы, связанные с ошибкой. Есть ли там 5 миллионов коробок с ошибкой? Вам нужно будет отозвать товар? Будет ли генерироваться X звонков в службу поддержки по гарантии? Будет ли это вызывать действие какого-либо пункта в контракте, в котором вы несете ответственность за ущерб. Проще говоря, вот почему программное обеспечение, написанное в области медицины, стоит больше на LOC, чем разработка веб-сайтов.

100% покрытие кода - это обычно лишь часть всех возможных сценариев, которые должен обрабатывать код.

Еще одним фактором, влияющим на стоимость ошибки, являются бизнес-затраты, связанные с ошибкой. Есть ли там 5 миллионов коробок с ошибкой? Вам нужно будет отозвать товар? Будет ли генерироваться X звонков в службу поддержки по гарантии? Будет ли это вызывать действие какого-либо пункта в контракте, обязывающего вас нести ответственность за ущерб. Проще говоря, вот почему программное обеспечение, написанное в области медицины, стоит больше на LOC, чем разработка веб-сайтов.

100% покрытие кода - это обычно лишь часть всех возможных сценариев, которые должен обрабатывать код.

Еще одним фактором, влияющим на стоимость ошибки, являются бизнес-затраты, связанные с ошибкой. Есть ли там 5 миллионов коробок с ошибкой? Вам нужно будет отозвать товар? Будет ли генерироваться X звонков в службу поддержки по гарантии? Будет ли это вызывать действие какого-либо пункта в контракте, в котором вы несете ответственность за ущерб. Проще говоря, вот почему программное обеспечение, написанное в области медицины, стоит больше на LOC, чем разработка веб-сайтов.

Есть ли там 5 миллионов коробок с ошибкой? Вам нужно будет отозвать товар? Будет ли генерироваться X звонков в службу поддержки по гарантии? Будет ли это вызывать действие какого-либо пункта в контракте, обязывающего вас нести ответственность за ущерб. Проще говоря, вот почему программное обеспечение, написанное в области медицины, стоит больше на LOC, чем разработка веб-сайтов.

Есть ли там 5 миллионов коробок с ошибкой? Вам нужно будет отозвать товар? Будет ли генерироваться X звонков в службу поддержки по гарантии? Будет ли это вызывать действие какого-либо пункта в контракте, в котором вы несете ответственность за ущерб. Проще говоря, вот почему программное обеспечение, написанное в области медицины, стоит больше на LOC, чем разработка веб-сайтов.

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

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

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

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

Чем позже вы обнаружите ошибку, тем хуже. Когда вы обнаруживаете ошибку сразу после написания кода, вы имеете в виду все поведение и точно знаете, какие изменения вызвали ее. Вы сможете сосредоточиться на проблеме, если узнаете, где она находится.

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

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

Наконец, есть проблемы, связанные с пользователями. Если вы обнаружите ошибку после выпуска, она разочарует больше пользователей, а имидж вашего продукта станет хуже. Пользователи также могут найти обходной путь для этой ошибки, которая может начать давать сбои после ее исправления.

Резюме: Когда вам нужно много времени, чтобы найти ошибку

• Ваши возможности для исследования больше
• разработчика, создавшего ошибку, может больше не быть, и другим разработчикам придется больше изучить код, чтобы найти, понять и исправить
• Вам также может потребоваться исправить части, которые зависят от ошибочного кода (и там будет больше таких частей)
• Пользователи уже будут разочарованы ошибкой, и образ продукта будет поврежден