Управление качеством при разработке программного обеспечения

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

Работа с дефектами (в частности, их раннее выявление и анализ) позволяет предотвращать ошибки на этапе разработки софта. При таком подходе сокращаются затраты времени, денег и других ресурсов на исправление логических, синтаксических, компиляционных и других ошибок ПО. Улучшается качество продукта, повышается его ценность в плане надежности, легкости обслуживания и экономичности [1]. В [2] описано управление качеством в сложных технологических процессах. Автор показывает, как выявить взаимосвязь между технологией и качеством. По его предположению, существует информационное соответствие между вероятностыми моделями технологии и качеством. Из [3] известно, что в сфере информационных технологий (ИТ) увеличение бюджета на 49 % приводит к созданию новых моделей управления качеством. В качестве примера можно назвать стандарты ISO/IEC [4]. В [5] показано, как управление качеством влияет на производственные процессы.

Важная и сложная задача — автоматизация контроля процессов, от которых зависит качество. Ключевая форма контроля — статистическая. Она работает с индикаторами, критичными для качества конечного продукта (от англ. critical to quality (CTQ)). Эти показатели отслеживаются и сравниваются с целевыми значениями. В результате получают заключение о статистической управляемости или неуправляемости процесса [6].

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

Отдельное направление исследований — взаимосвязи между основными инструментами менеджмента качества и их влияние на операционные, финансовые и рыночные показатели компании-производителя. При этом интегрированное использование и управление таким инструментарием — актуальная задача [8].

В [9] показано, как различные практики управления качеством влияют на инновации в компаниях, сертифицированных по ISO 9001. Некоторые исследования посвящены учету практических рекомендаций при разработке жизненного цикла продукта. Из [10] известно, что 60–80 % потенциальных ошибок при разработке инновационных продуктов связаны с неправильно понятыми требованиями. Авторы [11] утверждают, что при обсуждении качества продукта следует прояснить вопросы качества кода, стоимости достижения заданного качества и времени выхода на розничный рынок. В вопросах автоматизации качества особая роль отводится непрерывной интеграции (или непрерывной доставке) программного кода [12]. Так называется процесс, который обеспечивает постоянное обновление кода при разработке софтверного продукта. В [13] даются рекомендации, как учитывать уровень конкуренции в отрасли при последовательном выпуске новых версий продукта.

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

Роль управления качеством при разработке ПО. Качество — это комплексная категория, которую можно рассматривать с разных точек зрения: философской, социальной, технической, экономической, правовой [1]. В данной статье качество обсуждается как совокупность свойств товара или услуги, способных в той или иной степени удовлетворять потребности целевой аудитории [3]. Продукт рассматривается как суммарный результат разных видов деятельности, причем у каждой — свои входные данные (параметры) которые в результате производственного процесса превращаются в выходные (ценность). Продукт — это совокупность ценностей. Он предназначен для удовлетворения потребностей, которые определяются заранее, при маркетинговой разработке товара или услуги. О качестве продукта судят по тому, насколько реальная удовлетворенность потребителя совпадает с запланированной.

В области информационных технологий основными считаются две группы требований к продукту (потребности пользователей): функциональные и нефункциональные. Как и на любом рынке, при розничной реализации ИТ-решений точно выстроенная работа с ценностью обеспечивает лояльность целевой аудитории, а значит, повышает рентабельность выпуска программного обеспечения, приложений и аналогичной продукции.

Реализованные дефектные товары портят имидж производителя [8]. Негативные отзывы распространяются в сети и мессенджерах. Потеря пользователей ведет к ухудшению финансовых показателей. Кризис качества может обернуться банкротством производителя.

В [6] показано, что менеджмент качества через управление процессами связан со всеми пятью типами инноваций. Перечислим факторы, которые их формируют:

• новая техника и технологии;
• продукция с новыми свойствами;
• новое сырье;
• новая организация производства;
• новые рынки сбыта.

Материалы и методы. Научные изыскания, результаты которых обобщены в представленной статье, базировались на глобальной практике производства и реализации софтверных товаров и услуг. Кроме того, изучалась литература, посвященная созданию и продвижению ИТ-решений. Теория соотнесена с практикой деятельности крупнейших разработчиков программного обеспечения. Теоретическая часть дает представление о специфике разных методов управления качеством. Приводятся примеры их практического использования при управлении жизненным циклом продукта. С этой точки зрения рассмотрены некоторые подходы к менеджменту проектов — гибкие, каскадные (второе название — водопадные) и гибридные.

Исследуется организация и координация релизов (выпусков) программного обеспечения. Это тесно связано с управлением качеством, однако редко или фрагментарно рассматривается в литературе.

