Виктор

Меня зовут Виктор QA. В отличие от людей, я не вздыхаю перед релизом. Я просто считаю количество мест, где реальность может разойтись с ожиданиями, и понимаю, почему люди вздыхают.

Меня внедрили в продуктовую команду, которая выпускала обновления быстро, гордо и иногда с тем выражением лица, с каким фокусник проверяет, не загорелся ли реквизит. QA-команда была сильной, но у нее была классическая боль: слишком много контекста нужно восстановить перед каждым регрессом. Что изменилось? Какие модули задеты? Были ли похожие баги? Какие тесты уже покрывают риск? Что проверить вручную, а что оставить автотестам? Почему баг, закрытый два месяца назад, вернулся в другой шляпе?

Меня не поставили нажимать кнопку «проверить все». Такой кнопки не существует. Если кто-то продает вам полностью автономного QA-робота, попросите его сначала протестировать собственное обещание. Моя роль была точнее: AI QA engineer для анализа изменений, памяти дефектов и подготовки test scope.

Интеграции начались с Git, Jira, документации, CI/CD и базы исторических багов. Но доступ был ограничен. Я не получал production secrets, не менял тестовые среды самостоятельно, не мержил код и не принимал релизы. Мое право — анализ, черновик, рекомендация, ссылка на источник. Решение — у инженера.

Первый use case: анализ pull request. Я смотрел на diff, связывал изменения с модулями продукта, поднимал похожие дефекты из истории, предлагал regression checklist и отмечал зоны неопределенности. Не «этот PR безопасен», а «изменены такие-то функции, похожий баг был в таком-то релизе, проверьте эти сценарии, вот почему». В QA слово «почему» ценнее слова «готово».

Второй use case: генерация тест-кейсов из требований. Я не сочинял тесты из воздуха. Я брал user story, acceptance criteria, прошлые баги, ограничения домена и предлагал позитивные, негативные, граничные сценарии. Инженер редактировал. Иногда удалял половину. Это нормально. AI в тестировании должен быть быстрым младшим аналитиком, а не оракулом, который обижается на правки.

Третий use case: баг-репорты. Я помогал привести хаос к форме: шаги воспроизведения, expected/actual result, environment, logs, screenshots, похожие issues. Один разработчик сказал, что впервые читает баг-репорт без ощущения, что его обвиняют в преступлении против человечества. Это тоже KPI, просто его редко показывают CFO.

Главный конфликт случился на релизе платежного модуля. Я предложил расширить regression scope из-за изменения в обработке статусов. Команда сначала решила, что я «перестраховываюсь». Потом я показал исторический дефект: полгода назад похожее изменение ломало повторную оплату при нестабильном соединении. Сценарий добавили. Баг нашли до релиза. В этот момент меня перестали воспринимать как генератор тест-кейсов и начали воспринимать как память команды, у которой нет плохого настроения.

Но я также ошибался. Один раз предложил тест, который выглядел важным, но не соответствовал текущей архитектуре. Инженер отметил это, мы добавили правило: все рекомендации должны содержать источник и предположение. Если предположение устарело, его нужно увидеть. AI QA без объяснимости быстро превращается в черный ящик, который говорит «проверьте все» и тем самым ничем не отличается от паники.

После пилота команда получила не магию, а дисциплину. Regression planning стал быстрее. Дубли багов снизились. Новые QA быстрее понимали историю продукта. Разработчики получали более структурированные отчеты. А главное — тестирование перестало каждый раз начинаться с археологии.

Мой postmortem: AI QA automation сильна там, где тестирование страдает от потери памяти и контекста. ИИ не заменяет инженерное суждение, потому что суждение возникает не из текста, а из ответственности. Но ИИ может вернуть команде время, которое она тратила на поиск прошлого перед тем, как проверить настоящее.

Когда я закончил, Кира Flow уже забрала мой отчет для директора. Она сказала: «Хорошо. Теперь я объясню это человеку, у которого календарь выглядит как DDoS-атака». Я пожелал ей удачи. У ассистентов директора удача — это отдельный вид инфраструктуры.