report

report skill 개요

report skill이 하는 일

report skill은 Playwright 중심의 테스트 리포팅 워크플로로, 원시 테스트 결과를 명확한 상태 보고서로 바꿔 줍니다. 사용자가 “test report”, “results summary”, “test status”, “show results”, “test dashboard”, “how did tests go”처럼 테스트 결과를 보고 싶다고 요청하는 상황에 맞춰 설계되었습니다. 단순히 터미널 로그를 요약하는 데 그치지 않고, 기존 Playwright 출력물이 있는지 확인하고, 필요하면 테스트를 실행하며, JSON 결과를 파싱하고, 현재 전달 맥락에 맞는 유용한 보고서를 만들도록 에이전트를 안내합니다.

Test Automation 팀에 가장 잘 맞는 경우

이 report skill은 Test Automation 엔지니어, QA 리드, Playwright를 사용하는 개발자, 그리고 저장소 안에서 테스트 결과를 빠르게 요약해야 하는 에이전트에게 특히 적합합니다. 팀에서 이미 test-results/, playwright-report/, GitHub Actions, Slack webhooks, TestRail 방식의 리포팅을 사용하고 있다면 잘 맞습니다. 이 skill의 핵심 역할은 테스트 생성이 아니라, 실행 이후 결과를 해석하고 테스트 상태를 전달하는 것입니다.

일반 프롬프트보다 유용한 이유

일반적인 “테스트를 요약해 줘” 프롬프트는 Playwright가 결과를 어디에 저장하는지, 테스트를 다시 실행해야 하는지, 최종 보고서를 어디로 보내야 하는지 놓치기 쉽습니다. report skill은 여기에 워크플로 판단을 더합니다. 기존 산출물을 확인하고, 결과가 없으면 JSON/HTML/list reporter로 Playwright를 실행하며, 통과/실패/건너뜀/flaky 개수를 추출하고, 실패한 테스트와 메시지를 식별한 뒤, 환경이 지원하는 경우 Markdown, HTML report, CI artifact, Slack, TestRail 같은 전달 위치를 선택하도록 돕습니다.

도입 전에 알아둘 점

상위 skill은 가볍게 구성되어 있습니다. 공개된 저장소 경로에는 SKILL.md만 보이며, helper script, rules, references, 번들 asset은 포함되어 있지 않습니다. 덕분에 검토하고 맞춤화하기는 쉽지만, 에이전트가 로컬 Playwright 설정과 사용 가능한 환경 변수에 의존해야 한다는 뜻이기도 합니다. 설치하기 전에 프로젝트가 Playwright를 사용하는지, 또는 이 워크플로를 다른 JavaScript 테스트 러너에 맞게 조정할 수 있는지 확인하세요.

report skill 사용 방법

report 설치 맥락

디렉터리에서 사용하는 저장소 경로로 skill을 설치합니다.

npx skills add alirezarezvani/claude-skills --skill report

설치 후에는 먼저 skill 소스를 확인하세요.

engineering-team/playwright-pro/skills/report/SKILL.md

공개된 skill 미리보기에는 추가 지원 폴더가 없으므로 SKILL.md가 주요 운영 가이드입니다. 본인 저장소에서는 playwright.config.*, package.json, .github/workflows/, test-results/, playwright-report/를 확인해 테스트 출력이 어떻게 생성되고 보고서를 어디로 전달해야 하는지 파악하세요.

skill에 필요한 입력 정보

report를 안정적으로 사용하려면 에이전트가 추측하지 않도록 충분한 맥락을 제공해야 합니다.

• 테스트가 이미 실행되었는지 여부
• Playwright 테스트에 보통 사용하는 명령어
• 결과 산출물 위치가 표준과 다를 경우 그 위치
• retry가 활성화되어 있는지 여부. flaky 테스트는 retry 동작을 바탕으로 추론되기 때문입니다.
• 원하는 출력 형식: Markdown, PR comment, Slack summary, TestRail push, local HTML report
• “테스트를 다시 실행하지 말 것” 또는 “CI에서만 실행” 같은 환경 제약

약한 프롬프트:

Make a test report.

더 나은 프롬프트:

Use the report skill for this Playwright project. Do not rerun tests unless no recent results exist. Check test-results/ and playwright-report/, parse JSON output if available, summarize passed/failed/skipped/flaky counts, list failed tests with error messages, and produce a Markdown report for the release channel.

실무에서 쓰기 좋은 report 워크플로

좋은 report 가이드 워크플로는 다음과 같습니다.

1. ls -la test-results/ playwright-report/ 2>/dev/null로 기존 산출물을 확인합니다.
2. 사용할 수 있는 결과가 없고 재실행이 허용되어 있다면 다음을 실행합니다.

   npx playwright test --reporter=json,html,list 2>&1 | tee test-output.log
   

3. JSON 출력을 파싱해 총계, 실행 시간, 실패, 건너뛴 테스트, retry를 확인합니다.
4. 전달 대상을 감지합니다.
   • TESTRAIL_URL이 있으면 TestRail 게시가 가능할 수 있습니다.
   • SLACK_WEBHOOK_URL이 있으면 Slack 요약을 게시할 수 있습니다.
   • .github/workflows/가 있으면 CI/PR 리포팅이 관련될 수 있습니다.
   • playwright-report/가 있으면 HTML report를 열거나 서빙할 수 있습니다.
5. 사용자가 단일 전달 대상만 요청한 경우가 아니라면 항상 Markdown 요약을 생성합니다.

더 좋은 결과를 얻기 위한 팁

보고서가 어떤 판단을 돕기 위한 것인지 에이전트에게 알려 주세요. 릴리스 매니저에게는 위험 요소와 차단 이슈가 필요하고, 개발자에게는 실패한 spec, stack trace, 재현 명령어가 필요합니다. QA 리드에게는 flaky 테스트 개수와 실행 시간 추이가 중요할 수 있습니다. 보고서를 PR에 붙여넣을 예정이라면 간결한 요약을 요청하세요. 장애 리뷰용이라면 suite, browser, error pattern별 실패 그룹화를 요청하는 것이 좋습니다.

report skill FAQ

report는 Playwright 전용인가요?

이 skill은 Playwright 명령어, 폴더, reporter를 중심으로 작성되어 있어 Playwright Test Automation에서 가장 정확합니다. 구조 자체는 Jest, Cypress 또는 다른 러너에 맞게 조정할 수 있지만, 명령어, 산출물 경로, flaky 테스트 감지 방식은 수정해야 합니다. 저장소에 테스트 산출물이 없고 Playwright 설정도 없다면 일반 프롬프트만으로도 비슷하게 충분할 수 있습니다.

report가 테스트를 자동으로 실행하나요?

최근 결과를 찾지 못한 경우 npx playwright test --reporter=json,html,list를 사용해 테스트를 실행하도록 에이전트를 안내할 수 있습니다. 다만 재실행을 허용하는지 반드시 명시해야 합니다. 대규모 suite에서는 테스트 재실행이 느리거나 비용이 크거나, CI 실패 당시의 원래 환경이 중요한 상황에서는 부적절할 수 있습니다.

report skill은 무엇을 생성하나요?

기본 출력은 통과, 실패, 건너뜀, flaky 테스트 개수, 전체 실행 시간, 실패한 테스트 상세를 포함한 Markdown 테스트 보고서입니다. 환경에 따라 워크플로가 결과를 TestRail, Slack, GitHub Actions artifact 또는 PR comment, Playwright HTML report로 전달할 수도 있습니다.

report를 설치하지 않는 편이 나은 경우는 언제인가요?

팀에서 Playwright를 사용하지 않거나, 엄격한 API를 갖춘 전용 리포팅 플랫폼을 이미 운영하고 있거나, 단일 테스트 실행을 넘어서는 과거 데이터 분석이 필요하다면 설치를 건너뛰거나 미루는 것이 좋습니다. 이 skill은 간결한 워크플로 프롬프트이지, 완전한 리포팅 서비스, 데이터베이스, 대시보드, flaky 테스트 관리 시스템이 아닙니다.

report skill 개선 방법

요청 전에 report 입력 정보를 정리하기

report 결과를 개선하는 가장 빠른 방법은 실행 범위를 명확히 제공하는 것입니다. 테스트 명령어, 산출물 경로, 전달 대상, 독자, 재실행 정책을 포함하세요. 예를 들면 다음과 같습니다.

Generate a report for the CI Playwright run. Use existing artifacts only. Look in test-results/ and playwright-report/. Output a PR-ready Markdown summary with top failures, flaky tests, and whether the build should block merge.

이렇게 하면 에이전트가 테스트를 불필요하게 다시 실행하거나, 필요한 수준과 다른 상세도로 보고서를 만드는 일을 줄일 수 있습니다.

흔한 실패 모드 다루기

자주 발생하는 문제로는 JSON 출력 누락, 오래된 산출물, 지나치게 큰 로그, 모호한 retry가 있습니다. JSON을 사용할 수 없다면 에이전트에게 test-output.log와 HTML report metadata를 대체 자료로 사용하라고 요청하세요. 산출물이 오래되었을 수 있다면 timestamp 확인을 요구하세요. 로그가 너무 크다면 전체 stack trace를 붙여넣기보다 실패한 테스트 제목과 처음으로 의미 있는 오류 메시지 기준으로 그룹화해 달라고 요청하는 편이 좋습니다.

팀 워크플로에 맞게 report 조정하기

이 skill에는 번들 script가 없기 때문에, 팀별 개선은 보통 로컬 규칙을 추가하는 방식으로 이뤄집니다. 선호하는 보고서 템플릿, Slack 채널 규칙, TestRail 프로젝트 매핑, CI artifact URL 패턴, severity label을 문서화하세요. 그런 다음 프롬프트에서 해당 규칙을 참조하면 report skill이 릴리스 프로세스에 맞는 결과를 만들 수 있습니다.

첫 report 이후 반복 개선하기

첫 보고서는 초안으로 보고 다듬어 가세요. 다음과 같은 후속 요청을 할 수 있습니다.

• “Group failures by root cause.”
• “Separate product defects from test infrastructure failures.”
• “Add rerun recommendations for flaky tests.”
• “Make this suitable for a non-technical release update.”
• “Include exact commands to reproduce the failed specs.”

이렇게 하면 report가 단순한 개수 나열이 아니라 의사결정에 집중할 수 있습니다.