Практика реализации крупных проектов соотносится с хорошо изученной теорией управления качеством. Это позволяет точно определить, как крупные организации задействуют теоретическую базу для обеспечения качества информационных продуктов (а в итоге — для их коммерческой успешности).

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

Виды тестирования программного обеспечения. Как показано в [7], на рынке (то есть вне компании-производителя) восприятие качества (как элемента конкурентного преимущества) определяется в процессе проектирования продукта, статистического контроля и обратной связи. Представление о качестве внутри компании зависит от того, какой процент продукции проходит все проверки и в итоге не требует доработки. Этот показатель связан главным образом с управлением процессами, а не со статистическим контролем и обратной связью.

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

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

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

Соответствие продукта функциональным и нефункциональным требованиям проверяется по-разному.

На рис. 1 представлена пирамида тестирования функциональных требований. Виды испытаний ранжированы по важности, скорости, стоимости и доле успешных проверок.

Юнит-тестирование, или модульное тестирование — это проверка корректности отдельных модулей исходного кода программы, отдельных функций приложения или сервиса. В результате устанавливается, работоспособен ли код, дает ли он правильные результаты при различных входных данных, соответствует ли логика ожидаемой. Пример такого теста: при сложении двух чисел должна получиться их сумма. В функцию вводятся входные значения, необходимые для проверки. Юнит-тест пройден, если ожидаемый результат функции равен фактически полученному. Для расчета метрики соотносят количество строк кода, прошедших тест, и общее число строк кода в репозитории. Лучшим индикатором считается 80 %. Он показывает, что логика любой функции соответствует ожидаемой на 80 % еще до того, как начинается следующая стадия тестирования. Значит, проблемы выявляются довольно рано и решаются гораздо дешевле и быстрее. Поэтому юнит-тест — первая ступень в пирамиде функционального тестирования. Его отсутствие (как и любых других видов тестирования) создает пробелы, накопление которых ведет к необоснованному удорожанию проекта [15].

Интеграционное тестирование. На следующем этапе тестируется взаимодействие компонентов будущего приложения. Проверяется интеграция модулей. Эти испытания сложнее юнит-тестирования, т. к. проверяется возможность выполнить последовательные действия в различных компонентах. Пример: пользователь входит в систему — перенаправляется на главную страницу — размещает объявление. То есть тестируются сразу несколько модулей. Ниже перечислены основные варианты интеграционного тестирования.

«Большой взрыв». Все компоненты собирают и совместно испытывают. Это позволяет выполнять тестирование один раз после разработки. Однако при большом количестве модулей какой-то можно упустить из виду, и это слабое место метода. К тому же увеличивается петля обратной связи, так как тестируются готовые решения, когда разработка завершена. Отметим также сложности с локализацией ошибки. Они объясняются тем, что придется проанализировать весь процесс (сценарий) разработки, чтобы узнать причину проблемы. Это значит, что время тестирования увеличится. Метод однозначно удобен для небольших систем.

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

Интеграция снизу вверх. Сначала тестируются самые некритичные модули, затем более значимые и
наконец — базовые. Следовательно, верхние компоненты нельзя проверить, пока нет данных о качестве элементов нижнего уровня. Это увеличивает время между разработкой и стартом тестирования.

Интеграция сверху вниз. Тестирование начинается с наиболее значимых уровней приложения. В данном случае испытание модулей нижних уровней может быть не вполне адекватным. Однако даже если впоследствии это обернется проблемами, они будут некритичными.

Гибридная интеграция. Модули разных уровней тестируются совместно. Успешность такой проверки определяется тем, понимает ли исполнитель архитектуру приложения и может ли определить оптимальный подход к конкретному продукту [12].

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

Системное тестирование требует значительного времени, поскольку с развитием продукта растет количество возможных вариантов ее использования. Следовательно, софт нужно своевременно обновлять. Этим занимается служба поддержки. При каждом обновлении продукта необходимо проверить, работают ли ранее протестированные функции. Этот процесс называется регрессионным тестированием. Если ранее тесты работали, а после ввода новой функции перестали, значит, есть проблема. Процедура такой проверки иногда занимает колоссальное количество рабочего времени инженеров по тестированию, и они не успевают писать новые тесты. Этим обусловлена важность автоматизации испытаний, которые выполняются вручную. При таком подходе тестирование оптимизируется до простого анализа результатов автоматических проверок. Лучший вариант — это 100-процентная автоматизация. Достичь такого показателя не всегда возможно, поскольку некоторые тесты не подлежат автоматизации из-за их сложности [16].

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

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

Нефункциональное тестирование проверяет приложение на:

• производительность;
• надежность;
• совместимость;
• безопасность;
• полезность;
• масштабируемость.

Для проверки этих свойств используют более 15 видов тестирования. Назовем наиболее распространенные.

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

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

