당신의 테스트 스위트가 버튼이 움직일 때마다 깨지거나, 다이브가 변경되거나, 또는 신들이 금지하면 A / B 테스트가 실행된다면, 그것은 정말로 무언가를 테스트합니까? 당신이 휴식을 취해야했다면, 당신의 팀 - 대부분의 엔지니어링 팀과 마찬가지로 - 스크립트 기반 테스트를 고치고 유지하는 데 너무 많은 시간을 보내고 있습니다. 다행스럽게도 작업 흐름에 AI가 있으면 릴리스주기가 끝나지 않으며 UI가 깨지지 않으며 모든 것이 괜찮습니다. 이 게시물에서 우리는 AI 테스트가 무엇인지 그리고 QA 에이전트가 모드 아래에서 어떻게 작동하는지 설명 할 것입니다 - 그래서 팀에 실제로 도움이되는지 여부를 결정할 수 있습니다. 전통적인 테스트 자동화는 무엇을 하는가 Playwright 또는 Selenium과 같은 테스트 자동화 도구는 단계별 지침을 따릅니다.이 URL로 이동하고 특정 CSS 선택자를 사용하여 요소를 찾고 클릭하고이 텍스트가 나타납니다.이 제품이 결코 변경되지 않는 한 모든 것이 잘 작동합니다. 그러나 그 이름의 무언가가 있다. 기본적으로 스크립트는 UI가 바뀌기 때문만이 아니라 지침이 멈추기 때문에 깨지지 않습니다.팀은 기존 테스트를 유지하는 데 30~40%의 개발 시간을 소비하고 실제 버그를 찾고 고치거나 새로운 기능을 구축하는 것보다 더 많은 시간을 보냅니다. 단지 좋은 테스트를 유지하기 위해 마찰을 증가시켰을 뿐입니다. selector treadmill AI code generation Cursor, Claude Code, Copilot과 같은 도구는 회사가 이전보다 빠르게 코드를 배송하는 데 도움이되지만 더 많은 출력은 또한 스프린트 당 더 많은 UI 변경, 더 많은 코드 재작용기, 더 많은 구성 요소가 재 작성됩니다. A에 따르면 자동화 플랫폼에서 적절한 QA 솔루션이없는 고성능 팀은 2주 사이클 내에 생산에 도달하는 스프린트 당 약 20 개의 버그를 경험했습니다.코드 볼륨이 계속 증가함에 따라이 수치는 징수적으로 증가하며 수동 테스트나 고전적인 테스트 자동화는 도달 할 수 없습니다. Forrester TEI 연구 불행한 현실은 전통적인 테스트 자동화가 물건이 안정적이면 좋은 투자 수익률 (ROI)을 제공한다는 것입니다 (같은 포레스터 연구는 이러한 플랫폼 중 하나에 대해 3 년 동안 209%의 ROI를보고합니다).그러나 이는 더 이상 존재하지 않는 AI 이전 수준의 개발 안정성을 가정합니다. 에이전트 테스트를 진행합니다. 에이전트 테스트란 무엇인가요? 간단히 말해서, 에이전트 테스트는 지정된 목표를 달성하는 AI에 초점을 맞추고 있습니다.You don't tell the tool 테스트 (이것을 클릭하십시오, 주장하십시오, 그 다음), 당신은 그것을 말합니다. 확인할 수 있습니다. how what 다음은 예제 문구입니다 : "사용자가 M-size hoodie를 바구니에 성공적으로 추가하고 GooglePay로 체크 아웃을 완료 할 수 있는지 확인하십시오." AI 에이전트는 그 목표를 실행하는 임무가 있습니다. 에이전트 테스트를 통해 QA 에이전트는 사용자로부터 목표를 수신한 다음 시스템 내에서 그 목표를 완료하는 방법을 파악합니다.It navigates across web, desktop, or mobile apps and interacts with elements.Then, it checks whether the goal was actually achieved. 반응 패턴 대부분의 에이전트 시스템, 우리가 구축 한 시스템을 포함하여 ReAct 패턴을 따르십시오: QA.테크 observe —> decide —> act —> evaluate 참고: QA 에이전트는 먼저 DOM 및 시각적 레이아웃 모두의 페이지의 현재 상태를 살펴본다. 결정 또는 생각: 그것은 목표에 대한 이유입니다. "나는 '카트에 추가'버튼을 찾아야합니다. 나는 카트 아이콘이있는 파란색 버튼을 볼 수 있습니다." 행동: 사용자가 하는 것처럼 행동합니다. 평가: 작업이 작동했는지 확인하고 다음에 무엇을해야하는지 결정합니다 (반복). 여기서 우리는 웹 앱의 구조적 및 시각적 계층을 이해하고 사용자가 취할 수있는 경로를 재구성하는 자율적인 시스템에 대해 이야기하고 있습니다. 메모리 레이어 단일 테스트를 실행하기 전에 애플리케이션에 대한 구조적 이해를 생성합니다.Our agents crawl your website or an app to map all the pages, flows, interactive elements, and relationships between elements into a knowledge graph. QA.테크 다시 한 번 우리의지도 비유를 사용하자. 도시를 걷는 관광객과 마음으로 모든 거리를 아는 현지인 사이의 차이에 대해 생각해보자. 둘 다 A에서 B로 갈 수 있지만 도시에 익숙하기 때문에 현지인은 짧은 길을 걷는 방법과 죽은 끝이 어디인지 알고 있습니다. 실제로 Agentic Testing가 작동하는 방법 단일 테스트를 작성하기 전에 에이전트는 앱을 스크롤합니다.QA.tech는 이것을 호출합니다. 기본적으로 에이전트가 앱을 독립적으로 탐색하여 사용자 흐름과 UI 요소를 지도하고 이해합니다. epistemic foraging 시도 당신은 "사용자가 성공적으로 검색, 탐색, 보기 및 부동산을 예약할 수 있는지 확인"와 같은 최종 목표가 무엇인지 에이전트에게 알려주는 간단하고 자연스러운 인스턴트를 작성합니다. 발견 이제 에이전트는 페이지와 요소의지도를 가지고 있으며, 홈 페이지, 브라우저 속성 기능, 예약 버튼, 그리고 인간 사용자가 원하는 방식으로 필요한 모든 옵션을 찾기 시작할 수 있습니다. 실행 Flow 에이전트는 단계별로 테스트 실행을 완료합니다 (녹음 세션을 통해 전체 과정을 볼 수 있습니다). 예상치 못한 제안과 같은 무언가가 예기치 않게 발생하면 에이전트는 그것을보고 그것이 목표에 대한 장애물임을 깨닫고 그것을 닫습니다. 주장 흐름이 완료되면 에이전트는 목표가 달성되었는지 여부에 따라 통과 또는 실패를 평가합니다. 이제, 이 결과를 동등한 Playwright 스크립트와 비교하십시오. , 특정 선택자를 사용하여 속성 검색 입력을 찾거나 , 위치를 입력하고, 검색을 시작하고, 결과 페이지가 로드될 때까지 기다리며, 재산 목록을 클릭한 다음 예약 버튼을 찾고 누르십시오. /home page data-testid CAPTCHA가 추가되거나 테스트 ID가 이름을 바꾸거나 예약 프로세스가 추가 페이지로 나누어지면 유지 보수 모드로 돌아갑니다. 에이전트 테스트 자동화가 AI 보조 테스트와 다르게 만드는 이유 솔직히, AI 테스트 자동화로 마케팅 된 도구의 무리는 실제로 Playwright와 같은 오래된 기술을위한 스크립트를 생성하는 포장기 일뿐입니다. 우리는 이런 식으로 에이전트 자동화를 사용하는 것은 단지 잘못된 패러다임에 AI를 사용하는 것이라고 생각합니다 – AI 포장기를 사용하는 결과는 독립적으로 행동하는 AI 에이전트와 비교할 때 더 나니다. 목표 지향 : 테스트는 구현 과정이 아닌 결과에 초점을 맞추고 있으며, 어떻게 거기에 도달할 수 있는지에 초점을 맞추고 있습니다. 인식: 에이전트는 실제 사용자가 보는 것과 마찬가지로 응용 프로그램을 볼 수 있습니다 (시각적으로 + HTML를 통해). 그것은 요소를 참조하기 위해 개인이 만든 선택기에 의존하지 않습니다. 적응성: 이것은 당신의 에이전트가 스스로 치유 할 수있는 능력입니다.당신이 위치를 움직이거나 "전송"버튼을 움직이거나 A / B 테스트로 추가 단계를 추가하면, 에이전트는 원본 요소가 움직이거나 경로가 바뀌더라도 목표를 완료하는 방법을 찾을 수 있습니다. 자기 평가: 에이전트 테스트에서 에이전트는 지정된 목표가 달성되었는지 여부에 따라 패스 또는 실패를 결정합니다.Tests remain aligned with user intent even as the code base evolves below. 지속적인 학습: 에이전트가 응용 프로그램과 더 많은 상호 작용을 할수록 행복한 경로 시나리오와 특정 사용자 인터페이스 구성 요소의 "정상적인" 작업 성능을 인식하는 것이 더 좋습니다. 에이전트 테스트가 (그리고 아니면) 올바른 적합한 경우 나는 당신이 내일 당신이 소유 한 Playwright에 대한 모든 단일 스크립트를 던져야한다고 생각하지 않는다. 이 접근법이 실제로 : strong fit End-to-end (E2E) 사용자 흐름 : 로그인, 체크 아웃, 계정을 관리하고 모든 CRUD 활동을 수행하는 것을 포함하는 모든 것; 레그레이션 스위트: 수동으로 테스트할 수 있는 것보다 빠르게 릴리스할 수 있는 UI를 지속적으로 변경합니다. 빠르게 움직이는 UI: 신규 릴리스를 적시에 검증합니다. 복잡한 제품 : 경험을 검증하는 가장 좋은 방법은 수동 테스트였지만 명백한 이유로 충분히 빨리 일어나지 않습니다. 그러나, 현재, 그것은 덜 이상적인 해결책입니다 : Webgl 게임이나 webgl 기반 UI는 또한 에이전트가 테스트하기 어렵습니다. Session-to-Session에서 매우 역동적 인 UI입니다. 현실은 우리가 이야기하는 대부분의 팀이 하이브리드 접근법을 사용한다는 것입니다.그들은 작은 세부 사항을 위해 스크립트에 의존하고 AI 에이전트가 광범위하고 복잡한 사용자 흐름을 처리하도록합니다. 즉, 우리는 에이전트 QA를 채택하는 회사가 3 개월의 환불과 함께 최대 529 %의 ROI를 얻는 것을 보았습니다. 포장하기 Up 에이전트 테스트는 전통적인 테스트 프레임 워크와 완전히 다른 접근 방식을 나타내며, 원하는 목표와 실제 결과 사이에 하나의 관계가 있습니다. 팀이 실제 버그를 찾는 것보다 테스트 인프라를 유지하는 데 더 많은 시간을 소비하는 경우, 에이전트 테스트 자동화는 그 격차를 닫는 데 도움이 될 수 있습니다. 더 깊이 가고 싶으십니까?여기에 몇 가지 유용한 자료가 있습니다 : 수동으로부터 자율적인 QA : 단계별 전환 가이드 QA 자동화가 가치가 있습니까? 똑똑한 테스트의 실제 ROI QA.tech를 사용하여 우리의 에이전트가 다음 릴리스에 대한 중요한 흐름을 어떻게 검증할 수 있는지 알아보십시오. 책과 데모
