QAlity - Playwright × Jira

수동 회귀 테스트의 "이슈로 만들고 → 돌리고 → 결과 적고 → 상태 옮기는" 루프가 분리돼 있어 일관성이 떨어진다. 실행은 로컬에서, 결과는 사람 기억에, 상태 전이는 나중에 - 이 사이에서 기록이 샌다.

Jira Cloud(QAlity) 이슈를 테스트 시나리오 단위로 삼아, pytest + Playwright 실행 결과를 다시 Jira 코멘트로 회신하고 이슈 상태까지 전이시키는 워크플로우 통합 데모. Naver 검색 시나리오(QAP-1~3)로 이슈 → 실행 → 회신 → 상태 전이의 왕복을 보인다.

테스트 실행과 이슈 트래커가 따로 노는 팀, 그리고 "테스트 자동화를 우리 워크플로우에 어떻게 들이는가"를 실물로 보여줘야 하는 QA 컨설팅 상황.

• Jira(QAlity) 이슈를 시나리오 단위로 삼아 pytest + Playwright 실행
• 결과를 ADF(Atlassian Document Format) 코멘트로 Jira에 회신
• 성공/실패에 따라 Jira 이슈 상태 자동 전이
• 실패는 test_failures.log에 별도 기록

• 도구가 아니라 "왕복"을 보여주는 데 집중 - 시나리오는 Naver 검색 3개로 최소화하고, 대신 이슈 → 실행 → 회신 → 상태 전이의 끝과 끝을 완결
• 결과를 사람이 읽는 로그가 아니라 Jira 코멘트로 - QA의 산출물이 이슈 트래커 안에 남아야 팀의 일과 연결된다
• 일부러 강제 실패 케이스(QAP-2)를 넣어, 통합이 실패도 정확히 회신·전이하는지까지 확인

• Jira 왕복 무결성 - 이슈 → 실행 → 코멘트 회신 → 상태 전이가 중간에 누락 없이 끝까지 이어지는가
• 재실행 멱등성 - 같은 이슈를 다시 돌려도 코멘트·상태가 이중으로 쌓이거나 어긋나지 않는가
• 강제 실패 케이스(QAP-2)로 성공뿐 아니라 실패도 정확히 회신·전이하는지 확인했는가
• 성공/실패 결과가 정확한 Jira 상태 전이로 매핑되는가 - 통과인데 실패 상태로 넘어가는 오전이가 없는가
• 결과 코멘트가 ADF(Atlassian Document Format) 스키마를 지켜 Jira에서 깨지지 않고 렌더링되는가
• flaky 테스트 - 실패가 진짜 회귀인지 불안정인지 test_failures.log로 구분 가능한가

포트폴리오·데모 규모(Python 한 덩어리, 시나리오 3개). 실 팀 도입 지표는 없음 - Jira ↔ Playwright 워크플로우 왕복 통합 자체를 보이는 것이 목적.

• 시나리오를 Naver 검색으로 둔 건 데모엔 충분하지만, 실제 컨설팅에선 클라이언트의 회귀 시나리오로 갈아끼워야 가치가 산다. 통합 뼈대는 재사용 가능해도 시나리오는 재사용 불가라는 걸 분명히 해둔다.