InfoGrab DocsInfoGrab Docs

피처 플래그를 사용한 테스트

요약

특정 테스트를 피처 플래그가 활성화된 상태로 실행하려면 QA::Runtime::Feature 클래스를 사용하여 피처 플래그를 활성화하거나 비활성화할 수 있습니다(API를 통해). 피처 플래그를 변경하려면 관리자 인가가 필요합니다.

특정 테스트를 피처 플래그가 활성화된 상태로 실행하려면 QA::Runtime::Feature 클래스를 사용하여 피처 플래그를 활성화하거나 비활성화할 수 있습니다(API를 통해).

피처 플래그를 변경하려면 관리자 인가가 필요합니다. QA::Runtime::Feature는 GITLAB_QA_ADMIN_ACCESS_TOKEN을 통해 적절한 액세스 토큰을 제공하면(권장), 또는 GITLAB_ADMIN_USERNAME과 GITLAB_ADMIN_PASSWORD를 제공하면 자동으로 관리자로 인증합니다.

feature_flag RSpec 태그#

적절한 환경에서 테스트를 건너뛸 수 있도록 반드시 feature_flag 태그를 포함하세요.

필수 메타데이터:

name

  • 형식: feature_flag: { name: 'feature_flag_name' }

  • 정보 제공 목적으로 사용됩니다. 테스트 대상 피처 플래그를 확인하기 위해 반드시 포함해야 합니다.

선택적 메타데이터:

scope

  • 형식: feature_flag: { name: 'feature_flag_name', scope: :project }

  • scope가 :global로 설정되면, 모든 라이브 .com 환경에서 테스트가 건너뜁니다. 이는 해당 환경의 다른 테스트나 사용자에게 영향을 미치는 피처 플래그 변경 문제를 방지하기 위함입니다.

  • scope가 다른 값(:project, :group, :user 등)으로 설정되거나 scope가 지정되지 않으면, 카나리, 프로덕션, 사전 프로덕션 환경에서만 건너뜁니다. 이는 해당 환경에서 관리자 액세스를 사용할 수 없기 때문입니다.

    피처 플래그를 그룹, 프로젝트, 사용자 범위에서만 활성화하거나, 피처 그룹 범위에서 활성화하는 방법을 먼저 시도하도록 강력히 권장합니다.

  • 글로벌 피처 플래그를 반드시 사용해야 한다면, feature_flag 메타데이터에 scope: :global을 적용하도록 강력히 권장합니다. 다만, 이는 SET(Software Engineer in Test)의 재량에 따라 위험 수준을 결정하도록 남겨져 있습니다.

예를 들어, 테스트가 애플리케이션의 일부 영역에만 영향을 미치는 글로벌 피처 플래그를 사용하고 라이브 환경의 중요한 이슈를 확인하는 데도 필요한 경우가 있습니다. 이런 시나리오에서는 테스트 실행을 건너뛰는 것이 더 위험할 수 있습니다. 이러한 경우 scope를 메타데이터에서 생략하여 관리자 액세스가 있는 스테이징 같은 라이브 환경에서도 실행될 수 있도록 할 수 있습니다.

requires_admin에 대한 참고 사항: 피처 플래그 업데이트와 무관하게 테스트 내에서 관리자 액세스가 필요한 다른 작업(예: API를 통한 사용자 생성)이 있다면 이 태그를 여전히 적용해야 합니다.

아래 코드는 테스트에서 생성된 프로젝트에 대해 :feature_flag_name이라는 피처 플래그를 활성화합니다:

RSpec.describe "with feature flag enabled", feature_flag: {
  name: 'feature_flag_name',
  scope: :project
  } do

  let(:project) { Resource::Project.fabricate_via_api! }

  before do
    Runtime::Feature.enable(:feature_flag_name, project: project)
  end

  it "feature flag test" do
    # Execute the test with the feature flag enabled.
    # It will only affect the project created in this test.
  end
end

enable 메서드는 먼저 플래그를 설정한 다음 업데이트된 값이 API에 의해 반환되는지 확인합니다.

마찬가지로, 그룹, 사용자 또는 피처 그룹에 대해 기능을 활성화할 수 있습니다:

group = Resource::Group.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, group: group)

user = Resource::User.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, user: user)

feature_group = "a_feature_group"
Runtime::Feature.enable(:feature_flag_name, feature_group: feature_group)

범위가 지정되지 않으면 피처 플래그는 인스턴스 전체에 설정되며 테스트 실행 후에도 유지됩니다:

# This will affect all users! Use with care!
Runtime::Feature.enable(:feature_flag_name)

셀렉터 다루기#

새로운 기능은 종종 vue 컴포넌트나 haml 파일을 새로운 것으로 대체합니다. 대부분의 경우 새 파일이나 컴포넌트는 피처 플래그로만 접근할 수 있습니다. 이 방식은 테스트가 피처 플래그 활성화 여부에 관계없이 통과해야 할 때 문제가 됩니다. 두 시나리오 모두에서 테스트가 통과하도록 하려면:

  • 새 컴포넌트나 파일 내에 또 다른 셀렉터를 생성합니다.

  • 이전 셀렉터와 동일한 이름을 부여합니다.

셀렉터는 페이지 오브젝트의 특정 프론트엔드 파일에 연결되어 있으며, qa:selectors 테스트 내에서 가용성이 확인됩니다. 해당 셀렉터가 프론트엔드 파일 내에 없으면 테스트가 실패합니다. 피처 플래그가 활성화되거나 비활성화될 때 셀렉터를 사용할 수 있도록, 새 셀렉터를 페이지 오브젝트에 추가하고 기존 셀렉터는 그대로 둡니다. 테스트는 올바른 셀렉터를 사용하며 누락된 셀렉터를 계속 감지합니다.

새로운 기능이 이미 셀렉터가 있는 기존 프론트엔드 파일을 변경하는 경우, 같은 이름으로 새 셀렉터를 추가할 수 있습니다. 단, 셀렉터 중 하나만 페이지에 표시됩니다. 다음과 같이 해야 합니다:

  • 피처 플래그로 다른 셀렉터를 비활성화합니다.

  • 피처 플래그가 제거될 때 프론트엔드 파일과 페이지 오브젝트 파일에서 이전 셀렉터를 삭제하도록 프론트엔드 파일에 주석을 추가합니다.

변경 전 예시#

# This is the link to the old file
view 'app/views/devise/passwords/edit.html.haml' do
  # The new selector should have the same name
  element 'password-field'
  ...
end

변경 후 예시#

view 'app/views/devise/passwords/edit.html.haml' do
  element 'password-field'
  ...
end

# Now it can verify the selector is available
view 'app/views/devise/passwords/new_edit_behind_ff.html.haml' do
  # The selector has the same name
  element 'password-field'
end

리소스 클래스 다루기#

리소스 클래스가 피처 플래그가 활성화될 때 다르게 동작해야 한다면, 클래스 내에 피처 플래그 이름으로 변수를 토글합니다. 이 변수와 조건을 통해 모든 동작이 적절하게 처리됩니다.

이 변수는 fabricate_via_api 호출 내에서 설정할 수 있습니다. 일관된 접근을 위해:

  • 비활성화 확인이 아닌 activated 확인을 사용합니다.

  • 변수 이름 끝에 activated라는 단어를 추가합니다.

  • initialize 메서드 내에서 변수의 기본값을 설정합니다.

예를 들어:

def initialize
  name_of_the_feature_flag_activated = false
  ...
end

정리#

피처 플래그가 제거된 후, 리소스 클래스를 정리하고 변수를 삭제합니다. 모든 메서드는 이제 기본 상태가 된 조건 절차를 사용해야 합니다.

캐싱으로 인한 불안정성 관리#

모든 애플리케이션 설정과 피처 플래그는 GitLab 내에서 1분 동안 캐시됩니다. 모든 캐싱은 정적 환경을 제외한 테스트 중에는 비활성화됩니다.

테스트가 피처 플래그를 변경하면, 피처 플래그가 활성화된 경우에만 요소가 표시되는 경우 불안정한 동작이 발생할 수 있습니다. 이 동작을 방지하려면 피처 플래그 뒤에 있는 요소에 대한 대기를 추가하세요.

피처 플래그가 활성화된 상태로 시나리오 실행#

기존 테스트를 편집하거나 새 테스트를 작성하지 않고도 피처 플래그가 활성화된 전체 시나리오를 실행할 수도 있습니다.

자세한 내용은 QA README를 참조하세요.

피처 플래그가 활성화된 상태에서 엔드투엔드 테스트 통과 확인#

엔드투엔드 테스트는 Staging 또는 GitLab.com에서 활성화되기 전에 피처 플래그가 활성화된 상태로 통과해야 합니다. 업데이트가 필요한 테스트는 쿼드 플래닝의 일부로 식별되어야 합니다. 관련 담당 Software Engineer in Test는 테스트를 업데이트하거나 다른 엔지니어가 할 수 있도록 지원할 책임이 있습니다. 그러나 변경이 쿼드 플래닝을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 인해 배포가 차단될 수 있습니다.

피처 플래그 정의 변경 시 자동 테스트 실행#

엔드투엔드 테스트가 통과하는지 확인하는 두 가지 방법이 있습니다:

  • 머지 리퀘스트가 피처 플래그 정의 파일을 추가하거나 편집하면, 두 개의 e2e:test-on-gdk job(gdk-instance 및 gdk-instance-ff-inverse)이 머지 리퀘스트 파이프라인에 자동으로 포함됩니다. 하나의 job은 기본 피처 플래그 상태로 애플리케이션을 실행하고 다른 하나는 반대 값으로 설정합니다. 이 job들은 동일한 테스트 스위트를 실행하여 피처 플래그가 활성화되거나 비활성화된 상태에서 모두 통과하는지 확인합니다.

  • 경우에 따라, 엔드투엔드 테스트 job이 자동으로 트리거되지 않았거나 기본 피처 플래그 값으로 테스트를 실행한 경우(원하는 값이 아닐 수 있음), 모든 E2E 테스트가 피처 플래그가 활성화되거나 비활성화된 상태에서 통과하는지 확인하기 위해 피처 플래그를 활성화하는 Draft MR을 생성할 수 있습니다.

피처 플래그가 활성화된 상태에서 엔드투엔드 테스트 실패 트러블슈팅#

피처 플래그를 활성화하면 E2E 테스트 실패가 발생하는 경우, 실패한 파이프라인의 아티팩트를 탐색하여 실패한 테스트의 스크린샷을 볼 수 있습니다. 그 후 다음 중 하나를 수행할 수 있습니다:

  • 업데이트가 필요한 테스트를 식별하고 해당 테스트를 업데이트하거나 다른 엔지니어가 할 수 있도록 지원할 책임이 있는 관련 담당 Software Engineer in Test에 연락합니다. 그러나 변경이 쿼드 플래닝을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 인해 배포가 차단될 수 있습니다.

  • 피처 플래그가 활성화된 상태로 실패한 테스트를 로컬에서 실행합니다. 이 옵션은 상당한 설정이 필요하지만, 실패한 테스트가 실행되는 동안 브라우저가 수행하는 작업을 볼 수 있어 문제를 더 빠르게 디버그하는 데 도움이 됩니다. 또한 일반적인 차단 요인에 대한 지원을 위해 E2E 테스트 트러블슈팅 가이드를 참조할 수 있습니다.

기능 개발 중 테스트 실행#

엔드투엔드 테스트가 피처 플래그를 활성화하는 경우, 머지 리퀘스트 파이프라인에서 e2e:test-on-omnibus-ee job을 실행하여 머지 리퀘스트의 변경 사항을 테스트하는 데 엔드투엔드 테스트 스위트를 사용할 수 있습니다. 피처 플래그와 관련 변경 사항이 이미 병합된 경우, 기본 브랜치에서 테스트가 통과하는지 확인할 수 있습니다. 엔드투엔드 테스트는 기본 브랜치에서 2시간마다 실행되며, 결과는 testcase-sessions 프로젝트에서 사용 가능한 Test Session Report에 게시됩니다.

관련 테스트가 자체적으로 피처 플래그를 활성화하지 않는 경우, 피처 플래그 정의 파일을 통해 기본적으로 플래그를 활성화하는 Draft 머지 리퀘스트를 열어 테스트 업데이트가 필요한지 확인할 수 있습니다. 이렇게 하면 자동으로 엔드투엔드 테스트 스위트가 실행됩니다. 테스트가 통과하면 머지 리퀘스트를 닫을 수 있습니다. 테스트 업데이트에 도움이 필요하다면 Quality 부서의 안정적인 담당자에게 연락하거나, 해당 그룹의 안정적인 담당자가 없는 경우 Software Engineer in Test 누구에게나 연락하세요.

피처 플래그를 사용한 테스트

GitLab v19.1
원문 보기
요약

특정 테스트를 피처 플래그가 활성화된 상태로 실행하려면 QA::Runtime::Feature 클래스를 사용하여 피처 플래그를 활성화하거나 비활성화할 수 있습니다(API를 통해). 피처 플래그를 변경하려면 관리자 인가가 필요합니다.

특정 테스트를 피처 플래그가 활성화된 상태로 실행하려면 QA::Runtime::Feature 클래스를 사용하여 피처 플래그를 활성화하거나 비활성화할 수 있습니다(API를 통해).

피처 플래그를 변경하려면 관리자 인가가 필요합니다. QA::Runtime::Feature는 GITLAB_QA_ADMIN_ACCESS_TOKEN을 통해 적절한 액세스 토큰을 제공하면(권장), 또는 GITLAB_ADMIN_USERNAME과 GITLAB_ADMIN_PASSWORD를 제공하면 자동으로 관리자로 인증합니다.

feature_flag RSpec 태그#

적절한 환경에서 테스트를 건너뛸 수 있도록 반드시 feature_flag 태그를 포함하세요.

필수 메타데이터:

name

  • 형식: feature_flag: { name: 'feature_flag_name' }

  • 정보 제공 목적으로 사용됩니다. 테스트 대상 피처 플래그를 확인하기 위해 반드시 포함해야 합니다.

선택적 메타데이터:

scope

  • 형식: feature_flag: { name: 'feature_flag_name', scope: :project }

  • scope가 :global로 설정되면, 모든 라이브 .com 환경에서 테스트가 건너뜁니다. 이는 해당 환경의 다른 테스트나 사용자에게 영향을 미치는 피처 플래그 변경 문제를 방지하기 위함입니다.

  • scope가 다른 값(:project, :group, :user 등)으로 설정되거나 scope가 지정되지 않으면, 카나리, 프로덕션, 사전 프로덕션 환경에서만 건너뜁니다. 이는 해당 환경에서 관리자 액세스를 사용할 수 없기 때문입니다.

    피처 플래그를 그룹, 프로젝트, 사용자 범위에서만 활성화하거나, 피처 그룹 범위에서 활성화하는 방법을 먼저 시도하도록 강력히 권장합니다.

  • 글로벌 피처 플래그를 반드시 사용해야 한다면, feature_flag 메타데이터에 scope: :global을 적용하도록 강력히 권장합니다. 다만, 이는 SET(Software Engineer in Test)의 재량에 따라 위험 수준을 결정하도록 남겨져 있습니다.

예를 들어, 테스트가 애플리케이션의 일부 영역에만 영향을 미치는 글로벌 피처 플래그를 사용하고 라이브 환경의 중요한 이슈를 확인하는 데도 필요한 경우가 있습니다. 이런 시나리오에서는 테스트 실행을 건너뛰는 것이 더 위험할 수 있습니다. 이러한 경우 scope를 메타데이터에서 생략하여 관리자 액세스가 있는 스테이징 같은 라이브 환경에서도 실행될 수 있도록 할 수 있습니다.

requires_admin에 대한 참고 사항: 피처 플래그 업데이트와 무관하게 테스트 내에서 관리자 액세스가 필요한 다른 작업(예: API를 통한 사용자 생성)이 있다면 이 태그를 여전히 적용해야 합니다.

아래 코드는 테스트에서 생성된 프로젝트에 대해 :feature_flag_name이라는 피처 플래그를 활성화합니다:

RSpec.describe "with feature flag enabled", feature_flag: {
  name: 'feature_flag_name',
  scope: :project
  } do

  let(:project) { Resource::Project.fabricate_via_api! }

  before do
    Runtime::Feature.enable(:feature_flag_name, project: project)
  end

  it "feature flag test" do
    # Execute the test with the feature flag enabled.
    # It will only affect the project created in this test.
  end
end

enable 메서드는 먼저 플래그를 설정한 다음 업데이트된 값이 API에 의해 반환되는지 확인합니다.

마찬가지로, 그룹, 사용자 또는 피처 그룹에 대해 기능을 활성화할 수 있습니다:

group = Resource::Group.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, group: group)

user = Resource::User.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, user: user)

feature_group = "a_feature_group"
Runtime::Feature.enable(:feature_flag_name, feature_group: feature_group)

범위가 지정되지 않으면 피처 플래그는 인스턴스 전체에 설정되며 테스트 실행 후에도 유지됩니다:

# This will affect all users! Use with care!
Runtime::Feature.enable(:feature_flag_name)

셀렉터 다루기#

새로운 기능은 종종 vue 컴포넌트나 haml 파일을 새로운 것으로 대체합니다. 대부분의 경우 새 파일이나 컴포넌트는 피처 플래그로만 접근할 수 있습니다. 이 방식은 테스트가 피처 플래그 활성화 여부에 관계없이 통과해야 할 때 문제가 됩니다. 두 시나리오 모두에서 테스트가 통과하도록 하려면:

  • 새 컴포넌트나 파일 내에 또 다른 셀렉터를 생성합니다.

  • 이전 셀렉터와 동일한 이름을 부여합니다.

셀렉터는 페이지 오브젝트의 특정 프론트엔드 파일에 연결되어 있으며, qa:selectors 테스트 내에서 가용성이 확인됩니다. 해당 셀렉터가 프론트엔드 파일 내에 없으면 테스트가 실패합니다. 피처 플래그가 활성화되거나 비활성화될 때 셀렉터를 사용할 수 있도록, 새 셀렉터를 페이지 오브젝트에 추가하고 기존 셀렉터는 그대로 둡니다. 테스트는 올바른 셀렉터를 사용하며 누락된 셀렉터를 계속 감지합니다.

새로운 기능이 이미 셀렉터가 있는 기존 프론트엔드 파일을 변경하는 경우, 같은 이름으로 새 셀렉터를 추가할 수 있습니다. 단, 셀렉터 중 하나만 페이지에 표시됩니다. 다음과 같이 해야 합니다:

  • 피처 플래그로 다른 셀렉터를 비활성화합니다.

  • 피처 플래그가 제거될 때 프론트엔드 파일과 페이지 오브젝트 파일에서 이전 셀렉터를 삭제하도록 프론트엔드 파일에 주석을 추가합니다.

변경 전 예시#

# This is the link to the old file
view 'app/views/devise/passwords/edit.html.haml' do
  # The new selector should have the same name
  element 'password-field'
  ...
end

변경 후 예시#

view 'app/views/devise/passwords/edit.html.haml' do
  element 'password-field'
  ...
end

# Now it can verify the selector is available
view 'app/views/devise/passwords/new_edit_behind_ff.html.haml' do
  # The selector has the same name
  element 'password-field'
end

리소스 클래스 다루기#

리소스 클래스가 피처 플래그가 활성화될 때 다르게 동작해야 한다면, 클래스 내에 피처 플래그 이름으로 변수를 토글합니다. 이 변수와 조건을 통해 모든 동작이 적절하게 처리됩니다.

이 변수는 fabricate_via_api 호출 내에서 설정할 수 있습니다. 일관된 접근을 위해:

  • 비활성화 확인이 아닌 activated 확인을 사용합니다.

  • 변수 이름 끝에 activated라는 단어를 추가합니다.

  • initialize 메서드 내에서 변수의 기본값을 설정합니다.

예를 들어:

def initialize
  name_of_the_feature_flag_activated = false
  ...
end

정리#

피처 플래그가 제거된 후, 리소스 클래스를 정리하고 변수를 삭제합니다. 모든 메서드는 이제 기본 상태가 된 조건 절차를 사용해야 합니다.

캐싱으로 인한 불안정성 관리#

모든 애플리케이션 설정과 피처 플래그는 GitLab 내에서 1분 동안 캐시됩니다. 모든 캐싱은 정적 환경을 제외한 테스트 중에는 비활성화됩니다.

테스트가 피처 플래그를 변경하면, 피처 플래그가 활성화된 경우에만 요소가 표시되는 경우 불안정한 동작이 발생할 수 있습니다. 이 동작을 방지하려면 피처 플래그 뒤에 있는 요소에 대한 대기를 추가하세요.

피처 플래그가 활성화된 상태로 시나리오 실행#

기존 테스트를 편집하거나 새 테스트를 작성하지 않고도 피처 플래그가 활성화된 전체 시나리오를 실행할 수도 있습니다.

자세한 내용은 QA README를 참조하세요.

피처 플래그가 활성화된 상태에서 엔드투엔드 테스트 통과 확인#

엔드투엔드 테스트는 Staging 또는 GitLab.com에서 활성화되기 전에 피처 플래그가 활성화된 상태로 통과해야 합니다. 업데이트가 필요한 테스트는 쿼드 플래닝의 일부로 식별되어야 합니다. 관련 담당 Software Engineer in Test는 테스트를 업데이트하거나 다른 엔지니어가 할 수 있도록 지원할 책임이 있습니다. 그러나 변경이 쿼드 플래닝을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 인해 배포가 차단될 수 있습니다.

피처 플래그 정의 변경 시 자동 테스트 실행#

엔드투엔드 테스트가 통과하는지 확인하는 두 가지 방법이 있습니다:

  • 머지 리퀘스트가 피처 플래그 정의 파일을 추가하거나 편집하면, 두 개의 e2e:test-on-gdk job(gdk-instance 및 gdk-instance-ff-inverse)이 머지 리퀘스트 파이프라인에 자동으로 포함됩니다. 하나의 job은 기본 피처 플래그 상태로 애플리케이션을 실행하고 다른 하나는 반대 값으로 설정합니다. 이 job들은 동일한 테스트 스위트를 실행하여 피처 플래그가 활성화되거나 비활성화된 상태에서 모두 통과하는지 확인합니다.

  • 경우에 따라, 엔드투엔드 테스트 job이 자동으로 트리거되지 않았거나 기본 피처 플래그 값으로 테스트를 실행한 경우(원하는 값이 아닐 수 있음), 모든 E2E 테스트가 피처 플래그가 활성화되거나 비활성화된 상태에서 통과하는지 확인하기 위해 피처 플래그를 활성화하는 Draft MR을 생성할 수 있습니다.

피처 플래그가 활성화된 상태에서 엔드투엔드 테스트 실패 트러블슈팅#

피처 플래그를 활성화하면 E2E 테스트 실패가 발생하는 경우, 실패한 파이프라인의 아티팩트를 탐색하여 실패한 테스트의 스크린샷을 볼 수 있습니다. 그 후 다음 중 하나를 수행할 수 있습니다:

  • 업데이트가 필요한 테스트를 식별하고 해당 테스트를 업데이트하거나 다른 엔지니어가 할 수 있도록 지원할 책임이 있는 관련 담당 Software Engineer in Test에 연락합니다. 그러나 변경이 쿼드 플래닝을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 인해 배포가 차단될 수 있습니다.

  • 피처 플래그가 활성화된 상태로 실패한 테스트를 로컬에서 실행합니다. 이 옵션은 상당한 설정이 필요하지만, 실패한 테스트가 실행되는 동안 브라우저가 수행하는 작업을 볼 수 있어 문제를 더 빠르게 디버그하는 데 도움이 됩니다. 또한 일반적인 차단 요인에 대한 지원을 위해 E2E 테스트 트러블슈팅 가이드를 참조할 수 있습니다.

기능 개발 중 테스트 실행#

엔드투엔드 테스트가 피처 플래그를 활성화하는 경우, 머지 리퀘스트 파이프라인에서 e2e:test-on-omnibus-ee job을 실행하여 머지 리퀘스트의 변경 사항을 테스트하는 데 엔드투엔드 테스트 스위트를 사용할 수 있습니다. 피처 플래그와 관련 변경 사항이 이미 병합된 경우, 기본 브랜치에서 테스트가 통과하는지 확인할 수 있습니다. 엔드투엔드 테스트는 기본 브랜치에서 2시간마다 실행되며, 결과는 testcase-sessions 프로젝트에서 사용 가능한 Test Session Report에 게시됩니다.

관련 테스트가 자체적으로 피처 플래그를 활성화하지 않는 경우, 피처 플래그 정의 파일을 통해 기본적으로 플래그를 활성화하는 Draft 머지 리퀘스트를 열어 테스트 업데이트가 필요한지 확인할 수 있습니다. 이렇게 하면 자동으로 엔드투엔드 테스트 스위트가 실행됩니다. 테스트가 통과하면 머지 리퀘스트를 닫을 수 있습니다. 테스트 업데이트에 도움이 필요하다면 Quality 부서의 안정적인 담당자에게 연락하거나, 해당 그룹의 안정적인 담당자가 없는 경우 Software Engineer in Test 누구에게나 연락하세요.