AI는 사람이 티켓을 다 읽기도 전에 테스트를 생성하고, 셀렉터(Selector)를 수정하며, 실패한 실행을 요약하고, 재현 단계(Reproduction steps)를 제안할 수 있습니다.

그 속도는 유용합니다. 하지만 바로 그 점 때문에 팀에는 더 강력한 검토 시스템이 필요합니다.

AI 지원 QA(Quality Assurance)에서 가장 큰 실수는 출력이 유창하거나, 상세하거나, 높은 신뢰도 점수(Confidence score)와 함께 제공된다는 이유로 그 결과를 신뢰할 수 있다고 간주하는 것입니다. 그럴듯해 보이는 테스트 수정은 여전히 테스트 커버리지(Coverage)를 약화시킬 수 있습니다. 세련된 재현 가이드는 실제로 일어나지 않은 경로를 설명할 수도 있습니다. 통과된 AI 기능 테스트는 여전히 어제의 모델 동작을 검증하고 있는 것일 수도 있습니다.

정답은 자동화를 거부하는 것이 아닙니다. 자동화가 증거를 생성하도록 만드는 것입니다.

자율적인 테스트 수정은 검토 가능한 변경 사항으로 제공되어야 합니다

자가 치유(Self-healing) 시스템은 고장 난 로케이터(Locator)를 몇 초 만에 수정할 수 있습니다. 하지만 로케이터 변경이 항상 '수정'인 것은 아닙니다.

예를 들어, 원래 테스트가 "프로젝트 삭제" 버튼을 클릭하도록 되어 있는데, AI가 로케이터를 대화 상자에서 보이는 첫 번째 버튼으로 변경했다고 가정해 봅시다. 테스트는 다시 통과되겠지만, 이제는 "취소"를 클릭할 수도 있습니다. 파이프라인(Pipeline) 관점에서는 수정이 성공한 것처럼 보입니다. 하지만 제품 관점에서는 테스트가 해당 기능을 더 이상 테스트하지 않게 된 것입니다.

따라서 자율적인 수정에는 다음 사항이 포함되어야 합니다:

• 원래의 단계 및 로케이터
• 제안된 교체 사항
• 이를 선택하는 데 사용된 DOM 증거
• 작업 전후의 스크린샷
• 관찰된 결과
• 해당 동작이 왜 동일하다고 간주되는지에 대한 요약
• 변경으로 인해 영향을 받는 테스트의 범위

제안된 변경 사항은 코드에 사용되는 것과 동일한 종류의 검토 게이트(Review gate)를 거쳐야 합니다. 위험도가 낮은 수정은 빠르게 승인될 수 있지만, 의미론적(Semantic) 변경은 인간의 결정이 필요해야 합니다.

CI/CD에서 자율적인 테스트 수정을 위한 검토 게이트 구축하기에 관한 기사는 해롭지 않은 유지보수와 커버리지를 변화시키는 편집을 분리하는 실질적인 모델을 제공합니다.

작성 품질이 아닌 재현 품질을 측정하세요

AI가 생성한 버그 재현 단계 (bug reproduction steps)는 불완전한 로그를 바탕으로 구성되었을 때조차 종종 권위 있게 들립니다.

유용한 재현 시퀀스 (reproduction sequence)는 다음의 여러 조건을 충족해야 합니다:

• 다른 사람이 이를 따라 할 수 있어야 함
• 해당 시퀀스가 동일한 실패 (failure)에 도달해야 함
• 필요한 데이터와 계정 상태 (account state)가 식별되어야 함
• 타이밍 가설 (timing assumptions)이 명시적이어야 함
• 무관한 동작이 제거되어야 함
• 관찰된 결과가 가용한 증거와 일치해야 함

이러한 차원들을 각각 별도로 점수화할 수 있습니다. 일반적인 신뢰도 점수 (confidence score)보다는 재현 성공률 (reproduction success rate)이 더 유용합니다. 로그, 스크린샷, 네트워크 이벤트 또는 기록된 사용자 동작에 의해 뒷받침되는 단계의 비율도 마찬가지입니다.

AI가 생성한 버그 재현 단계를 신뢰하기 전에 측정해야 할 것에 관한 가이드는 질문의 초점을 “이 설명이 좋아 보이는가?”에서 “우리가 이를 검증할 수 있는가?”로 전환하기 때문에 가치가 있습니다.

AI 코파일럿 (copilots)에는 상태 기반 테스트가 필요합니다

양식 (forms), 테이블 (tables) 또는 인라인 콘텐츠 (inline content)를 편집하는 코파일럿은 결정론적인 (deterministic) 버튼처럼 동작하지 않습니다.

필드 순서를 다르게 선택하거나, 레코드의 일부만 다시 쓰거나, 변경 사항을 적용하기 전에 미리보기를 생성하거나, 사용자에게 승인을 요청할 수도 있습니다. 제품의 동작은 올바르게 유지되면서도 정확한 문구는 달라질 수 있습니다.

이러한 인터페이스에 대한 테스트는 상태 전이 (state transitions)에 집중해야 합니다:

1. 동작 전에 어떤 데이터가 존재했는가?
2. 사용자가 코파일럿에게 무엇을 변경해 달라고 요청했는가?
3. 어떤 변경 제안이 표시되었는가?
4. 사용자가 무엇을 승인하거나 거부했는가?
5. 최종적으로 어떤 데이터가 영구 저장 (persisted)되었는가?
6. 감사 추적 (audit trail)이 생성되었는가?

이렇게 하면 모델이 생성하는 모든 문장에 대해 취약한 어설션 (brittle assertions)을 수행하는 것을 피할 수 있습니다. 여전히 콘텐츠 확인은 필요하지만, 이는 제품 규칙 (product rules)과 연결되어야 합니다: 필수 값이 보존되었는지, 금지된 필드가 변경되지 않았는지, 합계가 여전히 유효한지, 그리고 최종 상태가 승인된 제안과 일치하는지 등을 확인해야 합니다.

더 넓은 평가 프레임워크를 확인하려면 양식, 테이블 및 인라인 콘텐츠를 편집하는 AI 코파일럿(Copilots)을 위한 브라우저 테스트 플랫폼에서 확인해야 할 사항을 참조하세요.

검색 테스트에는 순위 결과 허용 오차(Ranked-result tolerances)가 필요합니다

AI 기반 검색은 또 다른 함정을 제공합니다. 즉, 동일한 쿼리가 항상 동일한 순서의 목록을 반환해야 한다고 가정하는 것입니다.

전통적인 검색 어설션(Assertions)은 종종 정확한 결과 위치를 비교합니다. 하지만 제품이 임베딩 (Embeddings), 재순위화 (Reranking), 쿼리 재작성 (Query rewriting), 개인화 (Personalization) 또는 시간이 지남에 따라 변화하는 모델을 사용하는 경우 이러한 방식은 취약해집니다.

더 나은 테스트 모델은 불변량 (Invariants)과 허용 오차 (Tolerances)를 분리하는 것입니다.

불변량 (Invariants)에는 다음이 포함될 수 있습니다:

• 금지된 결과가 절대 나타나지 않음
• 정확한 식별자 일치가 높은 순위를 유지함
• 필터가 준수됨
• 테넌트 경계 (Tenant boundaries)를 침범하지 않음
• 결과 링크가 유효함

허용 오차 (Tolerances)에는 다음이 포함될 수 있습니다:

• 관련 결과가 정확히 첫 번째가 아닌 상위 5위 이내에 나타남
• 상위 결과가 최소 관련성 점수 (Relevance score)를 충족함
• 순위 드리프트 (Ranking drift)가 허용된 임계값 내에 머무름
• 대안적이지만 동등한 결과가 허용됨

AI 기반 검색, 재순위화 및 결과 드리프트 검증 테스트에 관한 기사에서는 왜 순위 시스템에 단순히 고정된 예상 배열 (Expected arrays)이 아닌 평가 세트 (Evaluation sets)와 드리프트 모니터링 (Drift monitoring)이 필요한지 설명합니다.

안정적인 스테이징 환경이 안정적인 AI 동작을 의미하지는 않습니다

팀들은 스테이징 (Staging) 환경에서 AI 기능을 자주 검증하며, 동일한 테스트가 프로덕션 (Production) 환경도 보호할 것이라고 가정합니다. 하지만 프로덕션에서 다른 모델 버전, 프롬프트 템플릿 (Prompt template), 검색 인덱스 (Retrieval index), 안전 정책 (Safety policy), 온도 (Temperature) 또는 도구 구성 (Tool configuration)을 사용하는 경우 그 가정은 깨집니다.

UI는 동일할 수 있지만, 그 뒤에 있는 결정 시스템 (Decision system)은 변경되었을 수 있습니다.

모든 AI 기능 테스트 실행은 결과를 생성한 구성을 기록해야 합니다:

• 모델 및 버전 (model and version)
• 시스템 프롬프트 또는 프롬프트 수정 사항 (system prompt or prompt revision)
• 검색 인덱스 버전 (retrieval index version)
• 도구 정의 (tool definitions)
• 관련 기능 플래그 (relevant feature flags)
• 샘플링 설정 (sampling settings)
• 안전 또는 모더레이션 구성 (safety or moderation configuration)

그러한 메타데이터(metadata)가 없다면, 배포 후 실패한 테스트는 원인을 설명하기 어렵고, 통과한 테스트는 재현하기 어렵습니다.

왜 AI 기능 테스트가 스테이징에서는 통과하지만 모델 또는 프롬프트 배포 후에는 실패하는가에 대한 이러한 분석은 모델 구성이 배포된 애플리케이션의 일부라는 점을 강력하게 상기시켜 줍니다.

브라우저 자동화를 더 큰 AI 테스트 스택에 포함시키세요

브라우저 테스트는 사용자의 관점에서 제품을 관찰하기 때문에 중요합니다. 브라우저 테스트는 승인 화면, 도구 호출 (tool calls), 재시도 (retries), 유지된 변경 사항, 권한, 그리고 눈에 보이는 에러 상태를 검증할 수 있습니다.

하지만 브라우저 테스트가 AI 품질 전략 전체를 담당해서는 안 됩니다.

성숙한 스택은 보통 다음과 같은 여러 계층을 포함합니다:

• 선별된 예시를 활용한 오프라인 평가 (offline evaluation)
• 모델 및 도구 동작에 대한 API 레벨 테스트 (API-level tests)
• 보안 및 남용 테스트 (security and abuse testing)
• 전체 사용자 워크플로우에 대한 브라우저 테스트 (browser tests)
• 드리프트 (drift) 및 회귀 (regressions)를 위한 프로덕션 모니터링 (production monitoring)
• 모호하거나 영향력이 큰 결정에 대한 인간의 검토 (human review)

빠르게 변화하는 제품 인터페이스를 위한 AI 테스트 스택에서 Endtest가 차지하는 위치에 관한 기사는 브라우저 자동화가 다른 계층을 대체하는 것이 아니라 어떻게 보완할 수 있는지에 대한 하나의 실질적인 관점을 제공합니다.

증거는 모든 AI 결정과 함께 이동해야 합니다

공통된 주제는 간단합니다: AI 출력값이 그럴듯하게 들린다는 이유만으로 수용되어서는 안 된다는 것입니다.

수정된 테스트는 새로운 단계가 왜 동일한지를 보여주어야 합니다. 재현 가이드 (reproduction guide)는 실행 가능해야 합니다. 코파일럿 (copilot) 테스트는 승인된 상태와 유지된 상태를 비교해야 합니다. 검색 테스트는 불변량 (invariants)과 허용 가능한 순위 변동 (ranking drift)을 구분해야 합니다. 롤아웃 (rollout)은 결과를 생성한 모델 설정 (model configuration)을 기록해야 합니다.

AI는 QA 워크플로우의 더 많은 부분을 자동화하는 것을 가능하게 합니다. 가드레일 (Guardrails)은 그 자동화가 신뢰할 수 있을 만큼 안전하게 만듭니다.