티스토리 뷰

낙서장/chatGPT

QA Lens - PRD

댕기사랑 2026. 9. 18. 07:34
728x90

QA Lens

Jira + TestRail 기반 프로젝트 품질 인사이트 대시보드

1. 프로젝트 목적

QA Lens는 Jira와 TestRail의 데이터를 연결하여 단순한 테스트 진행률이 아니라 프로젝트의 실제 품질 위험과 테스트 전략에 필요한 인사이트를 보여주는 웹 대시보드다.
기존 QA 업무에서는 다음 정보가 서로 분산되어 있다.

  • Jira Epic
  • Jira Bug
  • TestRail Project
  • TestRail Test Suite
  • Test Case
  • Test Run
  • Test Result
  • Failed / Blocked Result
  • TestRail Result와 연결된 Jira Bug

QA Lens는 이 데이터를 하나의 프로젝트 단위로 연결해 다음 5가지 질문에 답한다.

  1. Quality Hotspot
    • 현재 품질 문제가 가장 집중되어 있는 기능은 어디인가?
  2. Recurring Defect Detection
    • 반복적으로 발생하는 버그 유형은 무엇인가?
  3. High-Value Test Case
    • 실제로 중요한 결함을 자주 찾아내는 Test Case는 무엇인가?
  4. Automation Priority
    • 어떤 Manual Test Case부터 자동화해야 효과가 가장 큰가?
  5. Test Coverage Gap
    • Bug는 많이 발생하는데 Test Case가 부족한 영역은 어디인가?

이 대시보드의 핵심은 단순 통계가 아니라 다음 행동을 결정하게 만드는 것이다.

“이번 Release에서 어디를 더 테스트해야 하는가?”

“다음 Sprint에서 무엇을 자동화해야 하는가?”

“어떤 영역에서 Regression Risk가 반복되고 있는가?”

2. 핵심 Product Concept

전체 구조는 다음과 같다.

Jira
 ├─ Epic
 ├─ Bug
 ├─ Severity
 ├─ Component
 ├─ Status
 └─ Linked Issue

        +

TestRail
 ├─ Project
 ├─ Suite
 ├─ Section
 ├─ Test Case
 ├─ Test Run
 └─ Test Result
      ├─ Passed
      ├─ Failed
      └─ Blocked

        ↓

Relation Engine

        ↓

QA Lens

 ├─ Quality Hotspot
 ├─ Recurring Defect
 ├─ High-Value TC
 ├─ Automation Priority
 └─ Test Coverage Gap

3. 프로젝트 연결 구조

현재 데이터 구조에서 가장 중요한 기준점은 Jira Epic이다.

3.1 기준 관계

Jira Epic
   ↓
QA Project

Jira Epic
   ↕
TestRail Project

TestRail Test Case
   ↓
Test Execution
   ↓
Failed / Blocked
   ↓
Linked Jira Bug

따라서 QA Lens 내부에서는 하나의 분석 단위를 다음처럼 정의한다.

QA Project
=
Jira Epic
+
관련 TestRail Project
+
관련 Test Case
+
Test Execution
+
관련 Jira Bug

4. 핵심 데이터 관계

권장 관계 모델:

Epic
 ├─ TestRail Project
 │    ├─ Test Suite
 │    │    ├─ Section
 │    │    │    ├─ Test Case
 │    │    │    │    ├─ Execution
 │    │    │    │    │    ├─ Pass
 │    │    │    │    │    ├─ Fail
 │    │    │    │    │    └─ Block
 │    │    │    │    │
 │    │    │    │    └─ Linked Jira Bug
 │
 └─ Jira Bug

실제 데이터 분석에서는 다음 연결 키가 중요하다.

Epic Key
TestRail Project ID
TestRail Case ID
TestRail Run ID
Jira Bug Key

5. 대시보드 전체 Information Architecture

웹 대시보드는 크게 3단계로 구성한다.

Level 1

Portfolio / Project Overview

전체 프로젝트를 비교한다.
예:

Checkout Renewal
Search v2
Coupon Platform
Order Revamp

Level 2

Project Quality Dashboard

선택한 Epic 기준으로 5개 핵심 인사이트를 보여준다.

Level 3

Detail Drill-down

특정 기능 / Test Case / Bug를 상세 분석한다.

6. Dashboard 기본 Layout

상단:

QA Lens

Project
[ Checkout Renewal ▼ ]

