Как тестировать AI-приложения — Практический опыт Mentorpiece

Первая статья цикла про работу AI-QA-инженера (но написана без использования AI)

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

Принять участие в AI-лихорадке я заранее не планировала. Но за последние полгода без какой-либо инициативы со своей стороны мне в Mentorpiece пришлось поучаствовать в тестировании сразу нескольких коммерческих AI-проектов (не путать с использованием AI-инструментов для тестирования). 

А каждый шестой QA-джун из наблюдаемых мной начал свою карьеру сразу в AI-компании.

Хочу поделиться своим, пусть пока небольшим, но прикладным опытом ^[1] работы с AI и рассказать, как выглядит оно, тестирование AI-приложений. И, главное, кому действительно имеет смысл погружаться в тестирование AI, а для кого это может быть преждевременно.

Мы все умрем

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

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

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

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

Каждый шестой QA-джун стартовал карьеру сразу в AI-компании

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

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

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

При разговоре же с англоязычными CEO возникает стойкое ощущение, что на западном рынке сейчас уже и пишущую ручку без встроенного AI продать решительно невозможно. 
Да, наблюдается некоторый пузырь, охотно раздутый инвесторами. Но, с другой стороны, большинство компаний, с которыми я коммуницирую, живут на свои деньги и имеют реальных платящих клиентов. Среди них есть как уже давно работающие компании с классическим софтом, сейчас внедряющие AI-функционал, так и стартапы, уже имеющие положительный cash flow.

Есть и другой индикатор – QA-джуны. На протяжении всей своей карьеры в IT я параллельно 20 лет занимаюсь IT-новичками.

За все время я могу припомнить ^[2] только одного знакомого QA-джуна, который пошел работать в тестирование крипты – причем это было его изначальным желанием.

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

Будущее профессии тестировщика

Давать прогнозы – дело неблагодарное. Явно больше меня давать их любит Всемирный экономический форум – и он обещает исчезновение 92’000’000 рабочих мест в разных отраслях экономики из-за появления AI ^[3].
Впрочем, он же обещает и появление 170’000’000 рабочих мест.
Баланс положительный.

Конечный объем изменений в IT предполагать сложно, но они явно будут бо́льшими по сравнению с теми, что нам обещали из-за блокчейна.
Многие обыватели попробовали AI и не бросили – по некоторым данным, ежемесячное число пользователей ChatGPT уже превысило число использующих Википедию.
А работодатели с инвесторами хорошо запомнили графики падения расходов и роста продуктивности.

Что это значит для профессии тестировщика?

AI-приложений уже много и будет еще больше. Сейчас любой желающий может создать работающее AI-приложение. На это уйдет несколько  часов в случае vibe-кодинга или несколько десятков минут при использовании AI-агента.

Но чтобы перевести его из состояния “ого, оно работает” до “работает правильно у пользователей в 99.9% случаев” могут уйти месяцы и годы:

• Тесла начала делать автопилот в 2013 году. Спустя 10 лет разработки он не всегда замечает стену ^[4].

• Новые AI-модели должны галлюцинировать меньше, чем старые. Но на самом деле наоборот ^[5].

• Manus ^[6], агент искусственного интеллекта ^[7], всего по паре строчек промпта с нуля проектирует, разрабатывает и даже самостоятельно тестирует полноценные приложения. Но я за минуту нашла в сгенерированном приложении критический дефект, существование которого агент признал, но за нескольких итераций перегенерации исправить так и не смог.

Доходит до смешного. Мой старый знакомый работает на должности технического менеджера в FAAMG. Как вы понимаете, у его компании есть собственные AI-разработки. И, что логично ^[8], компания внедряет одну из лично разработанных AI-моделей в одну из своих технологических платформ. Когда в нашем с ним разговоре зашла речь про процесс внедрения, качество работы модели и что обо всем этом думают инженеры его команды, знакомый с трудом выбирал цензурные слова и обещал уволиться.

Мне сложно говорить о перспективах разработчиков в AI-будущем. Возможно, через пару лет программисты будут совершенно не нужны. А может быть, наоборот, требования к их знаниям и навыкам только вырастут. Ведь такие же разговоры были и в 60-е про появление высокоуровневых языков – мол, теперь кто угодно может программировать и больше столько разработчиков не нужно.

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

Так что до такой картинки нам еще далеко:

Кому из QA-инженеров стоит изучать тестирование AI, а кому нет

Джуну, планирующему работать на международном рынке – однозначно да.

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

Мидлу/сеньору, работающему именно на русскоязычном рынке – пока скорее нет.

Почему мидлам/сеньорам на русскоязычном рынке можно пока не торопиться?
Система бронирования авиабилетов SABRE ^[9] была разработана в 1962 году и работает до сих пор, считаясь одной из древних, но все еще эксплуатируемых коммерческих IT-систем. Да, несколько раз она мигрировала с одной мейнфрейм-платформы на другую, а сейчас часть ее функционала живет в Google Cloud. Но мы-то с вами знаем, что какие-то из ключевых функций до сих пор работают на допотопном сервере в почти забытом всеми дата-центре. На этот сервер налеплен Post-It “Для правки ассемблерной вставки звонить только Майклу (говорите громче, он плохо слышит) “.
Сложно сказать, как долго еще нынешним мидлам/сеньорам придется поддерживать и развивать создаваемый сейчас код. Но в любом случае речь идет про года. На каком-то этапе AI-технологии так или иначе утрясутся, а у опытного IT-человека не займет много времени их изучить.

Другая ситуация у джунов, тем более работающих на международном рынке. 

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

Вместо заплаток на локтях – R&D

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

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

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

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

Так нам удалось поработать на AI-проекте в интересах известной каждому международной E-commerce компании.
И с агрегатором AI-провайдеров.
И с американской компанией, работающей в сфере Healthtech, тоже интегрирующей AI.

Как тестировать AI на практике?

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

Моя задача – показать, что тестирование AI хотя и отдельная от классического тестирования материя, на начальном этапе в нем нет почти ничего, что было бы связано со страшными формулами или словами вроде “тензор”.

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

Тестирование AI для джунов логично разделить на два направления: черный ящик (Black-box) и серый ящик (Gray-box).

AI-тестирование черного ящика чаще нужно в тех случаях, когда ваш проект делает классический софт, но хочет интегрировать некий AI-функционал в качестве одного из модулей. Интеллектуальный ассистент с завязкой на данные в вашей базе, функционал семантического AI-поиска на сайте или персонализированные рекомендации для пользователей. В этом случае редко кому потребуется разработка AI-модели с нуля, чаще будут использоваться готовые решения – которые потребуется допиливать напильником и проверять, что они работают как надо.
Это примерно больше половины случаев использования AI, и для тестирования такого функционала не нужно погружаться во внутреннее устройство LLM и математику ^[10].

AI-тестирование серого ящика потребуется тогда, когда AI – это ключевой функционал вашего приложения. В этом случае уже надо понимать, как устроены трансформеры (Transformers), что такое векторная база данных (Vector DB), тензор (Tensor), как выглядит неодообучение (Underfitting), переобучение (Overfitting), а также как и чем можно “снимать” accuracy, recall, precision и так далее.

Продолжение

Погружаемся в детали глубже в статье “Как тестировать AI-приложения на практике: Черный ящик, бинарный вывод” (выходит уже завтра).

Полезное AI-компаниям – бесплатно 

Разрабатываете AI-проект? Если что-то работает не так и/или хочется снизить стоимость разработки, то вот два варианта получить толковые AI-кадры бесплатно:

Работаете на AI-проекте? 

Есть вопросы? Хотите поделиться опытом или поучаствовать в нашем R&D?
Добро пожаловать в ЛС!

Полезное изучающим AI – бесплатно 

Бесплатный учебник по тестированию AI сейчас в разработке. Тысячи уже знают, например, наши бесплатные 100-Year QA-Textbook ^[12] или Оранжевый ^[13] учебник ^[14]. 

Анонсы выхода учебника и следующих статей цикла – в телеграм-каналах:
Становимся тестировщиком ^[15] – ссылки на статьи по Black-box тестированию AI.
Становимся продвинутым QA ^[16] – ссылки на статьи по Gray-box тестированию AI.