Лига тестировщиков

Привет, Пикабу!
Это мой первый пост. В нём я хочу поделиться опытом, с чего можно начать изучение LLM тестировщику.

Я — Full-stack QA, в тестировании уже более 8 лет. В рабочем порядке пишу автотесты на Python для разных бэкендов/фронтендов и мануалю по необходимости. Но вдруг я очутился в новой реальности, где нужно “обязательно” знать про LLM, с ними работать и желательно уметь тестировать.

На проекте у меня AI не было, и было неясно, появится ли он вообще. А разбираться хотелось, чтобы владеть актуальными навыками.

Только с чего начать?

Токены, эмбеддинги, галлюцинации, RAG, агенты — знакомые слова, не более. Готовых гайдов или роадмапов о том, как и что учить нубу, я не нашёл. Решил изучать самостоятельно и с помощью ChatGPT, конечно. Было бы странно не спросить про LLM у LLM.
Через время разобрался с базой, необходимой для работы с LLM. И решил поделиться с вами. Возможно, кому-то тоже мой опыт будет полезен.

В мой стартерпак вошли три обширные темы:
- как работают LLM;
- как применять AI в работе QA;
- как тестировать AI-продукты.

Ниже привожу источники, которые помогли в этом.

Тема 1. Как работают LLM

ИИ для самых маленьких: как работает LLM и ИИ-агент —  Для себя назвал “золото нубов”. Та самая база в одном месте. С таймкодами и понятными примерами. Легко закрывает большинство вопросов начинающего.

Ключевые понятия LLM — простыми и понятными словами об LLM

3Blue1Brown — How might LLMs store facts? — перевод в дубляже от легендарного 3Blue1Brown

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

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

Тема 2. Как применять AI в работе QA

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

Anthropic Prompt Library — набор готовых инженерных промптов.

Тема 3. Как тестировать AI-продукты

Как тестировать AI-приложения — базовый курс, чтобы познакомиться с тем, как тестировать AI-приложения.

Как ухватить LLM за хвост: эффективные стратегии тестирования AI-моделей — про то, как тестировать LLM-приложения не только руками, а через автоматические проверки, метрики и кастомные оценки.

Тестирование LLM-приложений с DeepEval — практическое руководство по работе с современным инструментом тестирования LLM.

В итоге

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

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

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

Кстати, интересно, кто из вас уже использует LLM в работе? С чем работаете? И как начинали изучать AI? Ведь если AI нет на проекте, как у меня, изучение превращается в отдельный квест.

Что на самом деле происходит с профессией

Раз в несколько месяцев я вижу одни и те же обсуждения:
«Manual QA больше не нужны»,
«Рынок перегрет»,
«Всё автоматизируют и заменят».

Если коротко — нет, QA никуда не исчезает.
Но профессия действительно сильно меняется. И тем, кто работает в тестировании, важно понимать в какую сторону.

И ВАЖНО: Эта статья — не про обесценивание ручного тестирования. Оно по-прежнему необходимо в ряде проектов. Речь о том, как трансформируется рынок и какие навыки становятся критичными.

Как всё было

Когда я начинал в QA почти шесть лет назад, во многих компаниях было так: несколько ручных тестировщиков на проект, огромные регрессии, Excel или TestRail, автотесты — где‑то в теории или только зараждались.

Автоматизация существовала, но далеко не везде. Обычно один‑два человека писали тесты «где‑то отдельно», инфраструктура настраивалась сложно, тесты работали нестабильно, при этом съедала время поддержка.

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

Поэтому годами основной силой оставались Manual QA.

Что изменилось

Изменения шли постепенно, но сейчас их уже невозможно игнорировать.

Инструменты стали проще

Фреймворки стали стабильнее. Настройка окружения — быстрее. Отладка — тоже удобнее. Скриншоты, видео, трассировка — есть из коробки.

Автоматизация перестала быть «магией». Она стала рабочим инструментом, который действительно экономит ресурсы и применяется в большинстве крупных компаний.

Плюс к этому — рост AI‑инструментов. Сегодня генерация шаблонов тестов, рефакторинг, анализ логики стали быстрее. Входной барьер снизился.

Архитектура изменилась

Микросервисы, контейнеризация, CI/CD.
Монолитов становится меньше, распределённых систем — больше.

Когда продукт состоит из десятков сервисов, тестировать его полностью руками уже невозможно.
Нужны изоляционные, интеграционные, атомарные автотесты.

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

Новая роль QA

Тестирование со сдвигом влево стало базой.
Тесты пишутся вместе с кодом или даже раньше.

Роль SDET стала понятней и встречается чаще — теперь это всегда специалист, который не просто пишет тесты, а строит инфраструктуру тестирования. А раньше — был «кто‑то там непонятный)»

Модель «чистых Manual QA» постепенно уходит.
Всё чаще востребованы гибридные роли:
Часть ручной работы, часть автоматизации, понимание процессов разработки — в общем, Fullstack`и

Если открыть вакансии, картина очевидна: предложений для AQA и SDET больше, чем для чистого Manual.

Почему это происходит

Причины, если знать особенности современного IT, очевидны:

• релизы стали чаще;

• конкуренция выше;

• стоимость ошибок выросла;

• бизнесу нужна скорость.

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

Значит ли это, что Manual QA исчезнут?

Нет.

Ручное тестирование остаётся важным там, где автоматизация нецелесообразна или слишком дорога.

UX-оценка, исследовательское тестирование, сложные нестандартные сценарии — всё это требует человека.

Но рынок чётко показывает:
Оставаться только в ручном тестировании становится всё сложнее.

Что с этим делать

IT — это движущийся эскалатор. Если стоять на месте, постепенно спускаешься вниз.

Для QA это означает:

• осваивать автоматизацию, даже на базовом уровне;

• понимать CI/CD;

• разбираться в API и микросервисах;

• интересоваться нагрузочным тестированием;

• развивать системное мышление.

Не обязательно сразу становиться SDET. Но игнорировать автоматизацию уже нельзя. Так же, как и ИИ.

Это вызов или возможность?

К текущей ситуации можно привести аналогию из прошлого — когда IDE для написания кода только появлялись, многие тоже не хотели на них переходить и планировали писать код до конца жизни в vim, тем самым пытаясь сопротивляться прогрессу. Но, как показывает практика, такой подход оказался не самым эффективным и сейчас 95%+ разработчиков пишут код в IDE.

Можно конечно воспринимать изменения как угрозу.
Но лучше — как точку роста.

Бессмысленно сопротивляться прогрессу. Нужно адаптироваться!

Чтобы резюмировать: QA не исчезает полностью. Он меняется, как и всё в современном мире. И за тобой выбор, следовать тренду или оставаться на месте.

Спасибо за уделенное внимание! В своём Telegram-блоге делюсь мыслями и практическим опытом на тему тестирования, автоматизации и в целом рынка IT. Всегда рад новым читателям🤝

Самсунг Гэлэкси J4, Андро9 - тот же сканер

+1,2,4,5,6,7,8

-3,

Лучший сканер КУАР-кодов однозначно!