Release
[ All / v5.1 / v5.2 / v5.3 ▼ ]

Period
[ Last 90 days ▼ ]

Refresh
[ Sync Jira/TestRail ]

그 아래 핵심 Summary Card.

Executed TC
2,842

Pass Rate
91.9%

Failed
173

Blocked
55

Linked Bugs
91

Critical Bugs
4

7. Main Dashboard 구조

권장 화면 구성:

┌───────────────────────────────────────────┐
│ Project / Release / Period Filter         │
└───────────────────────────────────────────┘

┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ TC     │ │ Pass   │ │ Bugs   │ │ Risk   │
└────────┘ └────────┘ └────────┘ └────────┘

┌──────────────────────┬────────────────────┐
│ Quality Hotspot      │ Recurring Defect   │
│                      │                    │
└──────────────────────┴────────────────────┘

┌──────────────────────┬────────────────────┐
│ High Value TC        │ Automation Priority│
│                      │                    │
└──────────────────────┴────────────────────┘

┌───────────────────────────────────────────┐
│ Test Coverage Gap                         │
└───────────────────────────────────────────┘

8. 핵심 기능 1

Quality Hotspot

목적

프로젝트 내에서 품질 문제가 집중되는 영역을 찾는다.
단순 Bug Count가 아니라 Test Execution 대비 실패와 결함 비율을 본다.

기본 분석 단위

추천:

TestRail Section
+
Jira Component

가능하면 TestRail Section과 Jira Component를 동일한 Feature Group으로 매핑한다.
예:

Checkout

Payment
Coupon
Shipping
Order
Refund

핵심 지표

Failure Rate

Failed Execution
-----------------
Executed Test

Block Rate

Blocked Execution
------------------
Executed Test

Defect Rate

Linked Jira Bugs
-----------------
Executed Test

Critical Defect Rate

Critical + Blocker Bugs
------------------------
Executed Test

Hotspot Score

추천 초기 모델:

Hotspot Score =

Failure Rate          × 30
+
Defect Rate           × 25
+
Critical Defect Rate  × 25
+
Block Rate            × 10
+
Recurring Bug Rate    × 10

0~100 Normalize.

화면 표현

Heatmap

Feature             Risk

Payment             █████████ 91
Coupon              ████████  82
Refund              ██████    63
Order               █████     51
Search              ██        22

또는 Bubble Chart.
X:

Executed TC

Y:

Defect Rate

Bubble Size:

Critical Bugs

Drill-down

Payment 클릭 시:

Payment

Executed TC
341

Failed
42

Linked Bugs
31

Critical
5

Recurring Bugs
7

Risk Score
91

하단:

Top Failing Test Cases
Top Bugs
Recurring Defects
Recent Failure Trend

9. 핵심 기능 2

Recurring Defect Detection

목적

Jira Issue Key는 다르지만 본질적으로 반복되는 동일/유사 Bug를 찾는다.

활용 데이터

Jira:

Summary
Description
Component
Labels
Priority
Severity
Epic
Created Date
Resolution

처리 방식

1차:

Component 동일

2차:

Summary + Description Embedding

3차:

Cosine Similarity

기본 Algorithm

defect_text = (
    bug.summary
    + bug.description
    + bug.component
)

Embedding 생성.
Similarity:

similarity > 0.82

이면 동일 Cluster 후보.

추가 조건

오탐을 줄이기 위해 다음 조건을 같이 사용한다.

같은 Epic

또는

같은 Jira Component

또는

같은 TestRail Section

Recurring Score

Occurrence Count     40%
Release Spread       30%
Severity             20%
Recent Occurrence    10%

UI 예시

Recurring Defects

1.

Payment status synchronization

Occurrences
7

Affected Releases
v4.7
v4.9
v5.1
v5.3

Highest Severity
Critical

Related Bugs
PAY-183
PAY-341
PAY-587
...

시각화

Timeline:

v4.7   ●

v4.8

v4.9       ●

v5.0

v5.1           ●

v5.3               ●

사용자는 한눈에

“이 문제는 고쳐졌다고 생각했는데 계속 돌아오네.”

를 확인할 수 있다.

10. 핵심 기능 3

High-Value Test Case

목적

Test Case 수가 많다고 품질이 높아지는 것은 아니다.
실제로 중요한 Bug를 발견하는 Test Case를 찾는다.

TC별 수집 데이터

Execution Count

Pass Count

Fail Count

Blocked Count

Linked Bug Count

Critical Bug Count

Major Bug Count

Recent Failure

Release Coverage

기본 지표

Failure Rate

Fail Count
----------
Execution Count

Defect Detection Rate

Linked Bug Count
----------------
Execution Count

High Value Score

추천:

High Value Score =

Defect Detection Rate  × 35

Critical Bug Weight    × 25

Execution Frequency    × 15

Release Coverage       × 15

Recent Failure         × 10

단, 주의사항

Failure Rate가 너무 높다고 항상 좋은 TC는 아니다.
예:

Execution 2
Fail 2

는 데이터가 부족하다.
따라서 최소 실행 조건을 둔다.
추천:

Execution Count >= 5

또는 Release 기준:

3개 이상 Release에서 실행

UI

High-Value Test Cases

TC-394
Coupon + Partial Refund

Execution
18

Failures
7

Detected Bugs
6

Critical Bugs
2

Value Score
94

하단:

Why this matters

- 3개의 Release에서 반복 Failure
- Critical Bug 2건 발견
- Regression Bug 반복 탐지

11. 핵심 기능 4

Automation Priority

이 기능이 실제 운영상 가장 유용할 가능성이 높다.

목적

모든 Manual TC를 자동화하는 것이 아니라
자동화했을 때 사람이 가장 많은 시간을 되찾는 Test Case를 찾는다.

필요한 데이터

TestRail에서:

Execution Count

Execution Frequency

Average Duration
가능하면

Pass Rate

Fail Rate

Test Type

Automation Status

Section

자동화 상태는 Custom Field를 권장한다.
예:

Manual
Candidate
Automated
Not Automatable

Automation Priority Score

추천:

Frequency            30%

Manual Execution Time 25%

Repeatability        20%

Stability            15%

Automation Ease      10%

Frequency Score

최근 90일 Execution 횟수

Normalize.

Manual Time

만약 실제 Duration 데이터가 없다면 우선 Custom Field로 TC Expected Duration을 둔다.
예:

1 min
3 min
5 min
10 min
15 min+

Repeatability

다음 특성이 강할수록 높게 평가한다.

동일 Step 반복

고정 Input

명확한 Expected Result

매 Release 실행

Smoke / Regression

Stability

UI나 Requirement가 너무 자주 바뀌면 자동화 유지비가 높아진다.
따라서:

최근 변경 빈도 낮음
+
Pass Rate 높음

을 안정 TC로 본다.

추천 Score

Automation Priority =

Frequency      × .30
+
Manual Time   × .25
+
Repeatability × .20
+
Stability     × .15
+
Ease          × .10

UI

Automation Candidates

1. Login - Normal User

Executions / 90d
47

Manual Time
3 min

Estimated Manual Time
141 min

Priority
95

Estimated Monthly Saving
94 min

중요한 UX

자동화 추천에는 반드시 이유를 보여준다.
예:

Why recommended?

✓ 매 Release 반복
✓ 최근 90일 47회 수행
✓ Pass Rate 98%
✓ Expected Result 명확
✓ UI 변경 빈도 낮음

12. 핵심 기능 5

Test Coverage Gap

가장 전략적인 기능이다.

목적

Bug는 많이 발생하는데 이를 검증하는 Test Case가 부족한 영역을 찾는다.

기본 Logic

Feature별:

Bug Count

Test Case Count

Execution Count

Critical Bug Count

가장 단순한 Gap Index

Bug Density
=
Bug Count / Test Case Count

그러나 이것만으로는 부족하다.
추천 공식:

Coverage Gap Score =

Defect Density        40%

Critical Bug Weight   25%

Low TC Coverage       20%

Low Execution Coverage 15%

예

Payment Retry

Bug
11

Related Test Case
2

Execution
7

Critical
3

Coverage Gap
94

UI

Matrix 방식 추천.
X:

Test Coverage

Y:

Bug Risk
                 HIGH RISK

                    Payment Retry
                        ●

          Coupon
             ●


────────────────────────────────
LOW TEST                   HIGH TEST

                        Search
                           ●


                 LOW RISK

좌측 상단:
High Risk + Low Test Coverage
가 가장 위험한 영역이다.

13. 핵심 Dashboard Insight Summary

상단에 AI가 자연어 요약을 보여준다.
예:

이번 Release 주요 품질 인사이트

Payment 영역의 Risk가 가장 높습니다.

특히 Payment Retry에서
최근 3개 Release 동안 유사 Bug가 반복되고 있습니다.

Coupon + Partial Refund TC는
Critical Bug를 반복적으로 탐지하여
High-Value TC로 평가됩니다.

Login Regression TC는
최근 90일간 47회 수동 수행되어
자동화 우선순위가 가장 높습니다.

Payment Retry 영역은
Bug 대비 TC 수가 부족해
추가 Test Case 검토가 필요합니다.

이 부분만 LLM을 활용한다.
모든 Score와 숫자는 Backend에서 계산한다.

14. 상세 Navigation

사이드 메뉴:

Overview

Quality Hotspot

Recurring Defects

High-Value Tests

Automation

Coverage Gap

Data Explorer

Settings

15. Data Explorer

분석 결과에 대한 신뢰성을 위해 반드시 필요하다.
사용자가 Dashboard 숫자를 클릭하면 실제 원본 데이터를 확인할 수 있어야 한다.
예:

Hotspot
Payment
91

↓

관련 Test Case

TC-391
TC-394
TC-402

↓

관련 Jira Bug

PAY-183
PAY-291
PAY-310

Dashboard는 Black Box가 되면 안 된다.

16. Filter 설계

모든 화면에서 동일한 Global Filter를 사용한다.

Epic

Release

TestRail Run

Date Range

Feature / Component

Tester

Severity

Test Status

단 Tester Filter는 사람 평가 목적으로 사용하지 않는다.

17. Tester 데이터 처리 원칙

다음은 피한다.

Tester Ranking

Bug Detection Ranking

Best QA

대신:

Tester Coverage

Tester Expertise Area

Feature Ownership

정도로 제한한다.

18. Backend Architecture

이미 Codex에서 Jira / TestRail API를 사용하고 있으므로 Connector를 유지한다.

Jira API
        \
         Sync Worker
        /
TestRail API

      ↓

Normalization Layer

      ↓

QA Analytics DB

      ↓

Analytics Engine

      ↓

API

      ↓

Dashboard

19. API 데이터를 Dashboard에서 직접 사용하지 않는 이유

Dashboard 로딩 때마다 Jira와 TestRail API를 직접 호출하면:

느림

API Rate Limit

데이터 불일치

과거 비교 어려움

문제가 생긴다.
따라서 분석용 Local DB를 둔다.

20. Sync 방식

추천:

Full Sync

최초 1회

이후:

Incremental Sync

Jira
updated > last_sync

TestRail
최근 Run / Result

21. Sync 주기

MVP:

Manual Sync Button

+

30분 Scheduled Sync

이면 충분하다.
실시간일 필요는 없다.

22. 권장 DB Schema

projects

id

name

jira_epic_key

testrail_project_id

test_cases

id

testrail_case_id

project_id

title

section

priority

automation_status

estimated_duration

test_runs

id

testrail_run_id

project_id

release

created_at

test_executions

id

case_id

run_id

status

tester

executed_at

duration

jira_bugs

id

jira_key

project_id

summary

description

component

severity

priority

status

created_at

resolved_at

execution_bug_links

execution_id

bug_id

이 Table이 매우 중요하다.

23. Feature Mapping Table

TestRail Section과 Jira Component 이름이 항상 같지 않을 가능성이 있다.
따라서 별도 Mapping Table을 둔다.

feature_mapping

id

project_id

feature_name

jira_component

testrail_section

예:

Feature

Payment

Jira Component
Checkout-Payment

TestRail Section
Checkout / Payment

24. Derived Metrics Table

매번 Dashboard 요청 때 무거운 계산을 하지 않도록 집계 테이블을 둘 수 있다.

quality_metrics

project

release

feature

executed_count

failed_count

blocked_count

bug_count

critical_bug_count

recurring_bug_count

hotspot_score

초기 MVP는 Query 계산으로도 가능하고, 데이터가 많아지면 Materialized View로 전환한다.

25. Analytics Engine 구조

권장 구조:

analytics/

hotspot.py

recurring_defect.py

high_value_tc.py

automation_priority.py

coverage_gap.py

summary.py

각 인사이트는 독립 Service로 만든다.

26. API 설계

Overview

GET /api/projects/{project_id}/overview

Quality Hotspot

GET /api/projects/{project_id}/hotspots

Recurring Defect

GET /api/projects/{project_id}/recurring-defects

High Value Test

GET /api/projects/{project_id}/high-value-tests

Automation Candidates

GET /api/projects/{project_id}/automation-candidates

Coverage Gap

GET /api/projects/{project_id}/coverage-gaps

27. Dashboard Response 예

{
  "project": "Checkout Renewal",
  "release": "5.3",

  "overview": {
    "executed": 2842,
    "passed": 2614,
    "failed": 173,
    "blocked": 55,
    "bugs": 91,
    "critical_bugs": 4
  },

  "top_hotspot": {
    "feature": "Payment",
    "score": 91
  },

  "top_recurring_defect": {
    "cluster": "Payment status synchronization",
    "occurrences": 7
  },

  "top_high_value_tc": {
    "case_id": "C394",
    "score": 94
  },

  "top_automation_candidate": {
    "case_id": "C105",
    "score": 95
  },

  "top_coverage_gap": {
    "feature": "Payment Retry",
    "score": 94
  }
}

28. Frontend 권장 Stack

현재 Codex 환경에서 큰 제약이 없다면:

Next.js

TypeScript

Tailwind CSS

TanStack Query

Recharts

추천.
복잡한 데이터 테이블:

TanStack Table

29. Chart 설계

Quality Hotspot

추천:

Horizontal Bar

또는

Bubble Chart

Recurring Defect

추천:

Timeline
+
Cluster Table

High-Value TC

추천:

Ranked Table

Automation

추천:

Impact vs Effort Matrix

X:

Automation Effort

Y:

Time Saving

좌측 상단이 Quick Win.

Coverage Gap

추천:

Risk vs Coverage Matrix

30. 색상 원칙

Risk는 일관되게 사용한다.

Green
Low Risk

Yellow
Moderate

Orange
High

Red
Critical

그러나 전체 화면은 과한 빨간색 사용을 피한다.
Dashboard 기본 배경:

White / Neutral Gray

31. 데이터 신뢰성 표시

각 분석에는 데이터 Coverage를 표시한다.
예:

Analysis Confidence

Linked TC-Bug Coverage
82%

왜냐하면 Fail TC 중 Jira Bug가 연결되지 않는 경우가 존재할 수 있기 때문이다.
따라서

Linked Failures

Unlinked Failures

도 표시한다.

32. 중요한 데이터 품질 KPI

Dashboard 상단 또는 Settings에서:

TC → Jira Bug Link Rate

Epic → TestRail Mapping Rate

Test Execution Coverage

Missing Component Rate

를 보여준다.

33. AI 활용 범위

AI는 최소화한다.

AI 사용

Recurring Defect Semantic Clustering
Bug Pattern Summary
Dashboard Narrative Summary

AI 사용하지 않음

Fail Rate

Pass Rate

Bug Count

Hotspot Score

Automation Score

Coverage Gap Score

모두 deterministic calculation.

34. MVP에서 반드시 구현할 것

Phase 1:

Epic 선택

TestRail Project Mapping

Overview

Quality Hotspot

High-Value Test Case

Automation Priority

Coverage Gap

Recurring Defect는 Embedding이 필요하기 때문에 Phase 1.5로 해도 된다.
다만 목표 5개를 모두 처음부터 넣는다면 Rule 기반 Cluster → Semantic Cluster 순으로 확장한다.

35. MVP 구현 순서

Sprint 1

Existing Jira Connector 확인

Existing TestRail Connector 확인

Epic ↔ TestRail Project Mapping

Local DB Schema

Sprint 2

Jira Sync

TestRail Sync

Execution ↔ Bug Relation 저장

Feature Mapping

Sprint 3

Overview Metrics

Hotspot Engine

Dashboard Base UI

Sprint 4

High-Value TC Engine

Automation Priority Engine

Coverage Gap Engine

Sprint 5

Recurring Defect Engine

Embedding

Bug Cluster

Sprint 6

Drill-down

Filtering

Data Explorer

QA

36. 프로젝트 완료 기준

다음 질문에 Dashboard에서 바로 답할 수 있어야 한다.

1.

현재 가장 위험한 Feature는?

2.

최근 반복적으로 발생하는 Bug는?

3.

가장 많은 중요한 Bug를 찾아낸 TC는?

4.

가장 먼저 자동화해야 할 TC는?

5.

Bug 대비 Test Coverage가 부족한 영역은?
이 5개 질문에 3번 클릭 이내로 답할 수 있으면 성공이다.

37. Codex 구현 지시문

아래 내용을 Codex에 전달하면 된다.

Build a QA analytics web dashboard called QA Lens.

Existing systems already provide working Jira and TestRail API integrations.

Do not rebuild the existing connectors unless necessary.

The dashboard must analyze Jira + TestRail data at Jira Epic project level.

DATA RELATIONSHIP

Jira Epic
↔ TestRail Project

TestRail Test Case
→ Test Execution

Failed / Blocked Test Execution
→ Linked Jira Bug

Use this relationship as the core domain model.

PRIMARY DASHBOARD GOALS

Implement these five analytics modules:

1. Quality Hotspot
2. Recurring Defect Detection
3. High-Value Test Case
4. Automation Priority
5. Test Coverage Gap

QUALITY HOTSPOT

Calculate risk by feature using:

- execution count
- fail rate
- blocked rate
- bug count
- critical bugs
- recurring defects

HIGH VALUE TEST CASE

Rank test cases based on:

- execution count
- failure rate
- linked bug detection
- critical bug detection
- release coverage

AUTOMATION PRIORITY

Rank manual test cases based on:

- execution frequency
- manual execution time
- repeatability
- stability
- automation ease

TEST COVERAGE GAP

Compare:

- bug count
- critical bug count
- test case count
- execution count

Identify high-risk areas with low test coverage.

RECURRING DEFECT

Cluster Jira bugs using:

- project
- component
- summary
- description

Start with rule-based grouping.

Then optionally use semantic embeddings for similar bug detection.

ARCHITECTURE

Existing Jira API
+
Existing TestRail API

→ Sync Service

→ Local Analytics DB

→ Analytics Engine

→ REST API

→ Web Dashboard

Do not query Jira or TestRail directly on every frontend request.

Store normalized data locally.

Use incremental sync.

FRONTEND

Use:

Next.js
TypeScript
Tailwind CSS
TanStack Query
Recharts
TanStack Table

MAIN SCREEN

Header filters:

- Epic
- Release
- Test Run
- Date Range

Summary cards:

- Executed Tests
- Pass Rate
- Failed
- Blocked
- Linked Bugs
- Critical Bugs

Dashboard sections:

Quality Hotspot

Recurring Defects

High-Value Test Cases

Automation Candidates

Test Coverage Gap

Each section must support drill-down.

DATA EXPLORER

All analytics must be explainable.

Users must be able to click a metric and inspect related:

- Test Cases
- Test Executions
- Jira Bugs

AI RULE

AI may be used only for:

- semantic defect clustering
- defect summaries
- narrative insights

AI must not calculate statistics.

All numerical metrics and scores must be deterministic Python/SQL logic.

IMPORTANT

Avoid tester ranking.

This dashboard is for project quality improvement, not employee evaluation.

Add unit tests for all five analytics engines.

Create mock Jira/TestRail data if live data is unavailable during development.

After implementation:

run tests,
fix errors,
run the application,
verify all five dashboard modules,
and document setup in README.

38. 최종 제품 메시지

QA Lens는 다음 질문에 답하는 제품이어야 한다.

테스트를 얼마나 했는가?

가 아니라

테스트 결과가 우리 제품에 대해 무엇을 말해주고 있는가?

단순 Pass/Fail Dashboard에서 끝나지 않고,
과거 테스트와 버그 데이터를 다음 테스트 전략으로 바꾸는 Dashboard
가 최종 목표다.
 
#QA대시보드 #QAAnalytics #품질데이터분석 #Jira #TestRail #테스트자동화 #소프트웨어품질 #테스트케이스 #버그분석 #품질관리 #테스트전략 #데이터대시보드 #QA엔지니어 #업무자동화 #AI품질분석

728x90
반응형

'낙서장 > chatGPT' 카테고리의 다른 글

Inbox Lens  (0) 2026.09.18
4. 버그를 많이 찾는 QA보다는  (0) 2026.09.17
3. AI가 테스트를 대신하기 시작할 때  (0) 2026.09.16
2. 반복 테스트가 지겨운 이유는,  (0) 2026.09.15
1. 오늘 지운 테스트케이스 하나가, 누군가의 주문 실패 하나를 막는다  (0) 2026.09.14