Настоящий риск ИИ в тестировании: ложная уверенность, а не ошибки

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

Сейчас утро понедельника.

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

В этом и заключается реальная опасность, которую ИИ приносит в QA.

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

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

Что на самом деле означает ложная уверенность в QA

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

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

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

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

Но не все преимущества абсолютно надежны.

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

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

Более важный вопрос сегодня для всех, кто занимается автоматизированным тестированием программного обеспечения с использованием искусственного интеллекта, должен быть не «Строит ли ИИ тесты более эффективно?», а «Действительно ли надежны тесты, построенные ИИ?»

Почему ИИ усложняет обнаружение проблемы

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

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

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

​В обеспечении качества (QA) наша уверенность должна исходить от отслеживаемости тестов, глубины покрытия, оценки рисков и наблюдаемых результатов. А не от того, насколько красиво выглядят данные, созданные ИИ.

Пять способов, которыми ИИ создает ложную уверенность в современном QA

Чрезмерное тестирование распространенных сценариев

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

Но серьезные дефекты программного обеспечения часто скрываются в других местах:

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

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

Создает плохие утверждения 

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

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

Больше количество тестовых случаев и больше недостатков

Команда может проверить 40 тестовых случаев, написанных вручную. Но они могут не применить тот же подход к 400, которые были быстро созданы с помощью ИИ. Это одна из самых больших ловушек обеспечения качества (QA) на основе ИИ: тщательное тестирование естественно уменьшается по мере увеличения количества.

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

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

Создает слепое доверие к зеленым огням

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

Делает даже слепые ошибки, которые кажутся разумными

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

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

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

Что умные команды QA делают иначе

Это не означает, что ИИ следует полностью избегать.

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

Давайте посмотрим, как это работает на практике.

Понять риск перед построением тестов

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

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

ИИ может предоставить новые идеи в таких областях. Но решать, где больше рисков, должны люди.

Проверить, что утверждает тест, а не только шаги

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

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

Поддерживать многоуровневое покрытие тестами

Один уровень тестирования сам по себе не может гарантировать, что система завершена. Модульное тестирование, API, интеграция, сквозное (E2E), исследовательское тестирование и обратная связь с производством — все выявляют различные типы рисков.

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

Будущее QA не менее человечно

Многие опасаются, что ИИ в тестировании станет бесчеловечным начинанием. Но на самом деле происходит обратное.

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

Это не о меньшем объеме работы, а о лучшем качестве. Лучшие команды будущего — это не те, кто создает бесчисленное количество тестов. Это те, кто может работать быстро и тщательно, но сомневаться там, где это необходимо.

Потому что ошибки в системах всегда видны. Но чрезмерная уверенность часто заставляет нас игнорировать их.

Уроки для вашего следующего шага

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

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

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

Итак, реальная угроза, которую ИИ представляет для QA, — это не ошибки. Скорее, это ложная уверенность, которую он дает.