Почти половина разработчиков тратит 10-25% времени на исправление ошибок в готовом продукте



    Согласно новому исследованию, 43% enterprise-разработчиков тратят от 10 до 25% своего времени на отладку и исправление ошибок в приложениях на стадии эксплуатации.

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

    Авторы исследования считают, что такие потери времени слишком велики: разработчикам нужно больше концентрировать внимание на реализации новых фич для пользователей, нежели на постоянном исправлении ошибок.

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

    Исследователи также попросили респондентов оценить приоритет багов с точки зрения их критичности. 62% опрошенных ответили, что цена ошибки, пропущенной на этап продакшн является наиболее высокой. 18% считают самой «дорогой» стадию разработки, 7% отметили стадию QA, и 6% – тестирования.

    «Наше исследование тестирования приложений показывает, что такие практики, как тестирование на основе ограниченного подмножества специально сгенерированных данных, больше не годятся для команд, ориентированных на максимизацию времени, необходимого для разработки ценных для пользователей фич», – отмечает Марк Дэвис, СЕО компании ClusterHQ. – «Прогрессивные разработчики ПО понимают, что для [своевременного] снабжения клиентов инновациями и доработками необходимо эффективно управлять жизненным циклом ПО наряду с разнообразными уровнями инфраструктуры. Этот процесс начинается с выявления и ликвидации багов как можно раньше, чтобы команды могли сосредоточиться на добавлении [фич], необходимых конечному пользователю».

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

    88% респондентов хотели бы иметь возможность во время разработки тестировать приложения на реальных данных. Однако пока на пути к этому остается несколько препятствий. Главное из них – обеспечение актуальности тестовых данных. Так считают 23% опрошенных. 19,5% считают главной проблемой сложность одновременного обновления тестовых наборов везде, где они хранятся. Столько же собеседников упоминают сложность поддержки нескольких версий данных. 18% отмечают проблему управления доступом к информации, 14% считают копирование данных из работающей системы чересчур трудоемким процессом. 6% уверены, что стоимость хранения огромных объемов избыточной информации будет неоправданно высокой.

    Всего было опрошено 386 ИТ-специалистов. Полный отчет по исследованию доступен здесь.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      +11
      разработчикам нужно больше концентрировать внимание на реализации новых фич для пользователей, нежели на постоянном исправлении ошибок
      Ну тогда бизнесу следует определиться — что ему надо на начальном этапе разработки: бажный, но «дешевый» по всем параметрам MVP, слепленный на скорую руку для тестирования бизнес-идей, или тщательно спроектированный продукт с продуманной архитектурой?
      Вот не было в моем опыте такого, когда бизнес положительно протестировав идеи на MVP, выкинул его в мусор и предложил разработчикам сделать на основе этого удачного MVP качественный продукт с нуля. Всегда просят добавлять новые фичи именно в первоначальный глючный MVP.
        0
        Во многих бизнес-продуктах, разработчики не имеют возможности воссоздать реальное окружение и реальные данные — им просто их не дадут, особенно в финансовых структурах. Там вообще боятся лишнюю информацию с продакшена выдать.
        В результате идут фейковые таблицы, фейковые данные, фейковые нагрузки, которые не отражают реальность.
        Ну и да, взаимодействие с внешними системами, которые пишут другие разработчики, которые тоже тестят их на фейковых таблицах и фейковых данных, а потом все это соединяется вместе.
        +1
        Стоит упомянуть, что баг фиксинг продукта обычно финансируется из Operational budget, а разработка — из Capital Budget, и что по этой причине для компании часто имеет смысл запустить сырой продукт в продакшен, но потом фиксить его и по другой, гораздо более стабильной статье расходов.
        А вообще конечно, про это и так известно любому айтишнику, можно было и не дёргать 386 человек на всякую ерунду.
          +5
          Как-то, скорее, удивляет, что так мало, чем что так много.
            0
            Вероятнее всего из-за того, что это 1) забугорные реалии; 2) забугорые «интерпрайс» реалии (и скорее всего Java).
              0
              А что за бугром — багов меньше или отношение к ним более пофигистическое?
                0
                Наоборот. Более строгое. Ясное дело не везде. Но в целом мы по определению в роли догоняющих.
            0
            Не смог вспомнить область в которой обстоят дела иначе.
            88% респондентов хотели бы иметь возможность во время разработки тестировать приложения на реальных данных.
            В медицине эта цифра наверно несколько больше.
              +1
              Интересна была бы корреляция с используемыми технологиями и опытом команды.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое