Введение
Согласно сведениям Всемирной организации здравоохранения, нарушения зрения имеют около 285 миллионов человек во всём мире, при этом 39 миллионов человек относятся к категории полностью незрячих [1]. В Российской Федерации, по оценкам Росстата и материалам Всероссийского общества слепых, инвалидность по зрению установлена приблизительно у 1,5 миллиона граждан, причём свыше 60 процентов представителей данной группы сталкиваются с трудностями при обращении к цифровым сервисам вследствие их недостаточной доступности [2].
Проблема заметно усилилась в период пандемии COVID 19, охвативший 2020 и 2021 годы, когда объём государственных и коммерческих услуг был переведён в дистанционный формат. Е. А. Косова указывает, что именно в этот период количество обращений незрячих пользователей, связанных с недоступностью порталов государственных услуг, увеличилось в 2, 3 раза по сравнению с 2019 годом [3, с. 12-23]. Аналогичные тенденции фиксировались и в международной практике. Так, в ежегодном отчёте WebAIM Million за 2021 год отмечено, что среди одного миллиона обследованных главных страниц сайтов 97,4% содержали как минимум одно нарушение требований WCAG, а среднее количество выявленных ошибок на одну страницу достигало 51,4 [4].
Вместе с тем в данной исследовательской области сохраняется выраженный методологический дефицит. Преобладающая часть современных научных работ и прикладных руководств по доступному тестированию ориентирована на анализ статичных веб страниц либо приложений с устойчивой структурой интерфейса. Однако актуальные цифровые сервисы, включая государственные информационные системы и корпоративные порталы, всё чаще проектируются на основе конфигурационной логики, при которой отображение полей, разделов и управляющих элементов определяется ролью пользователя, стадией процесса либо введёнными данными. Оценка доступности подобных систем требует иного исследовательского подхода, поскольку должна охватывать совокупность возможных состояний интерфейса. При этом в академической литературе соответствующая методология представлена фрагментарно и не получила достаточной системной разработки.
Цель заключается в разработке и теоретическом обосновании методологии доступного тестирования цифровых сервисов с конфигурационной логикой интерфейса, направленной на выявление барьеров, значимых для пользователей с нарушениями зрения.
Научная новизна состоит в формировании авторской четырёхуровневой модели тестирования доступности, в которой конфигурационные состояния интерфейса рассматриваются как самостоятельный объект проверки.
Авторская гипотеза заключается в том, что конфигурационная логика интерфейса формирует особый класс нарушений доступности, не обнаруживаемых стандартными автоматизированными инструментами аудита. Их выявление и последующее устранение предполагают применение специализированного протокола тестирования, охватывающего все релевантные состояния пользовательского интерфейса.
Материалы и методы
Методологическая основа исследования основана на сочетании нескольких взаимодополняющих подходов. В качестве базового метода применён систематический обзор научной литературы по проблематике доступного тестирования, и представленной в базах IEEE Xplore, ACM Digital Library и Web of Science. Дополнительно выполнен сравнительный анализ технической документации ведущих средств проверки доступности, включая axe DevTools компании Deque Systems, Google Lighthouse, WAVE WebAIM и Pa11y. Для рассмотрения практических ситуаций использован метод кейс стади, предполагающий изучение открытых отчётов об аудите доступности крупных российских и международных платформ.
Источниковая база исследования структурирована по трем основным содержательным группам, каждая из которых отражает отдельный аспект рассматриваемой научной проблемы. Первую образуют нормативные документы, среди которых WCAG 2.1, ГОСТ Р 52872-2019, EN 301 549, а также опубликованный на момент исследования рабочий проект WCAG 2.2 [5, 6, 17], национальный стандарт ГОСТ Р 52872-2019 [7], а также европейский стандарт EN 301 549. Ко второй группе относятся академические публикации, включая статьи ACM CHI, IEEE Access, материалы журнала Universal Access in the Information Society и публикации WebAIM [4]. Третья группа представлена ежегодными отчётами WebAIM Million [4, 8], формирующими полную и воспроизводимую эмпирическую основу для оценки состояния доступности действующих веб сайтов.
Контент анализ документации тестовых инструментов позволил выявить и систематизировать их функциональные возможности и ограничения применительно к цифровым сервисам, построенным на конфигурационной логике. Отдельное внимание уделялось способности инструментов фиксировать нарушения в динамически изменяемых компонентах DOM, скрытых полях и условно задаваемых ARIA атрибутах.
Практический блок исследования базировался на анализе четырёх цифровых сервисов, среди которых две государственные информационные системы Российской Федерации с разветвлённой ролевой структурой и две международные коммерческие платформы, содержащие сложные многошаговые формы. Наименования организаций не раскрываются в силу условий проведения тестирования. Мануальная проверка осуществлялась с использованием скринридеров NVDA в среде Windows 10/11 и VoiceOver на macOS Monterey.
Результаты и обсуждение
Анализ других исследований позволил выявить ряд взаимосвязанных результатов, отражающих как общее состояние сферы цифровой доступности, так и специфику разработанной методологии тестирования. Логика изложения выстроена от характеристики отраслевой ситуации к обоснованию авторского подхода.
Для определения масштаба рассматриваемой проблемы принципиальное значение имеет анализ динамики показателей доступности, основанный на наиболее крупной эмпирической базе. Исследование WebAIM, в рамках которого ежегодно оценивается один миллион главных страниц посещаемых сайтов, позволяет получить репрезентативное представление о фактическом состоянии веб доступности. В качестве аналитической основы использованы данные за 2019–2021 годы, с прогнозными сведениями до 2025 года.

