핵심 기능기능프라이싱보안문서변경이력
로그인무료로 시작하기

시작하기

  • QA Note란?
  • 빠른 시작 가이드
  • Extension 설치
  • 프로젝트 멤버

기능 가이드

  • 스크린샷 & 어노테이션
  • 세션 레코딩
  • 유지보수 리포트
  • 이슈 상태 모델
  • 멀티 이슈 윈도우
  • Storage · DOM 스냅샷

연동

  • GitHub
  • 커밋 키
  • MCP 서버
  • Slack
  • Webhook
  • Vercel
  • 기존 Playwright

API 레퍼런스

  • 인증
  • 엔드포인트 레퍼런스
  • 공개 API v1
  • 에러 처리

AI 에이전트와 함께 쓰는 이슈 트래커. 수정은 당신의 에이전트가, 기록은 QA Note가.

Made in Seoul · © 2026 QA Note
제품핵심 기능기능프라이싱보안변경이력
리소스문서MCP 가이드Chrome 확장
회사브랜드이용약관개인정보처리방침

에프에프지지(ffgg)|대표: 한송욱

사업자등록번호: 746-54-00870[사업자정보확인]|통신판매업신고번호: 제 2024-서울마포-2178 호

주소: 서울특별시 마포구 월드컵북로6길 26, 5층(동교동, 삼기빌딩)

이메일: support@qanote.app|호스팅 제공자: Vercel Inc.

© 2026 QA Note. All rights reserved.

이용약관개인정보처리방침쿠키정책
  1. 홈
  2. /
  3. Docs
  4. /
  5. 연동

기존 Playwright 연결

기존 CI의 Playwright 결과를 QA Note 검토함으로 연결합니다

목차
  • 이 연결이 하는 일
  • 준비 사항
  • 1. QA 증거 가져오기 전용 키 발급
  • 2. 기존 Playwright report 만들기
  • 3. 얇은 importer 연결
  • 4. 수신 영수증 확인
  • 경계와 문제 해결
  • 관련 문서

이 연결이 하는 일

QA Note는 이미 운영 중인 Playwright와 CI의 결과만 받습니다. QA Note 서버가 Playwright나 브라우저를 시작하지 않고, 테스트·selector·workflow를 생성하거나 리포지토리를 수정하지 않습니다.

프로젝트 QA 관리 → 기존 Playwright 연결 화면의 사전 점검도 아래 고정 경로의 존재 여부만 읽습니다.

  • 루트 package.json
  • 루트 playwright.config.ts, .js, .mts, .mjs, .cts, .cjs
  • .github/workflows 안의 .yml, .yaml 파일명

파일 본문과 테스트 코드는 분석하지 않습니다. Playwright config와 CI workflow를 모두 발견해도 실제 결과가 한 번 도착하기 전에는 결과 연결됨으로 표시하지 않습니다.

준비 사항

  • 프로젝트에 GitHub 리포지토리가 연결되어 있어야 합니다.
  • 기존 Playwright 테스트가 JSON 또는 JUnit report를 만들어야 합니다.
  • 기존 GitHub Actions workflow가 있어야 합니다.
  • 조직 소유자 또는 관리자가 qa:write 전용 API Key를 한 번 발급해야 합니다.

Playwright나 workflow가 없다면 QA Note는 자동으로 만들지 않습니다. 개발팀이 기존 개발 절차에 맞춰 먼저 준비해야 합니다.

1. QA 증거 가져오기 전용 키 발급

조직 설정 → API Keys에서 새 키를 만들고 QA 증거 가져오기 (qa:write) 권한만 선택합니다. 키 원문은 다시 표시되지 않으므로 개발팀의 안전한 secret 관리 경로로 한 번만 전달합니다.

GitHub 리포지토리의 Actions secret에 아래 이름으로 저장합니다.

text
QANOTE_API_KEY

키 원문을 workflow 파일, 로그, QA Note 이슈에 붙이지 마세요.

2. 기존 Playwright report 만들기

기존 테스트 명령에 JSON reporter를 추가하는 예시입니다. 기존 reporter가 있다면 배열로 함께 유지할 수 있습니다.

bash
PLAYWRIGHT_JSON_OUTPUT_NAME=playwright-results.json \
  npx playwright test --reporter=json

JUnit report도 지원합니다. 여러 Playwright project가 한 report에 있으면 importer의 --playwright-project로 하나를 명시합니다.

3. 얇은 importer 연결

@qanote/playwright-importer는 이미 생성된 report를 정규화해 전송합니다. Playwright나 브라우저를 설치하거나 실행하지 않으며 stdout/stderr, trace 본문, screenshot·video 본문을 업로드하지 않습니다. 명시한 artifact는 byte/hash 메타데이터만 전송합니다.

먼저 전송 없는 dry-run으로 report를 확인합니다.

bash
npx @qanote/playwright-importer \
  --report playwright-results.json \
  --project-id <QA Note project ID> \
  --page-url https://example.com/ \
  --browser-name chromium \
  --browser-version <실행한 브라우저 버전> \
  --viewport 1280x720 \
  --dry-run

그다음 기존 workflow에서 secret을 환경 변수로 전달해 실제 결과를 보냅니다.

bash
QANOTE_API_KEY="${QANOTE_API_KEY}" \
npx @qanote/playwright-importer \
  --report playwright-results.json \
  --project-id <QA Note project ID> \
  --page-url https://example.com/ \
  --browser-name chromium \
  --browser-version <실행한 브라우저 버전> \
  --viewport 1280x720

GitHub Actions에서는 QANOTE_API_KEY 환경 변수 값을 ${{ secrets.QANOTE_API_KEY }}로 연결하세요. secret이 fork pull request에 노출되지 않도록 기존 조직의 신뢰 경계를 그대로 적용합니다.

4. 수신 영수증 확인

기존 CI를 한 번 실행한 뒤 프로젝트 QA 관리 → 기존 Playwright 연결로 돌아갑니다. 마지막 수신 시각과 receipt ID가 보이면 결과 연결이 확인된 상태입니다.

가져온 실패·오류 항목은 자동으로 이슈가 되지 않습니다. QA 검토함의 선택되지 않은 후보로 들어오며, 사람이 증거를 확인하고 선택해 승인한 항목만 QA 이슈가 됩니다.

경계와 문제 해결

  • Playwright config가 없음 — 개발팀 설정 필요가 정상 상태입니다.
  • workflow가 없음 — 기존 CI를 먼저 준비해야 하며 QA Note가 생성하지 않습니다.
  • GitHub 확인 실패 — GitHub App의 repository contents 읽기 권한과 설치 중단 여부를 확인하세요.
  • 환경은 발견됐지만 결과 연결 대기 — importer가 포함된 기존 CI를 한 번 실행한 뒤 다시 확인하세요.
  • receipt가 갱신되지 않음 — API Key에 qa:write가 있는지, secret 이름과 project ID가 맞는지 확인하세요. 키 원문은 로그에 출력하지 마세요.

QA Note는 Actions retry·parallelism·browser matrix를 운영하지 않습니다. 이 설정은 기존 CI의 책임으로 유지됩니다.

관련 문서

  • GitHub 연동
  • API 인증
이전
Vercel
다음
인증

목차

  • 이 연결이 하는 일
  • 준비 사항
  • 1. QA 증거 가져오기 전용 키 발급
  • 2. 기존 Playwright report 만들기
  • 3. 얇은 importer 연결
  • 4. 수신 영수증 확인
  • 경계와 문제 해결
  • 관련 문서