시니어 QA의 선언문: 자동화하지 않을 것을 어떻게 결정할까

Source: Dev.to

6년 넘게 QA를 해오면서, 높은 커버리지가 종종 허울뿐인 지표라는 것을 깨달았습니다. 제가 일했던 최고의 엔지니어링 팀 중 일부는 스크립트 수보다 파이프라인 속도를 우선시하기 때문에 UI 커버리지가 낮았습니다.

자동화는 “무료” 시간이 아닙니다—빌드가 끝나기를 기다려야 하는 개발자에게 매번 유지보수와 좌절이라는 비용을 지불하게 됩니다. 특히 플레이키한 셀렉터 때문에 빌드가 실패하면 말이죠. 플레이키한 테스트는 테스트가 전혀 없는 것보다 더 나쁩니다; 팀이 결국 무시하게 되는 잡음이 되기 때문입니다. CI에서 빨간 불을 신뢰하지 않게 되면 QA 프로세스는 사실상 죽은 것입니다.

자동화를 건너뛸 때

• Vibrating features – UI나 요구사항이 며칠마다 바뀐다면, 일회성 코드를 작성하는 겁니다. 나는 해당 기능이 주요 로직 변경 없이 최소 두 스프린트를 버텨볼 때까지 자동화를 하지 않습니다.
• Nightmare setups – 단 하나의 “Submit” 버튼을 테스트하려면 10개의 데이터베이스를 시드하고, 2단계 인증을 우회하며, 5개의 외부 API를 모킹해야 한다면 ROI가 없습니다. 나는 부서지기 쉬운 스크립트를 이틀간 디버깅하기보다 30 seconds 정도 수동으로 확인하는 데 시간을 씁니다.

테스트‑선택 전략

“자동화 필수” 목록

• 복잡한 계산 – 사람은 세금 로직, 통화 변환 등에서 오류를 범하기 쉽습니다. 기계는 수학에 지치지 않습니다.
• 스모크 테스트 – 앱이 시작되고 사용자가 로그인할 수 있음을 증명하는 “행복 경로”. 이는 파이프라인의 핵심입니다.
• 데이터 무결성 – 1단계에서 입력한 데이터가 실제로 10단계에서 데이터베이스에 나타나는지 확인합니다.

“손대지 말아야 할” 목록

• 시각적 “감각” – 스크립트는 버튼이 is_visible()인지 알려줄 수 있지만, 13인치 노트북 화면에서 겹치는 텍스트나 읽기 어려운 폰트를 감지하지는 못합니다.
• 한 번만 사용되는 기능 – 2주간 지속되는 시즌 프로모션은 3일간의 스크립팅을 정당화하지 않습니다.
• 모든 테스트를 브라우저를 통해 실행 – 이는 느리고 비용이 많이 들며 취약합니다. 예를 들어, 사용자의 프로필이 업데이트되었는지 확인하는 데 매번 전체 UI를 클릭할 필요는 없습니다.

UI‑heavy vs. balanced approach

// UI‑heavy (fragile)
test('user updates profile - the slow way', async ({ page }) => {
  await page.goto('/settings');
  await page.fill('#bio-input', 'New Bio');
  await page.click('.save-button-variant-2'); // This selector will break eventually
  await expect(page.locator('.success-toast')).toBeVisible();
});

// Balanced (faster and stable)

// 1. Check the logic via API (milliseconds)
test('profile update data integrity', async ({ request }) => {
  const response = await request.patch('/api/user/profile', {
    data: { bio: 'New Bio' }
  });
  expect(response.ok()).toBeTruthy();
});

// 2. Check the UI once (does the button work?)
test('save button triggers action', async ({ page }) => {
  await page.goto('/settings');
  await page.click('button:has-text("Save")');
  // No DB check needed; the API test already covered that.
});

전자상거래 체크아웃 예시

일반적인 체크아웃 흐름은 다음을 포함합니다:

1. 장바구니에 상품 추가.
2. 배송 주소 입력.
3. 신용카드 입력.
4. 주문 확인 검증.

UI만으로 자동화하면 깨질 수 있는 40~50개의 로케이터가 생깁니다. 네트워크 일시 중단이나 사소한 CSS 변경만으로도 전체 빌드가 중단될 수 있습니다.

내 접근 방식:

• 백엔드가 정상 작동하는지 확인하기 위해 “Add to Cart”(장바구니 추가)와 “Checkout”(결제) API 호출을 자동화합니다.
• 다양한 브라우저 해상도에서 UI에 대한 간단한 수동 “건전성 검사”를 수행합니다.

이렇게 하면 파이프라인이 정상 상태를 유지하고 개발자들이 만족합니다.

선택적 자동화의 이점

• 더 빠르고 신뢰할 수 있는 CI 파이프라인
• 잘못된 실패와 재실행 감소
• 테스트 결과에 대한 개발자 신뢰도 향상
• 유지보수 비용 감소
• 위험을 낮춘 빠른 릴리스 사이클

목표는 최대 커버리지가 아니라 최대 신뢰도입니다. 테스트가 위험을 실질적으로 줄이지 않으면서 배포를 지연시킨다면, 그 테스트는 파이프라인에 포함되지 않아야 합니다.