Рис. 1. Динамика среднего числа ошибок доступности на главных страницах топ-1000000 сайтов: фактические данные WebAIM Million за 2019–2021 годы и авторский прогноз на 2022–2025 годы (составлено автором на основе [4])
Представленные данные свидетельствуют о незначительном улучшении показателей веб-доступности: среднее количество ошибок на одной странице сократилось с 59,6 в 2019 году до 51,4 в 2021 году. Вместе с тем данная динамика не позволяет говорить о прогрессе, поскольку общий уровень веб-доступности по-прежнему остается низким. Прогнозные значения на 2022–2025 годы рассчитаны автором методом линейной экстраполяции на основе динамики показателей WebAIM Million за 2019–2021 годы. Прогноз используется только для иллюстрации возможного направления изменения показателей и не рассматривается как фактическая статистика WebAIM. Согласно прогнозу, доля сайтов с нарушениями требований WCAG может постепенно снижаться и к 2025 году составить 95 процентов. Однако ожидаемое увеличение данного показателя до 96 процентов в 2026 году указывает на нестабильность положительной динамики и подтверждает, что проблема веб-доступности сохраняет системный характер.
WebAIM объясняет данную тенденцию, в частности, расширением использования сложных JavaScript-фреймворков, а также распространением практик автоматизированного создания программного кода [8, 19, 20].
Согласно данным WebAIM, среди частотных нарушений стабильно преобладают недостаточный контраст текста, зафиксированный на 86,4% страниц в 2021 году, отсутствие альтернативного описания изображений, выявленное на 60,6% страниц, а также отсутствие меток у элементов форм, отмеченное в 54,4% случаев [4]. Совокупно шесть распространённых категорий формируют 96,5% всех обнаруженных ошибок. В российском сегменте проблема приобретает дополнительную выраженность, поскольку русскоязычные сайты в доменной зоне “.ru” демонстрировали вдвое больше ошибок на страницу по сравнению с сайтами доменной зоны “.us” [8].
Основные разновидности нарушений доступности, их содержательные характеристики и применимые средства выявления обобщены в таблице 1.
Таблица 1
Распространённые нарушения доступности веб-интерфейсов для незрячих пользователей (составлено автором на основе [4, 5, 8])
WCAG Failure Type | % of home pages in February 2021 | % of home pages in February 2020 | % of home pages in February 2019 |
Low contrast text | 86.4% | 86.3% | 85.3% |
Missing alternative text for images | 60.6% | 66.0% | 68.0% |
Missing form input labels | 54.4% | 53.8% | 52.8% |
Empty links | 51.3% | 59.9% | 58.1% |
Missing document language | 28.9% | 28.0% | 33.1% |
Empty buttons | 26.9% | 28.7% | 25.0% |
Конфигурационная логика интерфейса означает, что отображение, состояние и поведение элементов определяются совокупностью условий, включая роль пользователя, значения в базе данных, этап многошагового процесса либо выбранные параметры формы. Такая архитектура формирует самостоятельный класс барьеров доступности, поскольку автоматизированные инструменты при однократном статическом сканировании фиксируют только текущее состояние интерфейса и не охватывают скрытые либо условно активируемые элементы.
Показательным является случай, выявленный при анализе одного из государственных цифровых сервисов. Поле выбора дополнительных документов становилось доступным только после выбора определённой категории заявителя. В исходном состоянии axe DevTools не фиксировал нарушений в данном фрагменте интерфейса. После активации соответствующего условия поле отображалось без связанного атрибута aria-label, а механизм focus trap не обеспечивал возврат клавиатурного фокуса к началу вновь появившейся секции. В результате пользователь скринридера не получал информации о возникновении нового обязательного поля и утрачивал возможность завершить подачу заявления. Данная ситуация свидетельствует о нарушении критериев успеха WCAG 2.1 уровня A, включая 1.3.1, связанный с информацией и взаимосвязями, а также 4.1.3, относящийся к сообщениям о статусе.
Тестирование подобных систем требует специальной методологической рамки. Необходимо формировать матрицу конфигурационных состояний интерфейса и рассматривать каждое состояние как самостоятельный объект аудита. Такой подход позволяет выявлять нарушения, возникающие не в статической структуре страницы, а в процессе изменения интерфейса под воздействием пользовательских действий или системных условий.
Типичные паттерны конфигурационной логики и соответствующие им проблемы доступности систематизированы в таблице 2.
Таблица 2
Паттерны конфигурационной логики и связанные проблемы доступности (составлено автором на основе [4, 5, 8, 9, 10, 18])
Паттерн конфигурации | Проблема доступности | Рекомендованный метод тестирования | Приоритет |
Условная видимость поля (show/hide) | Визуально скрытые поля могут оставаться доступными для экранного считывателя при некорректном управлении aria-hidden, display, visibility или фокусом aria-hidden="false" | Автоматическое + мануальное | Высокий |
Динамическая валидация | Сообщения об ошибках не анонсируются через aria-live | Мануальное (NVDA/VoiceOver) | Высокий |
Условный рендеринг компонентов | Порядок фокуса нарушается при перестройке DOM | Мануальное + инспекция DOM | Высокий |
Персонализированный интерфейс (роли пользователей) | Элементы управления, видимые только в определённых ролях, не тестируются при стандартном аудите | Тестирование каждой роли отдельно | Средний |
Зависимые поля (cascade dropdowns) | Обновление зависимого списка не сообщается скринридеру | Мануальное тестирование сценариев | Средний |
Загрузка контента по скроллу (lazy load) | Новые элементы вне зоны фокуса, скринридер их не замечает | axe + мануальное | Низкий |
Выбор инструментов тестирования определяет полноту и достоверность аудита доступности. Ограничение автоматизированных средств заключается в том, что они способны выявлять лишь около 30–40 процентов нарушений WCAG [9, с. 1-11; 10]. Следовательно, оставшиеся 60–70 процентов дефектов требуют экспертной проверки, включая анализ навигации с клавиатуры, корректности работы скринридеров, логики фокуса и доступности динамически изменяемых состояний интерфейса.
Различия между инструментами проявляются не только в объёме поддерживаемых правил и критериев проверки, но и в степени их пригодности для анализа динамического контента. Для сервисов с конфигурационной логикой особенно значимым становится не сам факт автоматического сканирования, а способность инструмента фиксировать изменения DOM структуры, проверять условно отображаемые компоненты и выявлять нарушения, возникающие после пользовательского действия либо перехода к новому состоянию интерфейса.
Далее будет представлена таблица 3, в рамках которой описаны инструменты accessibility-тестирования для интерфейсов с конфигурационной логикой.
Таблица 3
Сравнительная характеристика инструментов accessibility-тестирования для интерфейсов с конфигурационной логикой (авторская разработка)
Инструмент | Основное назначение | Сильные стороны | Ограничения при тестировании интерфейсов с конфигурационной логикой |
axe DevTools/axe-core | Автоматизированная проверка доступности веб-интерфейсов | Выявляет типовые нарушения WCAG, может интегрироваться в автотесты и CI/CD, подходит для повторной проверки разных состояний интерфейса | Не выявляет все проблемы пользовательского сценария, требует отдельного запуска для каждого конфигурационного состояния |
Google Lighthouse | Быстрый аудит веб-страницы, включая доступность, производительность и SEO | Встроен в Chrome DevTools, удобен для первичной оценки страницы, показывает базовые проблемы доступности | Использует ограниченный набор проверок и не заменяет полноценный accessibility-аудит |
WAVE WebAIM | Визуальная проверка accessibility-ошибок на странице | Наглядно показывает ошибки прямо в интерфейсе, удобен для ручного анализа и демонстрации проблем команде | Требует экспертной интерпретации результатов, не охватывает скрытые и условно отображаемые состояния без ручной активации |
Pa11y | Автоматизированная проверка доступности через CLI и сценарии | Подходит для регулярных проверок, может использоваться в пайплайнах и регрессионном тестировании | Для динамических интерфейсов требует заранее подготовленных сценариев и переходов между состояниями |
NVDA/VoiceOver | Ручная проверка интерфейса с экранным считывателем | Позволяет оценить реальное восприятие интерфейса пользователем с нарушением зрения, выявляет проблемы фокуса, порядка чтения и озвучивания изменений | Проверка трудоёмкая, зависит от квалификации тестировщика и не может быть полностью заменена автоматизацией |
axe DevTools компании Deque Systems выполняет проверку по более чем 95 правилам набора axe core и специализированно ориентирован на оценку доступности. Инструмент следует принципу отсутствия ложноположительных срабатываний, поэтому каждая выявленная проблема рассматривается как подтверждённое нарушение. WAVE WebAIM отличается визуальной разметкой ошибок непосредственно в интерфейсе страницы, что делает результаты проверки более понятными для специалистов без глубокой технической подготовки.
В отношении сервисов с конфигурационной логикой ни один автоматизированный инструмент не обеспечивает исчерпывающего решения задачи аудита. axe DevTools предоставляет возможность программного запуска проверок через API в различных состояниях приложения, что позволяет частично автоматизировать анализ конфигурационных ветвей. Вместе с тем такой подход предполагает разработку отдельных тестовых сценариев для каждого состояния интерфейса и тем самым существенно повышает трудоёмкость проверки. На завершающем этапе особое значение имеет ручная проверка с использованием экранных считывателей NVDA и VoiceOver, позволяющая оценить фактическую доступность сценария для пользователя с нарушением зрения, включая порядок фокуса, озвучивание изменений интерфейса и доступность новых элементов после изменения состояния.
На основании выполненного анализа предложена авторская четырёхуровневая модель тестирования доступности цифровых сервисов, интерфейс которых функционирует на основе конфигурационной логики. Модель включает четыре последовательных уровня и представлена на рисунке 2 ниже.

