Репост из: ZenTest
Страх и ненависть во внедрении LLM
Возможно, прямо сейчас вам пытаются внедрить AI-инструменты, которые заменят рутинную работу тестировщика. Или требуют срочно это сделать, потому что все побежали и нам надо. На практике это выглядит обычно так: есть какие-то подходы, какие-то результаты, красивое выступление на конференции — а вопрос «почему не взлетело» так и висит в воздухе.
Давайте разбираться в рубрике #о_сложном_на_пальцах, что на самом деле происходит
Проблема на входе и выходе
Весь хайп про «синьор с агентами заменит пять мидлов» обычно про работу одного человека, который решает свою частную задачу — или совсем как с личным проектом, или она изолирована от других участников.
Но что происходит, когда это часть большого производственного процесса?
Когда мы встраиваем AI в конкретную задачу, нужно решить три вещи: качественные данные на вход, промпты для системы и оценка результата. С промптами обычно все более-менее понятно и это основной фокус приложения усилий. Но начало и конец тонут во тьме.
Возьмем пресловутую генерацию тест-кейсов. Редко где требования полные и хорошо структурированные. В реальности это задача в две строчки, переписка в чате, комментарии к коду, обсуждения на синках и куча неявного знания в голове у тестировщика. Весь этот контекст, который собирается во время тест-анализа и тест-дизайна, просто не доходит до LLM. Т-банк в своём инструменте пытается тянуть данные отовсюду — но судя по их собственным результатам, получается не очень.
Куда смещается нагрузка
Чтобы генерировать качественные тест-кейсы, нужно больше работы сдвинуть влево — в анализ и структурирование требований. RAG-системы помогают c дополнительным контекстом, но это отдельная задача, которую тоже надо решать.
Другой путь — генерировать много и отбирать нормальное. Тогда нагрузка смещается вправо, на ревью. И вот тут тоже ловушка: проревьюить чужие тест-кейсов не проще, чем написать свои. Нужно всё равно понять общую картину, выстроить тестовые идеи и оценить покрытие. Эта ментальная модель не появляется сама собой от чтения текста.
По сути, мы меняем творческую работу по дизайну тест-кейсов и простую работу по их оформлению на сложную и часто скучную работу по их ревью. Отсылаю к докладу Наташи про человеческое тестирование в мире искусственного интеллекта.
Системная задача
LLM нельзя эффективно воткнуть в середину процесса, не меняя ничего вокруг. Это не ускорение , просто перенос проблем на другое место. И ещё вопрос: а там ли вообще узкое место? Какой смысл, если разработчик с LLM пишет в три раза больше кода, а этот код всё равно упирается в ревью и тестирование?
Сейчас международные бигтехи ищут ответы на эти вопросы, но общего решения нет. Понятно одно: это долго, сложно и дорого. Гораздо сложнее, чем «давайте генерировать тест-кейсы LLMкой».
Куда можно углубиться?
🔴Лонгрид архитектора T-банка про переход от Software Engineering 1.0 к Software Engineering 2.0. Вызовы, ограничения, подходы.
🟡Хороший и емкий разбор теории ограничений в жизни и почему писать больше кода не решает всех проблем (внезапно!)
#объясняем_на_пальцах
Возможно, прямо сейчас вам пытаются внедрить AI-инструменты, которые заменят рутинную работу тестировщика. Или требуют срочно это сделать, потому что все побежали и нам надо. На практике это выглядит обычно так: есть какие-то подходы, какие-то результаты, красивое выступление на конференции — а вопрос «почему не взлетело» так и висит в воздухе.
Давайте разбираться в рубрике #о_сложном_на_пальцах, что на самом деле происходит
Проблема на входе и выходе
Весь хайп про «синьор с агентами заменит пять мидлов» обычно про работу одного человека, который решает свою частную задачу — или совсем как с личным проектом, или она изолирована от других участников.
Но что происходит, когда это часть большого производственного процесса?
Когда мы встраиваем AI в конкретную задачу, нужно решить три вещи: качественные данные на вход, промпты для системы и оценка результата. С промптами обычно все более-менее понятно и это основной фокус приложения усилий. Но начало и конец тонут во тьме.
Возьмем пресловутую генерацию тест-кейсов. Редко где требования полные и хорошо структурированные. В реальности это задача в две строчки, переписка в чате, комментарии к коду, обсуждения на синках и куча неявного знания в голове у тестировщика. Весь этот контекст, который собирается во время тест-анализа и тест-дизайна, просто не доходит до LLM. Т-банк в своём инструменте пытается тянуть данные отовсюду — но судя по их собственным результатам, получается не очень.
Куда смещается нагрузка
Чтобы генерировать качественные тест-кейсы, нужно больше работы сдвинуть влево — в анализ и структурирование требований. RAG-системы помогают c дополнительным контекстом, но это отдельная задача, которую тоже надо решать.
Другой путь — генерировать много и отбирать нормальное. Тогда нагрузка смещается вправо, на ревью. И вот тут тоже ловушка: проревьюить чужие тест-кейсов не проще, чем написать свои. Нужно всё равно понять общую картину, выстроить тестовые идеи и оценить покрытие. Эта ментальная модель не появляется сама собой от чтения текста.
По сути, мы меняем творческую работу по дизайну тест-кейсов и простую работу по их оформлению на сложную и часто скучную работу по их ревью. Отсылаю к докладу Наташи про человеческое тестирование в мире искусственного интеллекта.
Системная задача
LLM нельзя эффективно воткнуть в середину процесса, не меняя ничего вокруг. Это не ускорение , просто перенос проблем на другое место. И ещё вопрос: а там ли вообще узкое место? Какой смысл, если разработчик с LLM пишет в три раза больше кода, а этот код всё равно упирается в ревью и тестирование?
Сейчас международные бигтехи ищут ответы на эти вопросы, но общего решения нет. Понятно одно: это долго, сложно и дорого. Гораздо сложнее, чем «давайте генерировать тест-кейсы LLMкой».
Куда можно углубиться?
🔴Лонгрид архитектора T-банка про переход от Software Engineering 1.0 к Software Engineering 2.0. Вызовы, ограничения, подходы.
🟡Хороший и емкий разбор теории ограничений в жизни и почему писать больше кода не решает всех проблем (внезапно!)
#объясняем_на_пальцах