Вы понимаете истинную цену дефекта программного обеспечения?
Несколько недель назад наша команда развернула новый код в рабочей среде в рамках работы по реплатформингу. Это для существующей функции, которая существует уже много лет. К сожалению, новый код вышел из строя с первого клика пользователя.
Это была неловкая ситуация.
Разработчикам, участвовавшим в реализации, потребовалось немало часов, чтобы выявить первопричину. Пользователям стало не терпиться из-за того, что ранее работавшая функция была сломана в продакшене.
В итоге мы обнаружили, что выполнение определенного SQL-запроса занимает от 15 до 20 минут. Команда быстро исправила его на основе анализа оптимизации затрат и внедрила в производство. Обновленный запрос работал как шарм.
Позже мы узнали, что код не анализировался на этапе разработки. Команда также пропустила тестирование производительности, поскольку это была «просто» работа по переплатформе, а не разработка новой функции.
Новый код был переведен в рабочую среду только на основе результатов тестирования системной интеграции.
Загвоздка в том, что запрос выполняет полное сканирование таблицы миллиардов записей в рабочей среде. В SIT в нашей базе данных всего несколько тысяч (1 лакх = 100 тысяч) записей для функционального тестирования.
Этот инцидент поднимает вопрос об истинной стоимости дефекта программного обеспечения.
Истинная стоимость дефекта программного обеспечения выходит за рамки стоимости исправления ошибки. На самом деле, большинство считает, что подавляющая часть затрат приходится на задолго до того, как ошибка будет обнаружена. Это включает время и усилия, необходимые для воспроизведения ошибки.
Мы также должны учитывать время отладки и потерю производительности, пока команда пытается отследить основную причину.
Кроме того, часто существуют косвенные затраты, связанные с дефектами. Например, если в рабочей среде будет обнаружена критическая ошибка, это может нарушить нормальную работу бизнеса. В некоторых случаях дефектное программное обеспечение может повлечь за собой юридическую ответственность компании.
В нашем случае брак на производстве стоит нам:
- Несколько часов простоя указанной функции
- Часы потерянного времени инженеров, менеджеров и бизнес-пользователей на вызовах
- Доверие к команде по внедрению качественного кода в производство
- Выявлена плохая практика разработки, за которой следует команда
Всего этого можно было бы избежать, если бы команда не срезала путь.
- Они проигнорировали анализ запроса, который необходим для каждого кода, запускаемого в производство.
- Они пропустили этап тестирования производительности
Вот несколько уроков, которые каждая команда разработчиков программного обеспечения и их инженеры должны усвоить, чтобы не нести расходы, связанные с программным дефектом.
- Лучше потратить больше времени на этап разработки, чем на исправление дефектов в рабочей среде.Во время внедрения команда может не торопиться с анализом дефектов, не влияя на производственную среду. Нет давления со стороны бизнес-пользователей. Разработчики могут предпринять все необходимые шаги для проверки функциональности и тестирования производительности своего кода.
Команда может предоставить полезные решения для любых проблем на этапах тестирования. Им не нужно спешить с патчем, чтобы сделать эту функцию доступной. Это не повлияет на их бизнес, поскольку код еще не развернут. - Дефект программного обеспечения стоит не только денег:в некоторых случаях дефект может привести к значительным финансовым потерям, ущербу для репутации и судебному преследованию. В других случаях дефект может вызывать незначительные неудобства или раздражение.
Однако устранение даже небольшой программной ошибки может стоить компании времени и денег. Кроме того, каждый раз, когда ошибка обнаруживается и исправляется в спешке, это может создавать новые возможности для внесения в код других проблем.
Следовательно, для команд важно тщательно отслеживать дефекты и принимать меры по их устранению. предотвратить их в первую очередь. Поступая таким образом, команды могут сэкономить время, деньги и нервы в долгосрочной перспективе. - Дефект программного обеспечения может вызвать неудовлетворенность клиентов и даже потерю бизнеса.Хотя некоторые дефекты могут показаться простыми проблемами, они могут иметь волновой эффект, который влияет на компанию и ее пользователей.
Иногда возникает проблема дефект может привести к тому, что компания потеряет потенциальных клиентов или даже вынудит их отменить подписку. В других случаях дефект программного обеспечения может привести к потере или повреждению данных, что приведет к потере бизнеса или ущербу для репутации компании.
В любом случае крайне важно устранять дефекты программного обеспечения как можно быстрее, чтобы предотвратить дальнейшее влияние на бизнес. - Стоимость дефекта программного обеспечения выходит за рамки непосредственного воздействия:команда разработчиков программного обеспечения обычно ощущает немедленные последствия при обнаружении дефекта. Им нужно выделить время в своем графике, чтобы устранить проблему, что может повлиять на общий график проекта.
Однако стоимость дефекта программного обеспечения выходит за рамки непосредственного воздействия. Если дефект не будет исправлен быстро, он может иметь долгосрочные последствия, устранение которых может обойтись гораздо дороже.
Например, незначительный дефект в системе бухгалтерского учета может привести к созданию неверных финансовых отчетов. Если это не будет обнаружено и быстро не исправлено, это может привести к серьезным проблемам с соблюдением требований и финансовым санкциям. Следовательно, важно принять меры, чтобы предотвратить их появление в первую очередь. - Нет короткого пути к качеству: обеспечение качества (QA) должно быть неотъемлемой частью процесса разработки программного обеспечения. Тестируя продукты и услуги перед их выпуском клиентам, команды могут выявлять и устранять проблемы до того, как они вызовут проблемы с удовлетворенностью клиентов.
Контроль качества может выполняться собственными силами или с привлечением стороннего поставщика. Внутренний контроль качества часто дороже, но он может быть более эффективным при выявлении дефектов на ранних этапах процесса разработки. Аутсорсинг контроля качества может быть менее затратным, но также может привести к проблемам, если поставщик неопытный или надежный.
В конечном счете, лучший способ избежать затрат на устранение дефектов — инвестировать в тестирование обеспечения качества.
Заключительная мысль
Фактическая стоимость дефекта программного обеспечения часто намного превышает первоначальные затраты на исправление ошибки. При рассмотрении косвенных затрат становится ясно, что предотвращение дефектов должно быть главным приоритетом для организаций.
Внимательная разработка и тщательное тестирование могут помочь компаниям избежать значительных затрат, связанных с дефектами, и обеспечить соответствие их продуктов самым высоким стандартам.
Команды должны рассматривать обеспечение качества как инвестиции, а не затраты.
В следующий раз, когда у вас возникнет соблазн сократить время написания кода или пропустить несколько тестовых случаев, напомните себе об истинной цене дефекта. Независимо от того, насколько малы ваши изменения, они должны пройти надлежащий процесс анализа и тестирования.
Это может занять немного больше времени заранее, но ваше усердие наверняка избавит вас и вашу команду от головной боли в долгосрочной перспективе.
Спасибо за чтение. Если вам понравилась статья, проверьте мои самые успешные истории на Medium, чтобы узнать больше. Вы также можете стать участником Medium, перейдя по этой реферальной ссылке, чтобы поддержать меня.
Вы также можете прочитать:
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу
