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

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

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

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

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

Мы все умрем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему мидлам/сеньорам на русскоязычном рынке можно пока не торопиться?
Система бронирования авиабилетов SABRE была разработана в 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 и математику.

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

Продолжение

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

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

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

Скрытый текст

Получите в штат QA-специалиста, который уже имеет практический опыт работы с AI. Мы никаких комиссий не берем, платите зарплату напрямую ему. Наш интерес: чтобы AI-QA-специалист получил полную загрузку по специальности.
Целая QA-команда под руководством опытного QA-лида на 3+ месяца от Mentorpiece. Мы также никаких денег не берем и в этом случае даже зарплату платить никому не надо. Наш интерес: интересные R&D задачи. В 2/3 случаев одного-двух интернов компания оставляет в штат.

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

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

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

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

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

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