[Перевод] CISQ. Исследование анализа качества ПО 2020 — часть 1
В этой статье перевод части результатов опроса — раздела «Инженерия». Во второй части будет перевод оставшихся двух разделов — «Системные интеграторы», «Управление поставщиками».
--------------------
Представляем отчет «Состояние отрасли»
Консорциум по качеству информации и программного обеспечения (CISQ) запустил опрос «Состояние отрасли», первое комплексное исследование анализа качества программного обеспечения, охватывающее поставщиков инструментов, системных интеграторов, менеджеров и инженеров в организациях конечных пользователей. Опрос был открыт с июля 2019 года по январь 2020 года. Толчком для этого исследования стало тревожное увеличение количества инцидентов, связанных с качеством программного обеспечения, а также обеспокоенность членов CISQ тем, что организации не соблюдают основные требования. Мы хотели понять, как переход к Agile-разработке и DevOps меняет не только практики обеспечения качества программного обеспечения, но и отношение разработчиков и их поведение в отношении качества кода. Также важно понять, как стандарты качества программного обеспечения используются системными интеграторами и организациями конечных пользователей; какие стандарты применяются, какие сектора способствуют их внедрению и как организации получают пользу от стандартов качества программного обеспечения.
Методология
Результаты в отчете «Состояние отрасли» по анализу качества программного обеспечения основаны на 82 ответах в онлайн-опросе, 155 телефонных беседах с ИТ-руководителями предприятий, их командами и менеджерами поставщиков ИТ-услуг, обсуждениях на семинарах, организованных CISQ, и форумах на LinkedIn. Этот отчет включает результаты опроса, наблюдения и рекомендации. Отчет разделен на три раздела:
Что разработчики думают об анализе качества программного обеспечения (SQA)?
Переход к Agile-разработке и DevOps, а также растущая скорость, с которой работают команды, является беспрецедентным. Команды выпускают программное обеспечение с невиданной ранее скоростью. В то же время мы сталкиваемся с гораздо более высокими уровнями риска и уязвимости.
Проблемы низкого качества программного обеспечения и технического долга существуют с момента появления ИТ. Похоже, что мы достигли кризисного момента, когда необходимо гораздо серьезнее относиться к решению этих проблем и начинать рассматривать разработчиков как инженеров. Это значит, что нужно не только писать код, но и уделять внимание другим аспектам инженерии, таким как обеспечение качества, безопасность, надежность и долгосрочная жизнеспособность разрабатываемых решений. С переходом к SaaS и облачным технологиям предприятия и инженерные команды могут считать, что это не касается их, но это не так. SaaS-решения создаются инженерами. Если у этих решений есть слабые места, это затрагивает тысячи, если не миллионы, пользователей.
В отчете CISQ «Состояние отрасли» по анализу качества программного обеспечения мы хотели проверить гипотезу о том, что надежность, безопасность, эффективность производительности и поддерживаемость, поскольку их часто называют «нефункциональными требованиями», остаются второстепенными по сравнению с функциями, ориентированными на клиента, для продуктовых владельцев, менеджеров и команд. Давайте перейдём к результатам опроса.
Используете ли вы в настоящее время SQA?
Результаты: Большинство разработчиков, 82%, сообщают, что используют анализ качества программного обеспечения. Более того, 33% утверждают, что всегда используют статический анализ кода, по сравнению с 17%, которые всегда используют динамический анализ кода. 32% разработчиков сообщают, что часто используют статический и динамический анализ кода, т.е. на ежедневной или еженедельной основе.
Наблюдения: Существовало мнение, что разработчики неохотно используют анализ качества программного обеспечения в любой форме — статической или динамической. Однако собранные нами данные показывают, что это далеко от истины, так как более 82% разработчиков утверждают, что используют анализ качества ПО в той или иной форме. Мы полагаем, что усиленное внимание к непрерывной интеграции (CI) и непрерывной доставке (CD) в сообществе DevOps, а также доступность инструментов с открытым исходным кодом для анализа качества программного обеспечения способствуют этому.
Требует ли ваша внутренняя регуляторная функция или функция обеспечения качества обязательного использования SQA вашими командами разработки?
Результаты: 17% разработчиков сообщают, что использование анализа качества программного обеспечения является обязательным в рамках внутренней регуляторной функции, треть отмечает, что это зависит от проекта, и еще треть считает, что регуляторная функция должна требовать использования SQA. Эти данные показывают, что существует значительный потенциал для более тесного взаимодействия между инженерией и подразделениями управления рисками и соблюдения нормативных требований (GRC) для снижения рисков в программном обеспечении, который еще не полностью реализован. Функция обеспечения качества (QA) отражает регуляторную политику: 17% разработчиков сообщают, что SQA является обязательным, а 33% — что это зависит от проекта. Однако треть разработчиков отмечает, что функция QA никогда не требует обязательного использования анализа кода.
Наблюдения: Очевидно, что как внутренняя регуляторная функция, так и, что удивительно, функция обеспечения качества не требуют обязательного использования инструментов для анализа качества кода. Похоже, что подавляющее большинство разработчиков самостоятельно принимают решение использовать SQA. Подход, зависящий от конкретного проекта, остается доминирующим, и возникает вопрос, насколько он оправдан, учитывая текущий уровень ИТ-рисков и рисков безопасности.
Связана ли степень автономии вашей команды с уровнем зрелости команды в области SQA и управления техническим долгом?
Результаты: 50% разработчиков сообщают, что уровень автономии, предоставляемой команде, неформально связан с использованием анализа качества программного обеспечения. 17% указывают, что автономия формально связана с SQA. 33% разработчиков не знают о какой-либо формальной или неформальной связи между анализом кода и автономией команды.
Наблюдения: Agile и DevOps основаны на автономной организационной структуре с самоорганизующимися командами. Однако кажется, что лишь немногие организации позволяют автономным командам заслужить свою автономию, соблюдая правильные подходы и лучшие практики. Только 17% разработчиков сообщают, что их команды проходят формальную оценку по качеству структуры кода.
Мы считаем это несколько неожиданным, учитывая распространенность проблем технического долга во многих организациях. Автономия должна быть связана с лучшими практиками и поведением, ориентированными на качество программного обеспечения.
Какие стандарты разработчики используют для SQA?
Результаты: Наиболее «часто» используемыми стандартами являются: OWASP Top 10, ISO 25000. Стандарты, используемые «иногда», включают: MISRA, MITRE CWE, SANS/CWE Top 25, OMG/CISQ.
Наблюдения: Неудивительно, что учитывая его распространенность в отрасли, список OWASP Top 10 является одним из наиболее часто упоминаемых стандартов. Необходимо учитывать, что существует разница между осознанием и ссылкой на стандарт и разработкой кода, соответствующего этому стандарту. MISRA — это пример того, что мы ожидаем увидеть в будущем — отраслевые стандарты качества программного обеспечения. Мы прогнозируем, что киберфизические устройства и IoT увеличат использование стандартов качества программного обеспечения, специфичных для определенных областей.
Как часто проводите SQA?
Результаты: 60% разработчиков сообщают, что код сканируется ежедневно или еженедельно, 20% указывают, что код сканируется перед выпуском на этапе контроля качества, и 20% сообщают, что анализ кода носит реактивный характер и проводится по мере необходимости, когда возникает проблема.
Наблюдения: Более половины разработчиков сообщают о регулярном использовании SQA на ежедневной или еженедельной основе. Это ожидаемо, учитывая наше мнение о том, что DevOps и CI/CD способствуют более широкому внедрению SQA. Нам следует быть осторожными, чтобы не преувеличивать важность частоты SQA, так как наиболее важны результаты сканируемого кода и последующая рефакторинг. Все еще существует высокая доля команд, в которых SQA не проводится на постоянной основе. Анализ качества программного обеспечения должен быть интегрирован в инструментарий DevOps.
Как часто вы игнорируете метрики SQA?
Результаты: 60% разработчиков сообщают, что они «иногда» игнорируют результаты SQA, а 40% утверждают, что они «редко» это делают.
Наблюдения: Хотя инструменты SQA существуют уже некоторое время, они не идеальны, и не должно вызывать удивления, что они иногда дают ложные срабатывания, то есть указывают на известную уязвимость или слабость кода, которой на самом деле не существует. Исходя из этого, неудивительно, что разработчики иногда выбирают игнорировать результаты. Однако у нас есть основания надеяться, что разработчики все же уделяют время рефакторингу кода, так как 40% утверждают, что только редко игнорируют результаты сканирования. Команды разработки, которые часто сталкиваются с ложными срабатываниями, должны инвестировать в настройку инструментов, чтобы снизить количество ложных срабатываний. В случае 60% разработчиков, которые «иногда» игнорируют отчеты SQA, мы полагаем, что это связано с использованием инструментов без должной настройки и конфигурации. Важно, чтобы команды DevOps были поддержаны зрелыми инструментами SQA, соответствующими развитым стандартам качества программного обеспечения, чтобы минимизировать проблему ложных срабатываний и ложных пропусков.
Какая самая распространенная причина игнорирования метрик SQA?
Результаты: Самая распространенная причина, по которой разработчики игнорируют метрики SQA, — это нехватка времени (40% ответов), 20% указывают на ложные срабатывания, а остальные отметили «не актуально» или «другое».
Наблюдения: Одна пятая часть разработчиков, игнорирующих метрики SQA из-за ложных срабатываний, является признаком увеличения зрелости инструментов, так как мы ожидали, что эта цифра будет выше.
Следует обратить внимание бизнесу и менеджерам приложений на то, что 40% разработчиков игнорируют результаты из-за нехватки времени. Это противоречит ценностям Agile, связанным с доставкой ценности клиенту, и связано с недостаточным пониманием влияния нефункциональных требований со стороны владельцев продуктов и менеджеров продуктов. Неудивительно, что в ходе разговоров с разработчиками они часто считают, что SQA — это пустая трата времени, если они получают противоречивые сигналы от бизнеса и его представителей. Качеству программного обеспечения нужен защитник в компании, и этот вопрос должен возглавляться бизнесом.
Кто получает наибольшую выгоду от использования SQA?
Результаты: Топ-3 заинтересованных сторон, получающих наибольшую выгоду от SQA, в следующем порядке: 1) QA/Тестировщики, 2) Разработчики, 3) Операционные команды.
Наблюдения: Интересным и несколько удивительным результатом стало то, что так мало разработчиков считают, что SQA приносит непосредственную пользу конечному клиенту или бизнес-спонсору. Учитывая наше предыдущее замечание о том, что 40% разработчиков игнорируют SQA из-за нехватки времени, можно понять, почему они улавливают сообщение от бизнеса о том, что это не важно для клиента.
В каких областях качества кода SQA приносит наибольшую пользу?
Результаты: Топ-3 областей качества кода, которые получают наибольшую выгоду от анализа кода, в следующем порядке: 1) Надежность, 2) Поддерживаемость, 3) Эффективность работы.
Наблюдения: Очевидно, что разработчики понимают
взаимосвязь между SQA и классическими нефункциональными областями. Это вызывает у нас беспокойство, возвращаясь к вопросу на странице 6, о том, что результаты SQA игнорируются командами. Это также предполагает интересное наблюдение. Если разработчики считают, что SQA не приносит значительной ценности конечному клиенту, как мы видели в предыдущем вопросе, значит ли это, что они не считают надежность и производительность важными для клиента? Эти несколько противоречивые результаты возвращают нас к давно знакомой теме — нефункциональным требованиям (NFR), которые осознанно или подсознательно рассматриваются как второстепенные. Неудивительно, что надежность и безопасность занимают высокие позиции в отношении преимуществ SQA.
Использует ли ваша команда данные SQA для улучшения процессов?
Результаты: 60% разработчиков утверждают, что их команды «редко» используют данные анализа программного обеспечения на ретроспективах или для улучшения процессов, 20% делают это «иногда», а 20% — «всегда».
Наблюдения: Несколько удивительно, что только одна пятая часть разработчиков работает в командах, где результаты SQA всегда используются в процессе улучшения и на ретроспективах. SQA является индикатором зрелости как отдельных специалистов, так и команды в области разработки программного обеспечения и напрямую связано с поддерживающими практиками и ролями. Мы ожидаем, что эта цифра будет выше. Наша рекомендация заключается в том, чтобы использовать SQA не только на ретроспективах, но и в рамках процесса перекрестного обучения, чтобы помочь разработчикам улучшить свои технические навыки и архитектуру кода.
Довольны ли вы использованием инструментов SQA?
Результаты: 80% разработчиков сообщают, что они «в некоторой степени довольны» использованием инструментов анализа кода, а 20% — «очень довольны». Ни один из респондентов не сообщил о том, что он «недоволен».
Наблюдения: Хотя ни один из респондентов опроса или интервью не сказал прямо, что не нравится инструменты SQA, у нас складывается впечатление, что есть люди, которые не довольны использованием инструментов, но выбирают не высказываться об этом. В большинстве случаев (80%) разработчики говорят, что они только «в некоторой степени довольны». Это может быть связано с отсутствием калибровки и интеграции многих инструментов, что приводит к ручным процессам и ложным срабатываниям. Кроме того, в целом разработчики могут не любить, когда машина (или кто-то другой) указывает на ошибки, которые они сделали.
У нас все еще есть пути для продвижения вперед, прежде чем SQA будет восприниматься как столь же важный элемент, как непрерывная интеграция (CI) и тестируемая разработка (TDD). Тем не менее, разговор должен начаться с бизнеса и с движением от плохо названных нефункциональных требований. Если надежность, эффективность работы, безопасность и поддерживаемость будут помечены как нефункциональные, они продолжат занимать второстепенное место по сравнению с функциями для клиентов.
Заключение
Давление времени на разработчиков, владельцев продуктов и менеджеров продуктов усугубляет негативное отношение к анализу качества программного обеспечения и нефункциональным требованиям. Мы должны учитывать, что разработчики игнорируют результаты SQA и не особенно довольны использованием этих инструментов. Легко обвинять разработчиков, но мы считаем, что это отражает среду, в которой они работают. Наша рекомендация — запретить термин «нефункциональные требования» (NFRs). Пока мы этого не сделаем, NFR будут рассматриваться как второстепенные. Ясно, что разработчики получают смешанные сигналы. Несмотря на высокий процент разработчиков, использующих SQA, процент тех, кто использует его проактивно для улучшения процессов и действует на основе полученных выводов, ниже, чем хотелось бы.
Рекомендации менеджменту
Менеджеры приложений и скрам-менеджеры должны обращать внимание на свое поведение и отношение к нефункциональным требованиям. Они должны проактивно работать с владельцами продуктов или менеджерами проектов, чтобы обеспечить должное внимание к NFR. Мы обнаружили, что разговор с командой управления продуктами, сосредоточенный только на проблемах технического долга, не является конструктивным. Это обсуждение должно проводиться в контексте бизнес-результатов и рисков.
Команда управления должна обеспечить правильное использование SQA. Например, команды должны настраивать инструменты SQA для уменьшения ложных срабатываний. Также необходимо убедиться, что инструменты SQA интегрированы в цепочку инструментов. Мы должны понимать, что это может означать реорганизацию функций QA и тестирования, чтобы в командах проводилось больше качественного тестирования, связанного с NFR.
Лучшая практика заключается в том, чтобы уровень автономии, предоставленный каждой команде, был четко и последовательно связан с соответствующими количественными и качественными ключевыми показателями эффективности команды (KPI) или целями и ключевыми результатами (OKR), а именно способностью команды предоставлять код высокого качества с низким уровнем технического долга и высокой степенью поддерживаемости, надежности и производительности. Очевидно, что безопасность кода также является ключевым индикатором зрелости команды. Команды, которые не демонстрируют последовательные лучшие практики в этих областях, будут ограничены в частоте релизов, возможности подписывать изменения без утверждения и частоте код-ревью.
Признавая, что мы находимся в мире, где организации предоставляют командам разработки большую автономию, мы должны учитывать необходимость в стандартах на уровне предприятия. В ходе этого исследования мы обнаружили, что те команды, которые имеют назначенное лицо, ответственное за стандарты, которые будет использовать команда, имеют меньше инцидентов с дефектами программного обеспечения, меньший технический долг и более последовательные инструменты, т.е. меньше ложных срабатываний. Поэтому мы рекомендуем каждой команде иметь «чемпиона качества», который будет продвигать и поддерживать использование соответствующих стандартов, при этом этот человек не должен брать на себя ответственность за качество — он просто является чемпионом в команде. Мы обнаружили, что сообщества практики (COP) являются полезным инструментом для разработки стандартов, проводимой разработчиками.
С точки зрения культуры разработки, и в соответствии с Agile и DevOps, нам необходимо изменить поведение и действия команд с фокуса на обеспечение качества (QA) на фокус на инженерии качества (QE). Это выходит за рамки практик разработки на основе тестирования (TDD) или разработки на основе поведения (BDD) и требует фундаментального изменения в философии бережливого производства для обеспечения качества на каждом этапе.
Рекомендации разработке
Удивительно видеть, что уровень использования SQA выше, чем мы ожидали, однако очевидно, что нам предстоит еще пройти долгий путь, прежде чем SQA будет эффективно использовано. Наша первая рекомендация заключается в том, чтобы команды прекратили использовать термин «нефункциональные требования» (NFR) и обучили своих бизнес-аналитиков и владельцев продуктов важности NFR для конечного потребителя.
Мы рекомендуем рассматривать инструменты SQA так же, как и инструменты CI/CD, интегрируя их в цепочку инструментов с высоким уровнем автоматизации. Для того чтобы это было успешно и не создавало проблем для разработчиков, инструменты SQA должны быть настроены под среду программирования и соответствующие стандарты кодирования, чтобы сократить количество ложных срабатываний.
Команды должны использовать подход, основанный на данных, для приоритизации задач по рефакторингу. Инструменты SQA, настроенные под кодовую базу и стили программирования команды, могут помочь в приоритизации и аргументировании с владельцем продукта или менеджером продукта необходимости выделения времени на рефакторинг. Чтобы установить цели приоритизации и уменьшить внутренние споры, мы рекомендуем последовательно использовать стандарты качества кода вместе с инструментами SQA. Кроме того, команды должны использовать стандарты, которые могут быть автоматизированы и не требуют ручного вмешательства.
Учитывая низкий уровень использования метрик SQA для улучшения процессов, мы рекомендуем, чтобы все ретроспективы включали обзор панелей мониторинга SQA, даже если это будет всего лишь быстрый обзор, чтобы избежать самоуспокоенности. Если команды работают в организациях, где автономия должна зарабатываться на основе конкретных метрик, это становится еще более важным.
Наконец, командам необходимо создать убедительный бизнес-кейс для использования SQA, особенно если они работают в условиях, где NFR рассматриваются как второстепенные по сравнению с функциональностью, ориентированной на клиента. Мы обнаружили, что лучший подход заключается в том, чтобы указать на причинно-следственную связь между низким качеством и клиентским опытом, а также на положительный эффект от использования стандартного подхода к SQA для снижения технического рефакторинга, который сегодня обычно составляет 10–15% времени, затрачиваемого на спринт.
«Нефункциональные требования недостаточно подчеркиваются в управлении проектами и являются одной из основных причин перерасхода бюджета и срывов проектов. Нефункциональные требования критически важны для успеха, и необходимо уделить больше внимания подготовке к поддерживаемости, что имеет решающее значение для общей стоимости владения.»
Доктор Барри Бом, главный ученый, SERC, профессор программной инженерии TRW и директор Центра программной инженерии при Университете Южной Калифорнии
