Привет! Меня зовут Никита, с недавнего времени работаю в Cloud.ru на позиции QA-инженера, отвечаю за качество продукта для совместной разработки под названием Repo. В этой сфере я уже четыре года и успел поработать на проектах в GameDev и веб-разработке.

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

Почему документация всегда отстает

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

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

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

В результате новый человек начинает собирать знания буквально по кусочкам: что-то узнает из Confluence, что-то из Jira, что-то из кода (и то если понимает язык, на котором сервис разработан), а что-то просто задавая вопросы коллегам. И чем сложнее система, тем больше времени занимает этот процесс.

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

Как я документировал проект до появления ИИ

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

Структурировал Confluence

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

Рисовал схемы

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

Собирал FAQ

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

Писал онбординг

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

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

Как мне помогает ИИ

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

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

Я буду говорить об ИИ-инструментах в общем, но на практике использовал несколько решений. Для работы с проектным контекстом применял Claude и ChatGPT и open source модели в облаке с возможностью загрузки файлов и создания проектов, а также IDE-ассистенты для анализа кода и структуры репозиториев. Конкретный инструмент не так важен — ключевую роль играет именно наличие контекста проекта.

Быстро разобраться в новом проекте

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

• онбординг и внутреннюю документацию,

• требования,

• описание сервисов,

• диаграммы,

• структуру репозиториев,

• информацию о последних изменениях.

После этого загружаю эти материалы в контекст ИИ-агента. И вот здесь начинается самое интересное. Я перестал использовать ИИ как поисковую строку. Вместо вопросов вроде «Расскажи про проект» я разговариваю с ним так, как разговаривал бы с опытным коллегой. Например, спрашиваю:

• как проходит жизненный цикл пользовательского запроса,

• какие сервисы участвуют в его обработке,

• где реализована конкретная бизнес-логика,

• какие компоненты затронет изменение,

• какие зависимости есть у конкретного сервиса.

Если ответ кажется сомнительным, например агент написал, что проверка JWT выполняется в Gateway, а по факту оказалось, что в Auth Service, я всегда возвращаюсь к первоисточнику и проверяю его. Но даже с учетом этой проверки время погружения в проект сокращается в разы: то, на что раньше уходило три-четыре дня, теперь занимает четыре-пять часов, и это при том же уровне глубины понимания архитектуры.

Восстановить процессы тестирования

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

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

• зоны ответственности участников команды;

• процесс приемки задач;

• проверки, выполняемые разработчиками;

• проверки, остающиеся за QA;

• выкатка изменений на разные окружения (stage, prod);

• post-release процессы.

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

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

Контекст важнее модели

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

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

На практике мне удалось решить эту проблему с помощью корпоративного ИИ-агента, который использует подход RAG (Retrieval-Augmented Generation).

Если у вас нет корпоративного RAG-агента, тот же подход можно реализовать через Claude Projects, ChatGPT Projects или аналогичные инструменты с поддержкой загрузки документов. Это менее удобно, но принцип работы остается тем же: сначала собирается контекст проекта, а затем модель отвечает, опираясь именно на него.

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

• проектная документация;

• требования;

• архитектурные описания;

• схемы взаимодействия сервисов;

• технические документы;

• другие материалы, которые помогают описать устройство системы.

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

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

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

Где ИИ не помогает

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

Исторические решения и «почему так»

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

• почему бизнес-логика реализована именно так, а не иначе;

• какие решения были приняты как временные, но стали постоянными;

• какие ограничения появились из-за прошлых инцидентов;

• какие компромиссы были сделаны ради скорости релиза.

ИИ может описать текущее состояние системы, но он не знает, почему это состояние такое.

Неформальные договоренности в команде

Еще один слой знаний, который почти никогда не попадает в документацию — это договоренности между людьми, например:

• какие баги считаются приемлемыми до следующего релиза;

• какие проверки разработчики делают по умолчанию, но нигде не фиксируют;

• какие отклонения считаются критичными только в определенном контексте.

Это знание неформальное. Оно существует в коммуникации, а не в артефактах. И именно поэтому ИИ его не может восстановить.

Серая зона системы

Есть вещи, которые невозможно вывести только из документации или кода — это поведение системы в пограничных сценариях:

• нестандартные пользовательские пути,

• редкие интеграционные сбои,

• конкурирующие изменения в разных сервисах,

• поведение системы при частично неконсистентных данных.

ИИ может предположить поведение, но не может гарантировать, что оно соответствует реальности.

Ложная уверенность — главный риск

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

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

Для QA это критично, потому что задача тестирования — это не «логически красиво объяснить систему», а проверить ее фактическое поведение.

Роль QA в картине, когда ИИ не помогает

В итоге становится видно, что ИИ не заменяет роль QA в работе со знаниями о системе. Он помогает:

• быстрее собрать информацию,

• структурировать разрозненные данные,

• ускорить создание документации.

Но он не может:

• восстановить исторический контекст решений;

• зафиксировать неформальные правила команды;

• отличить реальную систему от описания;

• определить, где правда, а где устоявшееся заблуждение.

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

Мои выводы

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

Поделитесь в комментарии: как вы справляетесь с такой проблемой, к каким методам прибегаете?