Методы тестирования ПО с элементами ИИ: ожидание vs реальность

Кому из нас не знакомо это заветное слово NDA? Нам хорошо знакомо, а потому наша команда не может распространяться о своем продукте. Но все же в этой статье мы — Ирина Смердова , QA Lead в NIX и тестировщик с 7-летним опытом в IT, а также Галина Ищенко, QA Test Lead в NIX и специалист с 9-летним опытом в индустрии — поделимся интересным опытом, который вынесли из проекта.

Эта статья в первую очередь будет полезна тем, кому впервые предстоит тестировать самообучающиеся алгоритмы, а также тем, кто интересуется внедрением ИИ в реальный софт. Вы узнаете, что это за зверь такой — symantec matching engine — и как его приручить и заставить плясать под вашу дудку. Также выясним, какими знаниями нужно обладать QA-специалисту для выполнения такого рода тестирования и как настроить процесс, чтобы все прошло как можно эффективнее и комфортнее.

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

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

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

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

Черный ящик безо всяких котов

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

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

Планирование тестирования

Чтобы облегчить себе тестирование систем на базе ИИ, еще на этапе планирования обратите внимание на следующие аспекты:

  • Запросите у заказчика как можно большее количество тестовых данных (в нашем случае — это были анкеты людей). Чем больше валидных входных данных у вас будет, тем проще будет составить адекватный data setup и начать обучать систему.
  • Подберите слаженную команду. Возможно, это звучит банально, но конкретно в нашем случае данный аспект играл решающую роль. Так как системы на основе ИИ самообучаемые, то при принятии командой неверных решений в работе с ней, легко можно научить ваш ИИ плохому. В результате этого программа будет мыслить неправильно и работать некорректно.
  • Запросите у product owner-а данные о проценте допустимой погрешности системы — вы сэкономите себе уйму времени и нервов.
  • Расслабьтесь и научитесь думать нестандартно. Не пытайтесь предугадывать действия ИИ, это хоть и интеллект, но все же искусственный! Постарайтесь понять его нестандартную логику и научитесь взаимодействовать с ней.

Технические требования и (не)соответствие им

В наших требованиях ничего не говорилось об алгоритме, по которому система принимает решения. Техническая документация затрагивала только общие данные по UI. В документации также никак не был описан user-flow — пользовательский сценарий, который бы наглядно иллюстрировал порядок действий, необходимый для корректной работы системы. Сценарий: «Пользователь делает действие X, система отвечает действием Y... и все работает» — совершенно не соответствовал тому, с чем мы столкнулись. Приведенные в документации формулы отражали абстрактные принципы работы ИИ, при этом не давая никакой конкретики о его реализации в данном приложении.

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

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

Подготовка к тестированию

Перед тем, как приступить к тестированию, убедитесь, что у вас:

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

Совпадение? Не думаю...

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

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

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

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

Чек-лист тестировщика

Предлагаем сформулировать чек-лист по тестированию ПО на базе ИИ в таких позициях:

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

Ты готов выпустить это?

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

  • Заказчик понимает, что продукты на основе ИИ не могут идеально работать «из коробки». Сначала их обязательно нужно обучить, тренируя систему на валидных входных данных.
  • Если такими данными ваш product owner не располагает — настаивайте на проведении бета-тестирования и UAT (пользовательском тестировании). Участие в тестировании продукта реальных людей не заменят никакие тест-кейсы.
  • Сразу же тестируйте hot-fixes — таким образом вы сможете убедиться, что разработчики правильно проанализировали найденные вами дефекты и внесли нужные корректировки в код. Но будьте готовы к тому, что тестирование может происходить в овертайм.

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

👍НравитсяПонравилось3
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

От себя могу порекомендовать несколько ключевых слов и один базовый курс, который помог бы вам быстрее прийти к нужным выводам:
1. Во-первых, есть прекрасная статья в целом про ML, которую поймет и пятиклассник, объясняющая базовые вещи (ее можно читать и не-техническим людям): vas3k.ru/blog/machine_learning
2. Во-вторых, когда уже есть какое-то понимание того, что происходит в таких проектах, есть часть курса Andrew Ng, посвященная оптимальной структуре проектов и нюансам обучения, например, нейросеток. Это уже более продвинутое чтиво, но оно позволяет гораздо лучше понять как делать надо и как не надо: www.coursera.org/...​machine-learning-projects
3. Стоит разобраться в базовых метриках (например, Confusion Matrix, Precision/Recall/F1, Correlation Matrix, etc.), они помогут понять как оцениваются получившиеся модели, а также методах интерпретации (например, SHAP values), которые помогают понять какие факторы повлияли на решение.

Надеюсь, это поможет в следующих проектах! ;)

"

Кому из нас не знакомо это заветное слово NDA?

" — мне не знакомо, как и множеству других. Почему? Потому что это — аббревиатура, и ничего заветного в соглашении о неразглашении данных нет.

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

Якось жахливо виглядає. Виходить це було не стільки тестуваня, скільки налаштування системи.

Запросите у product owner-а данные о проценте допустимой погрешности системы — вы сэкономите себе уйму времени и нервов.

Зачем? Вы на этапе тестирования проверяете «допустимую погрешность», не понимая, как она получена( не зная алгоритма обучения и способа вычисления этой самой «допустимой погрешности»)?

Запросите у заказчика как можно большее количество тестовых данных (в нашем случае — это были анкеты людей). Чем больше валидных входных данных у вас будет, тем проще будет составить адекватный data setup и начать обучать систему.

Какое отношение обучение «системы» имеет к планированию тестирования?

Сокращу до смысла: чтобы ИИ нейросеть «правильно» работала, её надо вручную доработать напильником, фактически приняв ключевые решения за неё.

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

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

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

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