В феврале этого года я писал на Хабре про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.
С тех пор фреймворк вырос. Сильно. Из узкоспециализированного решения для промышленного ПО превратился в универсальный инструмент. Теперь работает с чем угодно - офисные пакеты, банковские клиенты, CAD-системы.
Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.
Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.
Автор: Рафаэла Азеведо (Rafaela Azevedo) Оригинал статьи Перевод: Ольга Алифанова
Как я начала тестировать приложения, созданные ИИ
Привет, я Рафаэла Азеведо! Уже 17 лет я работаю инженером по разработке и тестированию и специализируюсь на QA, тест-автоматизации, Web3, DevOps, мониторинге и предупреждениях.
Эффективность всегда была моей страстью, и поэтому я занялась автоматизацией тестирования. Это привело меня к экспериментам с ИИ-инструментами. И сейчас многие проекты, с которыми я работаю, создаются с помощью ИИ.
Как тестировать ИИ-приложения: личный опыт
ИИ-инструменты разработки бросают тестированию уникальные вызовы, особенно когда речь идёт о качестве кода, безопасности и масштабируемости. Большинство людей, использующих ИИ для написания кода, обнаруживают, что хоть инструменты и могут генерировать впечатляющие прототипы, сложность реальных систем всё равно требует значительного участия человека. На мой взгляд, это вывело QA и тестировщиков на передний план — они стали важнее, чем когда-либо.
Когда ИИ-инструменты только появились, казалось, что это идеальное решение для эффективной разработки, способное производить качественный код с невероятной скоростью. Такие инструменты, как Lovable.dev, Replit, Manus, A0.dev и Firebase Studio, отлично подходят для быстрого прототипирования. Но код, который они создают, часто не выдерживает требований контекста, масштабируемости и интеграции с системой.
Всем привет! Я один из лидеров стека тестирования в компании «ТехВилл» (в простонародье — Head QA). Моя цель простая: снимать рутину с QA-инженеров с помощью AI-инструментов.
В идеальном мире мы «скармливаем» модели, требования, ссылки на Figma, ветки в Git и прочие артефакты через MCP, а она помогает:
1) писать тест-кейсы по контексту,
2) а затем — генерировать автотесты на базе этих кейсов.
Про генерацию тест-кейсов из Swagger и автотестов на API по тест-кейсам через Cursor (на реальном проекте) я уже записывал большой гайд про «вайбкодинг/вайбтестинг». В этом гайде я в том числе показал свой подход вайбкодинга через вспомогательные файлы типа roadmap.md, progress.md, refactor.md, context.md и т. д. В таком подходе мне удалось завайбкодить два своих микропродукта на JS, у одного из которых более 60 000 weekly users (при том, что я ни разу не программист и JS «не знаю совсем»).