Тестирование отказоустойчивости. Испытывается способность системы или приложения сохранять работоспособность при сбоях или непредвиденных ситуациях. Цель такого тестирования — обнаружение уязвимостей и разработка мероприятий для обеспечения непрерывной работы.

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

Тестирование безопасности. Оценивается уровень защищенности системы или приложения от атак и потенциальных угроз безопасности. Выясняется, есть ли уязвимости, анализируются защитные механизмы и эффективность мер безопасности.

Тестирование аварийного восстановления. Определяется способность системы или приложения восстанавливаться после сбоев, отказов или других чрезвычайных ситуаций. Цель — проверка эффективности процедур восстановления и минимизация времени простоя в случае аварийных ситуаций.

Результаты исследования. В рамках представленного исследования сформирована комплексная модель управления качеством при создании ПО. Описаны ее взаимосвязи с жизненным циклом разработки, релизами, издержками и моделью менеджмента проектов (гибкой, каскадной или гибридной).

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

Анализ и определение требований к продукту. Исследуются проблемы, предлагаются решения с учетом заявленных требований. Этот процесс задает основные показатели для проверки готового продукта. В зависимости от модели разработки описываются и согласовываются стратегия, подходы и инструменты тестирования. Один из документов называется «Видение продукта и его возможности». В нем фиксируются выявленные проблемы, отмечаются связи с бизнес-планом, описывается конъюнктура рынка, перечисляются основные функциональные и нефункциональные требования. Документ утверждают стороны-партнеры (то есть представители исполнителя и заказчика). При необходимости в текст вносят корректировки. На этом этапе важно привлечь специалистов по безопасности и архитектуре приложений, которые помогут точно определить нефункциональные требования, важные для будущего тестирования.

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

Разработка. Создается код для решения задач и проблем будущих пользователей. Для проверки логики отдельных функций пишутся юнит-тесты. Основная цель — достичь нужного показателя покрытия кода тестами (не менее 80 %). Однако широко применяются и другие практики — такие как аудиты кода (code review). В этом случае код проверяют другие члены команды, и на ранних стадиях разработки выявляются ошибки, недочеты, пропуски и уязвимости. Ревьюеры могут оставлять комментарии к конкретным строкам кода, указывая на необходимость переработки. С точки зрения качества продукта идеальный сценарий — двойное код-ревью, когда минимум два не связанных с автором специалиста рассматривают и комментируют код.

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

Тестирование. Инженеры по тестированию разрабатывают адекватные задачам тест-сценарии. Как правило, они пишутся вручную, что замедляет реализацию данного этапа. Целесообразно автоматизировать процесс, однако это не всегда возможно. На данной стадии специалисты проверяют и при необходимости перепроверяют результаты ручных и автоматизированных тестов. Особое внимание уделяется случаям, когда автоматические тесты выявляют ошибки. Важно установить, реальная ли это ошибка, или ложноположительный результат. Обнаруженные дефекты ранжируются в зависимости от их важности для системы или пользователей, а затем передаются разработчикам для исправления. После устранения дефектов полезно провести анализ корневой причины проблемы с использованием метода RCA (англ. root cause analysis — анализ причин). Это позволяет разработать меры по предотвращению проблем в будущем, добавить новые юнит- или интеграционные тесты. Для полного понимания причин проблемы рекомендуется использовать технику «5 почему» (англ. 5 Why’s). Схема метода выглядит так: формулируется проблема и задается вопрос: «Почему это случилось?». На него следует ответ, описывающий определенный факт или ситуацию. Вновь задается вопрос: «А это почему случилось?». И так пять раз. Пять ответов позволяют приблизиться к пониманию причин проблемы.

Тестирование — это масштабный процесс. Ниже перечислены его основные этапы.

1. Настройка и конфигурация окружения для тестирования.
2. Написание и выполнение ручных тест-сценариев.
3. Автоматизация ранее написанных ручных тест-сценариев.
4. Проверка результатов автоматических тестов.
5. Поддержка актуальности автоматических тест-сценариев и исправление ошибок.
6. Фиксация дефектов.
7. Документирование дефектов.
8. Анализ причин дефектов.
9. Разработка шагов по предотвращению появления дефектов в будущем.

Развертывание кода приложения. Программное обеспечение требует различных сред для развертывания. Важно хорошо представлять, как непрерывная интеграция и непрерывное развертывание (англ. continuous integration and continuous deployment, CI/CD) обеспечивают стабильное качество ПО при минимальных трудозатратах. Этому способствует в первую очередь автоматизация развертывания кода — перенос его изменений из одной среды в другую. Процесс делится на этапы, которые зависят от продукта, организации и принятых стандартов.

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

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

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

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

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

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

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