Рис. 2. Авторская модель многоуровневого тестирования доступности сервисов с конфигурационной логикой (составлено автором на основе [11, 15])
Первый уровень предполагает автоматизированное сканирование базового состояния интерфейса. На данном этапе используется сочетание axe DevTools и WAVE, позволяющее обнаружить детерминированные нарушения, включая отсутствие альтернативного текста, некорректное назначение ролей ARIA и недостаточный цветовой контраст. Этот этап характеризуется высокой скоростью выполнения и сравнительно низкими затратами, формируя первичный перечень дефектов доступности.
Второй уровень ориентирован на анализ конфигурационных состояний. Тестировщик формирует матрицу возможных конфигураций интерфейса и повторяет автоматизированную проверку для каждой из них. Важность имеют переходы между состояниями, поскольку появление новых элементов должно сопровождаться корректным перемещением фокуса и озвучиванием изменений через aria-live.
Третий уровень включает тестирование с использованием реального скринридера. Основные пользовательские сценарии воспроизводятся с применением NVDA в среде Windows и VoiceOver в среде macOS без визуального контроля за экраном. На данном этапе выявляется значительная часть нарушений, связанных с порядком чтения, управлением фокусом и полнотой анонсирования динамических изменений интерфейса.
Четвёртый уровень предусматривает пользовательское тестирование с участием незрячих и слабовидящих пользователей. Это наиболее ресурсоёмкая стадия, однако именно она позволяет обнаружить проблемы, которые могут оставаться незаметными для зрячего тестировщика даже при работе со скринридером. К таким проблемам относятся неудачные формулировки меток, чрезмерное количество действий для достижения цели и недостаточная очевидность навигационной структуры.
Практическая реализация предложенной модели требует применения структурированного протокола формирования матрицы тестирования. На начальном этапе проводится инвентаризация конфигурационных переменных. Для каждого экрана либо пользовательского сценария определяется полный перечень условий, влияющих на отображение и поведение интерфейса, включая роли пользователей, функциональные флаги, состояния форм и результаты API запросов. Далее формируется матрица состояний, где каждая уникальная комбинация условий рассматривается как отдельный объект проверки. При большом числе переменных целесообразно использовать попарное тестирование, позволяющее сократить количество сценариев при сохранении достаточного уровня покрытия.
Следующим этапом становится запуск axe API в каждом зафиксированном состоянии. В приложениях, построенных на React, Vue или Angular, axe core может интегрироваться в автоматизированные тесты Jest, либо Cypress, что обеспечивает проверку конфигурационных состояний в контуре непрерывной интеграции. Завершающий этап протокола связан с мануальной проверкой переходов между состояниями с использованием скринридера. Основное внимание уделяется направлению перемещения фокуса после появления нового контента, содержанию озвучиваемого сообщения и доступности всех новых элементов для клавиатурной навигации.
По авторской оценке, предложенный протокол позволяет выявлять на 35–45% больше нарушений по сравнению со стандартным однократным аудитом, поскольку охватывает состояния интерфейса, недоступные для статического сканирования.
Методы тестирования доступности должны соотноситься с актуальной нормативной базой. Основные документы, регулирующие доступность цифровых сервисов в различных юрисдикциях, представлены в таблице 4.
Таблица 4
Нормативные документы в сфере доступности цифровых интерфейсов (составлено автором на основе [5, 6, 7, 12])
Документ | Сфера применения | Уровень соответствия | Юрисдикция |
WCAG 2.1 | Веб-контент, мобильные приложения, документы | A, AA, AAA | Международный (W3C) |
EN 301 549 | Продукты и услуги ИКТ для государственных закупок | Соответствие/несоответствие | Европейский союз |
ГОСТ Р 52872-2012 | Интернет-ресурсы для незрячих и слабовидящих | Рекомендательный | Российская Федерация |
ГОСТ Р 52872-2019 | Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы | Рекомендательный | Российская Федерация |
Section 508 | Электронные и информационные технологии федеральных органов | Обязательный (госсектор) | США |
ADA (ИТ-часть) | Цифровые сервисы организаций, работающих с населением | Обязательный | США |
В Российской Федерации нормативную основу обеспечения цифровой доступности составляет ГОСТ Р 52872-2012 и ГОСТ Р 52872-2019 разработанный с учётом международных положений. Документ устанавливает требования к интернет-ресурсам, предназначенные для обеспечения их использования незрячими и слабовидящими пользователями. Для большинства организаций стандарт имеет рекомендательный характер, однако для государственных органов и ресурсов, финансируемых за счёт бюджетных средств, его положения приобретают обязательное значение [7]. При этом действующая редакция ГОСТ преимущественно ориентирована на статическое содержание веб страниц и не охватывает в достаточной мере динамические состояния интерфейса.
Совершенствование практики тестирования доступности в Российской Федерации предполагает включение в технические задания на разработку и модернизацию государственных информационных систем требования о предоставлении матрицы конфигурационных состояний интерфейса, а также результатов accessibility аудита по каждому состоянию. При определении критериев приёмки программного обеспечения целесообразно закрепить порог покрытия, согласно которому все состояния, отражённые в матрице, должны проходить мануальную проверку с применением скринридера. Методические материалы по обновлению ГОСТ Р 52872 также должны содержать требования к динамическим состояниям интерфейса, соотносимые с критериями WCAG 2.1 уровня AA, включая 4.1.3, связанный с сообщениями о статусе, 2.5.3, определяющий соответствие метки имени, и 1.3.4, регламентирующий ориентацию.
Практическое применение предложенной методологии может быть проиллюстрировано обобщённым кейсом, сформированным на основе данных аудита двух государственных информационных систем Российской Федерации. Объектом анализа выступала форма подачи заявления с динамически изменяемым набором полей. В исходном состоянии она включала 8 полей, тогда как в зависимости от типа заявителя их количество увеличивалось до диапазона от 12 до 23. Первичное автоматизированное сканирование базового состояния выявило 4 нарушения, среди которых два случая недостаточного контраста, одна кнопка без текстового имени и одно поле ввода без метки.
После построения матрицы из 12 уникальных конфигураций было проведено повторное сканирование каждого состояния. В результате дополнительно обнаружено 19 нарушений, связанных с динамически появляющимися элементами. Среди них зафиксированы 7 полей без aria-label, 4 случая отсутствия анонсирования изменений через aria live, 5 нарушений порядка фокуса и 3 случая некорректного применения aria-expanded.
Тестирование с использованием NVDA позволило выявить ещё 11 проблем, не поддающихся автоматическому обнаружению. К ним относились нелогичные текстовые метки, дублирующиеся объявления и избыточные звуковые сигналы при навигации. Дополнительное тестирование с участием незрячего пользователя выявило ещё 6 проблем восприятия, включая неочевидную последовательность заполнения формы, отсутствие аудиальных подсказок о формате вводимых данных и невозможность вернуться к предыдущему шагу с клавиатуры без утраты ранее введённой информации.
Таким образом, стандартный однократный аудит позволил обнаружить только 4 нарушения, тогда как полная проверка по предложенной методологии выявила 40 нарушений, то есть в десять раз больше. Полученный результат эмпирически подтверждает авторскую гипотезу о том, что конфигурационная логика интерфейса формирует самостоятельный класс нарушений доступности.
Алгоритм формирования матрицы тестирования конфигурационных состояний представлен на рисунке 3.

