Autosana

Autosana의 핵심은 동료에게 설명하듯 테스트를 쓰는 것이다. "로그인 버튼을 탭하고 테스트 이메일을 입력해"라고 적으면 에이전트가 단계를 스스로 구성한다. XPath도 CSS 선택자도 유지할 필요가 없다. 이것이 자동화를 깨뜨리는 가장 흔한 원인이었다. 리뉴얼 뒤 테스트 모음이 죽는 걸 본 팀에게 차이는 지시가 의도를 말한다는 점이다. 레이아웃의 특정 요소가 아니라.

UI가 바뀌면 에이전트는 곧바로 실패하는 대신 흐름을 적응시킨다. Autosana에 따르면 에이전트는 코드 diff를 바탕으로 테스트를 갱신하므로, 버튼이 옮겨지거나 화면 이름이 바뀌어도 스크립트를 손으로 고치는 일이 남지 않는다. 빠르게 움직이는 팀에 이 점은 무겁게 작용한다. CI 모음은 리뉴얼을 넘어 계속 돌고, 유지보수에 쓰는 시간도 줄어든다. 제품이 이 기능을 축으로 만들어졌고, 오래된 E2E 도구와 갈리는 지점이기도 하다.

Autosana는 모바일 앱과 웹사이트를 같은 플랫폼에서 다룬다. 흐름은 iOS, Android, 웹 브라우저에서 로컬로도, 설정이 필요 없는 클라우드 기기에서도 돌릴 수 있다. Flutter, React Native, Swift, Kotlin, React, Ionic 같은 주요 프레임워크를 지원한다. 여러 환경에 배포하는 팀에게 흐름을 한곳에서 쓰고 어디서든 확인한다는 건, 따로따로인 테스트 스택을 안고 가지 않아도 된다는 뜻이다.

실행은 모두 기록되고 게시되므로, 통과 또는 실패 한 줄을 믿는 대신 에이전트가 무엇을 했는지 직접 본다. 스크린샷이 각 단계를 표시해, 재현하지 않고도 실패를 진단하기 쉽다. CI에서 테스트가 깨졌는데 아무도 못 봤을 때, 앱이 깨진 건지 테스트가 깨진 건지 알려 주는 건 대개 이 리플레이다. 사소해 보이지만 오가는 일을 꽤 줄여 준다.

트리거로 흐름을 예약하거나 파이프라인에 넣고, 보고서를 풀 리퀘스트, 이메일, Slack으로 받는다. 변경이 들어온 순간, 나중에 누가 보는 대시보드가 아니라 필요한 사람 앞에 테스트가 놓인다. 이미 CI를 돌리는 팀에게 가치는 배포 전에 회귀를 잡는 데 있다. Autosana는 백엔드 호출로 테스트를 준비할 수 있다고도 언급하는데, 흐름이 스스로 데이터를 마련할 수 있다는 뜻이다.

버전 관리를 선호하는 팀은 흐름을 저장소 안의 파일로 두고 GitHub로 동기화할 수 있다. 테스트가 대상 코드 옆에 놓이고, 변경은 같은 리뷰 과정을 거친다. 테스트 정의를 다른 소스 파일처럼 추적하고 비교하려는 엔지니어링 조직에 맞고, 웹 대시보드에만 두지 않아도 된다.