UI가 바뀔 때마다 E2E 테스트가 실패하지 않게 하려면 어떻게 해야 하나요?

E2E 테스트는 클래스, id, 텍스트 일부 또는 위치로 요소를 찾기 때문에 UI가 바뀌면 실패합니다. 이런 속성들이 바로 디자인 개편으로 달라지는 부분이기 때문입니다. Verdict System LLC의 Nexus Studio는 세 단계로 이 문제를 처리합니다: 새 로케이터를 제안하고 테스트를 변경하기 전에 승인을 요청하며, 복구된 선택자 덕분에 성공한 실행은 정상 통과가 아닌 AUTO_RECOVER로 표시하고, 취약한 로케이터를 나열해 먼저 수정할 수 있게 합니다.

작성: Nexus Studio 팀, Verdict System LLC. 2026년 10월 7일.

UI가 바뀌면 Playwright와 Selenium 테스트가 실패하는 이유는 무엇인가요?

로케이터는 테스트가 요소를 찾는 데 사용하는 주소입니다. 이 주소가 빌드 시 생성되는 클래스, 페이지 내 위치, 레이블 문구처럼 요소의 기능과 무관한 속성에 의존하면, 페이지가 바뀔 때 주소가 잘못되어 애플리케이션은 여전히 정상 작동해도 테스트는 해당 줄에서 실패합니다.

문제는 한 번의 실패가 아닙니다. 릴리스할 때마다 팀이 실패한 실행 결과를 읽고, 문제가 생긴 줄을 찾고, 새 로케이터를 찾아 파일을 수정하는 데 반복해서 들이는 시간입니다.

테스트를 알리지 않고 수정하는 자동 복구에는 어떤 문제가 있나요?

도구가 아무에게도 알리지 않고 잘못된 로케이터를 교체하면 테스트 모음은 계속 통과하지만, 변경 사실도 숨겨집니다. 이제 테스트는 작성자가 선택하지 않은 대상을 클릭하며, 아무도 그 변경을 검토하지 않았습니다. 새로 일치한 대상이 잘못된 요소라면, 테스트는 엉뚱한 것을 검사하면서도 통과할 수 있습니다.

Nexus Studio는 정반대의 원칙으로 만들어졌습니다: 사용자 모르게 복구하는 일은 없습니다.

Nexus Studio는 잘못된 로케이터를 어떻게 복구하나요?

• 자동 복구가 기본 설정인 제안 모드로 켜져 있으면, 테스트가 실패할 때 Studio가 백그라운드 브라우저를 열어 실패한 줄까지 테스트를 재실행하고 페이지를 읽습니다. 실패 항목을 열면 후보가 이미 준비되어 있습니다. 이 과정에는 AI를 사용하지 않으며, 테스트는 실패 상태로 유지됩니다.
• 실패한 줄 옆 여백의 줄 복구 기능을 사용하면 해당 단계만 다시 기록하거나 선택자를 후보 중 하나로 교체할 수 있습니다. 후보는 안정성이 높은 순서로 정렬되며, XPath는 마지막에 표시됩니다.
• 변경 사항은 저장되지 않은 상태로 편집기에 반영됩니다. 저장하면 승인한 것으로 간주합니다.
• 어떤 후보를 선택할지 AI에게 물어볼 수도 있습니다. AI는 후보의 순서만 바꿀 수 있고 새 후보를 추가할 수는 없으며, 파일의 이전 버전은 해당 파일의 변경 기록에 남습니다.

복구된 선택자로 테스트가 통과했다는 것은 어떤 의미인가요?

판정은 AUTO_RECOVER입니다: 실행은 통과했지만, 자동 복구가 해당 테스트의 선택자를 교체해야 했다는 뜻입니다. 정상 통과인 SECURE로 보고되는 일은 없습니다. 작성자가 지정한 로케이터는 더 이상 작동하지 않으며, 다음번 페이지 변경 시에는 테스트 모음이 실제로 실패하게 되므로, 누군가 원래 선택자를 수정할 때까지 보고서와 실행 기록에 주의 사항이 계속 표시됩니다.

AUTO_RECOVER는 일곱 가지 통과 판정 중 하나이므로, CI 작업은 종료 코드 0을 반환합니다. 주의 사항은 빌드 실패가 아니라 보고서에 표시됩니다. 전체 검사 순서는 Nexus Studio가 14가지 테스트 판정을 내리는 방법에서 확인할 수 있습니다.

취약한 선택자가 작동하지 않게 되기 전에 어떻게 찾을 수 있나요?

• 로케이터 상태는 열려 있는 테스트의 취약한 로케이터와 각 로케이터가 있는 줄을 나열하며, 줄 복구와 동일한 대화 상자를 통해 복구할 수 있습니다.
• 선택자 맵은 AI 없이 페이지를 분석하고, 각 선택자를 HIGH, MEDIUM 또는 LOW로 평가하며, 맵을 로컬 디스크에 보관합니다.
• AI가 작성한 모든 테스트가 통과해야 하는 일곱 가지 검사인 Vet에는 테스트에 취약한 로케이터가 없어야 한다는 규칙이 포함되어 있습니다.

기록기는 어떤 로케이터를 선택하나요?

Nexus Recorder는 AI의 개입 없이 사용자가 클릭한 내용을 테스트 코드로 작성합니다. 테스트 id 속성을 사용할 수 있습니다: JavaScript 기록에서 data-testid를 선택하면 data-testid와 data-qa를 모두 읽습니다. Python과 Selenium 기록은 각 실행기의 속성 이름 하나를 유지합니다. 이러한 속성을 사용하는 선택자는 안정적인 것으로 평가되지만, 빌드 시 생성되는 클래스 이름, 깊게 중첩된 CSS 선택자, 태그 이름만 사용하는 선택자는 취약한 것으로 평가됩니다.

테스트는 표준 Playwright 또는 Selenium 파일로 유지되나요?

네. Studio가 작성하거나 가져오는 모든 테스트는 팀에 이미 익숙한 프레임워크 코드입니다: Playwright Test 파일(JavaScript, TypeScript, Python 또는 C#)이나 Selenium 파일(JavaScript, Python, Java 또는 C#)입니다. 복구는 해당 파일의 한 줄을 수정하는 방식이므로, Studio 사용을 중단하더라도 독점 형식에서 다른 형식으로 옮길 필요가 없습니다.

한계

• 제안 모드의 자동 복구는 스스로 아무것도 수정하지 않습니다. 여전히 사람이 각 복구를 승인해야 하므로, UI가 크게 바뀌면 검토에 시간이 걸립니다.
• 실패 후 자동으로 페이지를 읽으려면 기기에 여유 메모리가 필요합니다. 메모리가 부족하면 자동 읽기가 시작되지 않지만, 후보를 수동으로 요청할 수는 있습니다.
• 로케이터 상태는 파일을 한 줄씩 읽으므로, 여러 줄에 걸쳐 작성된 로케이터는 감지하지 못합니다.
• 취약하더라도 아직 작동하는 로케이터는 실패로 간주되지 않습니다. 로케이터 상태가 이를 알려주지만, 반드시 변경해야 하는 것은 아닙니다.

실제로 작동하는 모습은 어디에서 볼 수 있나요?

Studio 둘러보기에서는 Repair 줄과 요소 탐색자 상태를 화면으로 보여주고, 판정 안내서에서는 AUTO_RECOVER를 다른 13개 판정과 함께 설명하며, 30일 체험판에서는 동일한 엔진으로 직접 만든 테스트를 실행할 수 있습니다.