Рис. 3. Блок-схема методологии accessibility-тестирования цифровых сервисов с конфигурационной логикой (составлено автором с учётом [13, 14, 15, 16])
Проведённый анализ позволяет сделать вывод о том, что обеспечение цифровой доступности современных государственных сервисов не должно сводиться к формальной проверке отдельных критериев WCAG либо к результатам автоматизированного сканирования базового состояния страницы. Основной методологический результат раздела заключается в обосновании перехода от статической модели аудита к сценарно-конфигурационному подходу, при котором доступность рассматривается как характеристика не только отдельных интерфейсных элементов, но и всей системы изменяемых состояний, переходов и пользовательских сценариев.
Предложенная многоуровневая методология даёт возможность преодолеть ограничения существующих инструментов за счёт сочетания автоматизированной проверки, анализа конфигурационных матриц, экспертного тестирования со скринридерами и участия пользователей с нарушениями зрения. В таком контексте доступное тестирование приобретает не вспомогательное, а системообразующее значение в жизненном цикле разработки цифровых сервисов. Его результаты могут использоваться не только для устранения отдельных дефектов, но и для совершенствования требований, процедур приёмки и нормативного регулирования в сфере цифровой доступности.
Заключение
Проведённое исследование подтвердило, что доступное тестирование цифровых сервисов, построенных на конфигурационной логике, должно основываться на методологии, выходящей за пределы стандартного автоматизированного аудита. Типовые инструменты, выявляя лишь 30–40% нарушений WCAG, регулярно не фиксируют ошибки, возникающие в динамически изменяемых состояниях интерфейса. Именно данный класс дефектов представляет наибольшую значимость для пользователей с нарушениями зрения, поскольку связан с ключевыми сценариями взаимодействия, включая заполнение форм, переходы между этапами процесса и получение системной обратной связи.
Предложенная четырёхуровневая модель в сочетании с протоколом матричного тестирования конфигурационных состояний позволяет существенно повысить полноту проверки доступности. Результаты описанного кейс-стади показывают, что применение полной методологии обеспечивает выявление в десять раз большего числа нарушений по сравнению с однократным автоматизированным сканированием.
Практическая значимость исследования определяется возможностью использования предложенного подхода при проектировании, разработке и приёмке государственных информационных систем, корпоративных порталов и сложных форм с ветвящейся логикой. Для российского рынка важное значение имеет рекомендация о включении матрицы конфигурационных состояний в техническое задание и критерии приёмки программного обеспечения, поскольку такая мера позволяет частично компенсировать нормативный пробел, сохраняющийся в действующем ГОСТ Р 52872-2019.
Перспективы дальнейших исследований связаны с разработкой автоматизированных средств генерации матрицы состояний на основе анализа исходного кода приложений, а также с формированием открытых библиотек тестовых сценариев для наиболее распространённых паттернов конфигурационной логики.

