Ограничения искусственного интеллекта: он не способен самостоятельно оценивать результаты своей работы.

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

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

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

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

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

Общие предположения создают общие слепые пятна.

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

Тот же принцип применим и к искусственному интеллекту.

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

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

В результате может получиться система, которая технически безупречна, но практически несовершенна.

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

Это не всегда связано с обучением системы во время каждого запуска; это также результат вероятностной генерации, изменений контекста и эволюции модели. Такая изменчивость может быть чрезвычайно полезна, когда команды ищут решения, но она противоречит фундаментальному принципу обеспечения качества (QA). А именно, контролируемый тест должен быть воспроизводимым для той же версии, в тех же условиях, с четко определенными ожидаемыми результатами и доказательствами успеха или неудачи.

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

Успех в карьере — это не успех пользователя.

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

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

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

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

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

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

Почему визуальная проверка важна?

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

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

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

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

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

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

Итеративный подход превращает автоматизацию в надежное руководство.

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

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

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

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

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

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

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

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

Регулируемая среда повышает риски.

Последствия ошибок интерфейса распределяются неравномерно.

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

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

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

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

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

В таких условиях интерфейс — это не просто декоративный элемент; он является неотъемлемой частью системы оперативного управления.

Сочетание скорости и контроля

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

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

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

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

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

Ценность заключается в сочетании этих методов, а не в требовании замены всех остальных одним методом.

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

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