QA Сhannel

Последние пару лет вокруг LLM много разговоров про то, как они изменят работу тестировщиков.Чаще всего обсуждают генерацию тест-кейсов, автотестов или даже полную замену части QA-процессов. Но если посмотреть на работу большинства команд, основная проблема находится гораздо ближе к земле.Тестировщики по-прежнему тратят часы на вещи, которые сложно назвать инженерной работой: читать требования, переносить информацию между Jira, Confluence и TMS, собирать Postman-коллекции, оформлять тест-кейсы и искать пробелы в документации.Всё это требует экспертизы, но значительная часть времени уходит не на поиск дефектов, а на механическую работу.В статье как раз разбирается интересный кейс QA-инженера, который решил делегировать эту рутину LLM и собрал собственный инструмент для генерации тест-кейсов, API-тестов и ревью документации.Получился хороший пример того, как AI может не заменить тестировщика, а освободить его от самой скучной части работы.

Для тех, кто давно думал о переходе в AQA попался довольно подробный гайд на Хабре.Автор подробно расписал путь от Manual QA до AQA:✔️ выбор направления (UI, API, Mobile, Load);✔️ выбор языка программирования;✔️ рекомендуемый стек технологий;✔️ Git, Docker, Allure и CI/CD;✔️ создание портфолио;✔️ подготовка к поиску первой работы в автоматизации.Особенно полезно для тех, кто постоянно откладывает переход из-за вопроса: «С чего вообще начать?»🔗 https://habr.com/ru/articles/932374/Пишите в коментах какой стек вы бы сегодня выбрали для старта в автоматизации: Python, Java или TypeScript?

Git для QA без инфоцыганства, магии с бубном, смс и регистрации😎В статье на Хабре собран джентльменский набор Git для тестировщика:✔️ Как читать изменения через diff и быстрее локализовать баги✔️ Не ждать деплой ✔️ Ветки, merge и rebase без боли✔️ Лайфхаки: blame, stash, cherry-pick✔️ Как не испортить репутацию, коммитя в master (спойлер: лучше не надо)Если вы всё ещё думаете, что Git только pull/push, статья за 10 минут прокачает вас до уровня «можно спорить с лидом, но это не точно»🔗 https://habr.com/ru/articles/1040232/#QA #Git #Testing #Habr

Кажется, работодатели окончательно решили, что QA должен уметь всё: Тестировать. Автоматизировать. Писать код. Разбираться в архитектуре. Работать с метриками. Настраивать CI/CD. Использовать AI. И как уже стало привычно все это ещё вчера)Но как всегда есть нюансики.Нейроночки тестерам обещали освободить время, но во многих командах они превратились в ещё один обязательный навык в резюме. И вместо решения проблем и автоматизации процессов появляются бесконечные горы тест-кейсов, отчётов и прочих артефактов, которые в потоке рабочей информации редко кто читает, и все чаще нужен только зелёный статус и апрув, что всё «ОК».А можно использовать его иначе: убрать рутину, освободить время для инженерной работы, улучшить процессы и наконец заняться автоматизацией того, что действительно тормозит команду.Пока рынок требует от QA всё больше навыков ради навыков, сами тестировщики говорят о другом: перегрузках, хаосе в процессах, постоянном переключении контекста и нехватке времени на те самые улучшения, которых от них ждут.Что происходит с QA в 2026 году на самом деле? В статье результаты исследования среди 800+ инженеров.

Последнее время всё чаще появляются статьи и кейсы команд, которые потратили месяцы работы, время инженеров и немалые бюджеты на доказательство вещей, которые многим опытным специалистам были понятны с самого начала.Одна из самых популярных идей последних лет звучит примерно так:«Давайте заменим QA нейросетью!»Именно заменим, а не усилим существующие процессы или дадим инженерам более мощный инструмент.Звучит красиво. Почти как «давайте просто перепишем легаси» или «обнулим техдолг». На демках всё сходится: агент читает задачу, понимает бизнес-логику, пишет тесты, чинит упавший CI, открывает mergы и даже может что-нибудь поправить самостоятельно. QA вроде больше не нужен.Но затем происходит столкновение с жестокой реальностью.Оказывается, спецификации противоречат друг другу, бизнес-контекст не живёт в Jira, источников правды несколько, а самые дорогие ошибки возникают именно там, где нужно не генерировать код, а принимать решения и задавать неудобные вопросы, и в целом создавать "человеко идиотские" сценарии, которые регулярно происходят в реальной жизни.В статье как раз разбирается реальный эксперимент по созданию AI-QA, который должен был максимально автоматизировать работу тестировщиков. Получился хороший пример того, почему между «писать тесты» и «обеспечивать качество» до сих пор лежит пропасть.

Обучение без отрыва от работы: кейс РТЛабсМы же хотели обучающую модель, при которой получали бы опытных сотрудников, готовых выполнять задачи на наших инструментах сразу, без адаптации. В итоге создали корпоративную школу автоматизированного тестирования (далее — Школа АТ), которая уже третий год обучает AQA-инженеров на практических примерах и действующих в компании фреймворках.В компаниях часто стоит дилемма - учить сотрудников на внешних курсах или заниматься их обучением самостоятельно. Чем больше компания, тем превалирует внутреннее обучение. Так можно:- сэкономить часть бюджета- дать только те знания, которые нужны в их проектах- построить процесс передачи знаний от опытных коллегПро один из таких вариантов внутренней школы в сегодняшней статье.

Пострелизная валидация данных как новый вид тестирования?Этот вид тестирования показал свою эффективность в тех случаях, когда у вашего проекта есть следующие особенности:- это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сомнения), что их воспоминания о фактическом поведении “серой логики” верны - на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”- сам проект уже в production- при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

написал лонгрид-обзор того как ISO 25010 и 29119 рекомендует проектировать тестирование с учетом экономики:- обоснование, вводное- шаг 1 — выбор рисков- шаг 2 — категоризация и приоритезация рисков- шаг 3 — выбор способов тестирования- шаг 4 — оценка и перебалансировка портфолио- справочная таксономия способов тестирования

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

Как преобразовать огромный монорепозиторий с автотестами в микросервисыЕсли ваш репозиторий с автотестами сильно увеличился в размерах и процесс сборки начал занимать ощутимое время - в статье есть вариант как можно улучшить ситуацию. Мы решили, что будем разделяться на модули: один проект будет содержать много модулей с тестами. Чтобы такое провернуть, мы начали с анализа наших зависимостей, с рефакторинга нашего конфигурационного файла сборщика, или как мы его называем — build.gradle: вынесли в отдельные блоки именно те таски и зависимости этого сборщика, которые точно понадобятся всем модулям.Благодаря модулям мы получили ещё один серьезный бонус. Допустим, что через некоторое время мы хотим заменить наш старый HTTP-клиент на новый. Раньше это была бы мучительная задача по рефакторингу сотен тестов. Теперь же мы меняем зависимость и логику только в одном месте — в модуле-адаптере. Сами автотесты даже «не узнают», что что-то поменялось. Мы изолировали изменения!

Завтра тестирования: Как ИИ переопределяет профессию QA В докладе две части. Первая - обзор на ИИ-продукты в сфере тестирования, которые сейчас можно купить и использовать в России. Это и помощник для исправления падающих тестов в Playwright, и генератор тест-кейсов на основе технического задания. Во второй части рассказывается о применении ИИ на разных этапах разработки со стороны тестирования для улучшения конечного качества и ускорения процессов: прогнозная оценка задачи, ревью требований, анализ похожий инцидентов на основе логов.

История, в которой Винни-Пух и его друзья учатся решать проблемы по однойКаждое ретро превращается в длинный список проблем: команда обсуждает всё подряд, составляет планы — но через месяц список остаётся тем же. Проблемы не решаются, а участники устают от бесконечных разговоров без результата. Squad Health Check работает иначе: он помогает выявить одну самую «больную» точку и сфокусировать команду на её решении.История похожа на басню про лебедя, рака и щуку. Когда в товарищах согласья нет - на лад их дело не пойдет. Базовые, но важные вещи при оценке любых результатов работы:- Оценивать честно. Берем пример с ослика- Собирать данные анонимно, чтобы люди могли честно ответить- Фокусироваться на самом проблемном участке- Назначать ответственных за выполнение

Бенчмарки для теста телефона на производительностьЕсли вы занимаетесь мобильным тестированием — эта статья для вас. Вопрос о том, на каких устройствах тестировать каждое приложение, является одним из краеугольных камней процесса. Нужно проанализировать данные об устройствах и подобрать их исходя из вашей задачи. Ключевые характеристики для выбора могут зависеть от типа приложения: калькулятор калорий, сложное 3D-приложение или шутер.