@educa-corp/sdd-framework 0.9.5 → 0.9.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/build.js +11 -1
- package/bin/lint-trace.js +397 -28
- package/bin/self-check.js +183 -12
- package/bin/trace-schema.json +2656 -1981
- package/core/FRAMEWORK_VERSION +1 -1
- package/core/commands/dev-gen-test.md +62 -0
- package/core/commands/generate-code.md +1 -1
- package/core/commands/generate-tech-docs.md +3 -3
- package/core/commands/map-testids.md +88 -11
- package/core/commands/qc-analyze.md +509 -425
- package/core/commands/qc-design-test.md +475 -247
- package/core/commands/qc-plan.md +134 -93
- package/core/commands/qc-review.md +216 -131
- package/core/commands/qc-run-test.md +346 -231
- package/core/commands/validate-traces.md +17 -2
- package/core/rules/workflow.md +40 -0
- package/core/skills/qc/qa-analyst/DOC_GAP.template.md +9 -1
- package/core/skills/qc/qa-designer/shared/duplicate-check-procedure.md +33 -5
- package/core/skills/qc/qa-designer/shared/tc-metadata-format.md +24 -0
- package/core/skills/qc/qa-planner/test-plan.md +7 -0
- package/core/skills/qc/qa-runner/functional/gui-feature.md +1 -1
- package/core/skills/qc/qa-runner/functional/gui-screen.md +1 -1
- package/core/steps/qc-scope.md +67 -11
- package/core/steps/qc-stamp.md +142 -0
- package/core/steps/report-footer.md +13 -5
- package/core/templates/tech-design.template.md +3 -3
- package/docs/01-getting-started/quickstart.md +4 -3
- package/docs/02-concepts/architecture.md +14 -0
- package/docs/02-concepts/glossary.md +8 -0
- package/docs/02-concepts/overview.md +3 -2
- package/docs/02-concepts/pipeline-steps/04-bdd.md +1 -1
- package/docs/02-concepts/pipeline-steps/05-tech-docs.md +21 -5
- package/docs/02-concepts/pipeline-steps/06-code.md +12 -2
- package/docs/02-concepts/pipeline-steps/08-qc-automation.md +60 -12
- package/docs/02-concepts/pipeline-steps/README.md +4 -3
- package/docs/02-concepts/traceability.md +2 -2
- package/docs/03-guides/architect.md +2 -2
- package/docs/03-guides/developer.md +5 -2
- package/docs/03-guides/tester-qa.md +17 -5
- package/docs/04-reference/commands.md +6 -3
- package/docs/04-reference/trace-schema.md +1 -1
- package/docs/explain/07-generate-tech-docs.md +5 -3
- package/docs/explain/08-review-tech-docs.md +15 -3
- package/docs/explain/09-generate-code.md +30 -4
- package/docs/explain/10-review-code.md +1 -1
- package/docs/explain/11-map-testids.md +72 -70
- package/docs/explain/12-dev-gen-test.md +1 -1
- package/docs/explain/15-qc-analyze.md +14 -2
- package/docs/explain/16-qc-plan.md +5 -1
- package/docs/explain/17-qc-design-test.md +26 -3
- package/docs/explain/18-qc-review.md +6 -2
- package/docs/explain/19-qc-run-test.md +29 -6
- package/docs/explain/20-qc-report.md +5 -2
- package/docs/explain/README.md +4 -1
- package/package.json +1 -1
|
@@ -1,17 +1,19 @@
|
|
|
1
|
-
---
|
|
2
|
-
version: 1.0
|
|
3
|
-
updated: 2026-09-04
|
|
4
|
-
ported_from: ai-automation-qc-base
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# /qc-design-test — QC Test-Case Design
|
|
8
|
-
|
|
9
|
-
> Stage 3 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-designer của team QC. Sinh test case Markdown (`.Test.md`) — Python đến sau ở /qc-run-test.
|
|
10
|
-
|
|
11
|
-
## Gate
|
|
12
|
-
|
|
13
|
-
*Checkpoint: **chặn
|
|
14
|
-
|
|
1
|
+
---
|
|
2
|
+
version: 1.0
|
|
3
|
+
updated: 2026-09-04
|
|
4
|
+
ported_from: ai-automation-qc-base
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /qc-design-test — QC Test-Case Design
|
|
8
|
+
|
|
9
|
+
> Stage 3 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-designer của team QC. Sinh test case Markdown (`.Test.md`) — Python đến sau ở /qc-run-test.
|
|
10
|
+
|
|
11
|
+
## Gate
|
|
12
|
+
|
|
13
|
+
*Checkpoint: **chặn CỨNG** — ghi đè `*.Test.md` đã qua cổng HITL `/qc-review` → mất `Status` đã duyệt, `Expected Result` đã sửa theo finding, dấu 🚫 Block vừa gỡ; và ĐÁNH SỐ LẠI `TC_<FEATURE>_NNN` mà `REVIEW_<FEATURE>.md` đang trỏ vào. `--yes` KHÔNG bỏ qua được (gate Bước 3a).*
|
|
14
|
+
|
|
15
|
+
*Mức cứng chỉ áp khi file `.Test.md` **đã tồn tại**. Lần thiết kế đầu không ghi đè gì, đi thẳng. Xem §Chạy lại.*
|
|
16
|
+
|
|
15
17
|
# Gate — Quy trình vào chuẩn cho mọi lệnh
|
|
16
18
|
|
|
17
19
|
Mọi lệnh PHẢI chạy gate này trước khi thực thi phần logic riêng của nó.
|
|
@@ -163,247 +165,473 @@ Mỗi dòng ⚠️/🔴 phải ứng với một trạng thái **context-loader
|
|
|
163
165
|
- "N" → dừng, hỏi người dùng muốn thay đổi gì.
|
|
164
166
|
- Có `--yes` và mức *chặn thường* → coi như "Y", **nhưng vẫn IN khối CHECKPOINT** nếu có cờ
|
|
165
167
|
🔴/⚠️ (không chặn ≠ không báo — người đọc log sau này vẫn cần thấy).
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID. Đọc output của qc-analyze + qc-plan (`REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`) từ `{qc_artifact_dir}` — **cả ba đều ở cấp PRD, lọc theo cột `UC`** để lấy phần của UC này — và file `.feature` của đúng platform đó (với `@trace.scenario` mỗi scenario). Với layer GUI, cũng đọc bảng **Test Selectors** §4.5.6 (block platform) của tech-doc gộp tại `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/{TICKET-ID}-tech-design.md` (nếu có — bảng gộp mọi UC của platform, **lọc theo cột "
|
|
169
|
-
|
|
170
|
-
## Context
|
|
168
|
+
|
|
169
|
+
|
|
170
|
+
*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID. Đọc output của qc-analyze + qc-plan (`REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`) từ `{qc_artifact_dir}` — **cả ba đều ở cấp PRD, lọc theo cột `UC`** để lấy phần của UC này — và file `.feature` của đúng platform đó (với `@trace.scenario` mỗi scenario). Với layer GUI, cũng đọc bảng **Test Selectors** §4.5.6 (block platform) của tech-doc gộp tại `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/{TICKET-ID}-tech-design.md` (nếu có — bảng gộp mọi UC của platform, **lọc theo cột "Serves SC" khớp SC của UC này**) — các test-id ổn định mà QC sẽ định vị theo.*
|
|
171
|
+
|
|
172
|
+
## Context
|
|
171
173
|
**BẮT BUỘC — đọc `.agent/steps/context-loader.md` và thực thi TOÀN BỘ quy trình trong đó**,
|
|
172
174
|
rồi mới tiếp tục phần bên dưới.
|
|
173
175
|
|
|
174
176
|
Bỏ qua bước này thì `{paths.*}`, `{tech_stack.*}`, `{conventions.*}`, guardrail từ
|
|
175
177
|
`project-lessons`, và routing service (chế độ umbrella) đều **chưa được phân giải** — mọi
|
|
176
|
-
placeholder bên dưới sẽ rỗng và lệnh sẽ đọc/ghi sai chỗ.
|
|
177
|
-
|
|
178
|
-
## Phạm vi QC
|
|
179
|
-
|
|
178
|
+
placeholder bên dưới sẽ rỗng và lệnh sẽ đọc/ghi sai chỗ.
|
|
179
|
+
|
|
180
|
+
## Phạm vi QC
|
|
181
|
+
|
|
180
182
|
**BẮT BUỘC — đọc `.agent/steps/qc-scope.md` và thực thi TOÀN BỘ quy trình trong đó**,
|
|
181
183
|
rồi mới tiếp tục phần bên dưới.
|
|
182
184
|
|
|
183
185
|
Nó chốt bốn thứ mà mọi trạm QC đều cần: `TICKET-ID` · `active_platform` ·
|
|
184
|
-
`qc_artifact_dir` · `uc_list` (kèm trạng thái BDD từng UC, và cờ `--
|
|
186
|
+
`qc_artifact_dir` · `uc_list` (kèm trạng thái BDD từng UC, và cờ `--force`).
|
|
185
187
|
Bỏ qua thì artifact QC ghi vào **sai thư mục** và `qc_status` ghi vào **sai sổ trace** —
|
|
186
|
-
cả hai đều xảy ra trong im lặng, không có bước nào phía sau bắt được.
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
257
|
-
|
|
258
|
-
|
|
259
|
-
|
|
260
|
-
|
|
261
|
-
|
|
262
|
-
|
|
263
|
-
|
|
|
264
|
-
|
|
265
|
-
|
|
|
266
|
-
|
|
|
267
|
-
|
|
|
268
|
-
|
|
|
269
|
-
|
|
270
|
-
|
|
271
|
-
**
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
|
|
279
|
-
|
|
280
|
-
|
|
281
|
-
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
|
|
292
|
-
|
|
293
|
-
|
|
294
|
-
|
|
295
|
-
|
|
296
|
-
|
|
297
|
-
|
|
298
|
-
|
|
299
|
-
|
|
300
|
-
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
|
|
305
|
-
|
|
306
|
-
|
|
307
|
-
|
|
308
|
-
-
|
|
309
|
-
|
|
310
|
-
|
|
311
|
-
|
|
312
|
-
|
|
313
|
-
|
|
314
|
-
|
|
315
|
-
|
|
316
|
-
|
|
317
|
-
|
|
318
|
-
|
|
319
|
-
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
|
|
323
|
-
|
|
324
|
-
|
|
325
|
-
|
|
326
|
-
|
|
327
|
-
|
|
328
|
-
|
|
329
|
-
|
|
330
|
-
|
|
331
|
-
|
|
332
|
-
|
|
333
|
-
|
|
|
334
|
-
|
|
335
|
-
|
|
336
|
-
|
|
337
|
-
|
|
338
|
-
|
|
339
|
-
|
|
340
|
-
|
|
341
|
-
|
|
342
|
-
|
|
343
|
-
|
|
344
|
-
|
|
345
|
-
-
|
|
346
|
-
|
|
347
|
-
|
|
348
|
-
|
|
349
|
-
|
|
350
|
-
|
|
351
|
-
|
|
352
|
-
|
|
353
|
-
|
|
354
|
-
|
|
355
|
-
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
|
|
360
|
-
|
|
361
|
-
|
|
362
|
-
|
|
363
|
-
|
|
364
|
-
|
|
365
|
-
|
|
366
|
-
|
|
367
|
-
|
|
368
|
-
|
|
369
|
-
TC
|
|
370
|
-
|
|
371
|
-
|
|
372
|
-
|
|
373
|
-
|
|
374
|
-
|
|
375
|
-
|
|
376
|
-
|
|
377
|
-
|
|
378
|
-
|
|
379
|
-
|
|
380
|
-
|
|
381
|
-
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
|
|
388
|
-
|
|
389
|
-
|
|
390
|
-
|
|
391
|
-
|
|
392
|
-
|
|
188
|
+
cả hai đều xảy ra trong im lặng, không có bước nào phía sau bắt được.
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Stamp phiên bản nguồn
|
|
193
|
+
|
|
194
|
+
**BẮT BUỘC — đọc `.agent/steps/qc-stamp.md` và thực thi phần áp cho lệnh này**,
|
|
195
|
+
rồi mới tiếp tục phần bên dưới.
|
|
196
|
+
|
|
197
|
+
Nó có **hai vế**: §1 **ghi** khối `Nguồn & phiên bản` vào artifact lệnh này sinh ra ·
|
|
198
|
+
§2 **so** stamp của artifact lệnh này ĐỌC với version hiện tại của spec.
|
|
199
|
+
Bỏ vế ghi thì trạm sau không có gì để so; bỏ vế so thì stamp thành một con số không ai
|
|
200
|
+
đọc — và một bộ TC lỗi thời sẽ chạy xanh rồi ghi `pass` **hợp lệ theo mọi phép kiểm**.
|
|
201
|
+
|
|
202
|
+
> **Trạm này vẫn gọi theo TỪNG UC** *(B11)* — thiết kế và chạy test **thật sự** làm tăng dần
|
|
203
|
+
> theo UC, nên giữ khả năng làm UC1 khi UC3 chưa xong là đúng. Chỉ **chỗ đọc/ghi** đổi: mọi
|
|
204
|
+
> artifact nằm chung ở `{qc_artifact_dir}` cấp PRD, không còn một thư mục mỗi UC.
|
|
205
|
+
>
|
|
206
|
+
> Nên `DOC_GAP.md` / `TEST_PLAN.md` đọc được ở đây phủ **cả PRD**: **lọc theo cột `UC`** để lấy
|
|
207
|
+
> phần của UC đang làm. Đừng coi toàn bộ bảng gap là của UC này — sẽ chặn oan.
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
## Guard — tiền đề *(chạy NGAY SAU §Phạm vi QC, TRƯỚC mọi việc khác của lệnh)*
|
|
212
|
+
|
|
213
|
+
Trạm này là **trạm 3**. Nó **tiêu thụ** output của trạm 1 và trạm 2 — không tự sinh lại được.
|
|
214
|
+
Kiểm sự tồn tại của cả ba file dưới `{qc_artifact_dir}`:
|
|
215
|
+
|
|
216
|
+
| File | Do lệnh nào sinh | Trạm này dùng để |
|
|
217
|
+
|---|---|---|
|
|
218
|
+
| `REQUIREMENT_ANALYSIS.md` | `/qc-analyze` | neo `BR-xx`/`AC-xx` cho trường `Trace:` của mỗi TC |
|
|
219
|
+
| `DOC_GAP.md` | `/qc-analyze` | gắn `🚫 Block` cho TC bị gap chặn |
|
|
220
|
+
| `TEST_PLAN.md` | `/qc-plan` | độ sâu theo rủi ro (P0/P1) · layer trong scope · entry criteria |
|
|
221
|
+
|
|
222
|
+
**Thiếu bất kỳ file nào → DỪNG.** Không hỏi Y/N, không cảnh báo rồi đi tiếp:
|
|
223
|
+
|
|
224
|
+
```
|
|
225
|
+
❌ {TICKET-ID} ({active_platform}): thiếu đầu vào của trạm 3.
|
|
226
|
+
Không có: {danh sách file thiếu}
|
|
227
|
+
Chạy trước: /qc-analyze {TICKET-ID} {active_platform}
|
|
228
|
+
rồi: /qc-plan {TICKET-ID} {active_platform}
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
**Đủ cả ba → im lặng, đi tiếp.** Guard này là **điều kiện vào cửa**, không phải phép đo: "đủ file"
|
|
232
|
+
không phải một phát hiện, nên không in dòng nào. *(Khác `Guard BR-tag` và `Guard SC coverage` —
|
|
233
|
+
hai cái đó là phép ĐẾM, con số của chúng có giá trị ngay cả khi sạch, nên chúng luôn in.)*
|
|
234
|
+
|
|
235
|
+
> **Vì sao DỪNG chứ không cảnh báo rồi chạy.** Guard duy nhất còn lại của trạm này —
|
|
236
|
+
> `Guard SC coverage` — đối chiếu TC với `.feature`, mà `.feature` ở spec repo thì **luôn có mặt**,
|
|
237
|
+
> không mất theo khi trạm 1–2 chưa chạy. Nên nó vẫn in `khớp K/K` và lần chạy thiếu đầu vào
|
|
238
|
+
> **không phân biệt được** với một lần chạy đúng.
|
|
239
|
+
>
|
|
240
|
+
> Thiếu `DOC_GAP.md` là ca đắt nhất: TC bị gap chặn **trông y hệt** TC bình thường (không có dấu
|
|
241
|
+
> `🚫 Block` nào), nên `/qc-run-test` chạy nó, thấy đỏ, và `/qc-report` phân loại thành *product-gap*
|
|
242
|
+
> rồi in một `/report-bug` sẵn-chạy. Lỗi đi **ra khỏi đội QC** thành bug gửi PO — cho một hành vi
|
|
243
|
+
> mà spec chưa bao giờ định nghĩa. Đây là **báo cáo sai**, cùng loại với việc giữ một `pass` đã hết
|
|
244
|
+
> hiệu lực (`rules/workflow.md` §*"Làm mất hiệu lực ≠ ghi đè"*).
|
|
245
|
+
>
|
|
246
|
+
> **Vì sao DỪNG chứ không hỏi Y/N.** Một cổng chỉ chặn được khi có người ngồi đó thì ở chế độ
|
|
247
|
+
> headless nó không phải cổng, nó là **treo** — cùng bài học với `steps/qc-scope.md` §2.
|
|
248
|
+
>
|
|
249
|
+
> **Vì sao `--yes` KHÔNG bỏ qua được.** `--yes` nghĩa *"tôi không ngồi đây để trả lời"*, không phải
|
|
250
|
+
> *"tôi chấp nhận thiết kế test không có phân tích gap"*. Gộp hai nghĩa là để một lần chạy headless
|
|
251
|
+
> âm thầm sinh ra một bộ test case thiếu mọi dấu chặn.
|
|
252
|
+
>
|
|
253
|
+
> **Vì sao cả ba file đều bắt buộc, không miễn trừ `TEST_PLAN.md`.** Không có luồng hợp lệ nào có
|
|
254
|
+
> file 1–2 mà thiếu file 3: `Next` của `/qc-analyze` chính là `/qc-plan`. Miễn trừ nó là mở một
|
|
255
|
+
> đường tắt không ai xin.
|
|
256
|
+
>
|
|
257
|
+
> **Chỉ kiểm SỰ TỒN TẠI, không kiểm nội dung hay độ tươi.** Ba file này có còn khớp spec hiện tại
|
|
258
|
+
> không là một câu hỏi khác, và nó cần một cơ chế khác (đóng dấu version nguồn). Trộn hai việc vào
|
|
259
|
+
> một guard thì guard này không bao giờ landing được.
|
|
260
|
+
|
|
261
|
+
---
|
|
262
|
+
|
|
263
|
+
## Cờ — chọn tầng nào, tách mịn đến đâu
|
|
264
|
+
|
|
265
|
+
| Cờ | Ghi file | Nhóm |
|
|
266
|
+
|---|---|---|
|
|
267
|
+
| *(không cờ)* | `TC_<FEATURE>.Test.md` | 1 GUI · 2 Validation · 3 Functional · 4 Integration (qua UI) · 5 NFR · 6 E2E |
|
|
268
|
+
| `--api` | `TC_<FEATURE>_API.Test.md` | 1 Endpoint · 2 Integration API/DB/Kafka |
|
|
269
|
+
| `--all` | **cả hai file** | như trên, hai file riêng biệt |
|
|
270
|
+
| `--atomic-max` | — | bật chế độ tách tối đa (xem dưới) |
|
|
271
|
+
|
|
272
|
+
**Câu hỏi phân file:** *"TC này verify được mà **không cần UI** không?"* → **có** = file API ·
|
|
273
|
+
**không** = file giao diện. Đây đúng là Bước 2 của
|
|
274
|
+
`{paths.qc_skills_dir}/qa-designer/shared/skill-decision-tree.md`.
|
|
275
|
+
|
|
276
|
+
> **Vì sao hai file riêng chứ không một file rồi ghi từng nhóm** *(B12)*. `--api` chạy sau khi
|
|
277
|
+
> file giao diện đã tồn tại là chuyện thường. Nếu chung một file, lần chạy `--api` phải **giữ
|
|
278
|
+
> nguyên** năm nhóm kia — mà viết-lại-cả-file là đúng thứ agent hay làm. Hai file thì hai chế
|
|
279
|
+
> độ **không bao giờ chạm nhau**, và không cần tin vào việc agent nhớ giữ phần cũ.
|
|
280
|
+
|
|
281
|
+
### `--atomic-max` — tách tới mức nhỏ nhất
|
|
282
|
+
|
|
283
|
+
Mặc định đã là ATOMIC (mỗi TC đúng một kết cục), nhưng **cho phép** bullet compound khi cả hai
|
|
284
|
+
vế nói về **cùng một** kết cục — ví dụ *"form hiển thị đủ 3 trường"* vẫn là 1 TC.
|
|
285
|
+
|
|
286
|
+
`--atomic-max` **nổ danh sách completeness thành từng thành phần**: thẻ hiển thị đủ 5 thông tin
|
|
287
|
+
→ **5 TC**. Ở đội QC, một tính năng đi từ 82 lên 130 TC.
|
|
288
|
+
|
|
289
|
+
**⛔ Thủ tục bắt buộc TRƯỚC khi ghi** *(theo `shared/precision-rules.md` §2.1)*:
|
|
290
|
+
|
|
291
|
+
1. **Chốt ranh giới completeness** — hai mức có quy mô rất khác nhau:
|
|
292
|
+
| Giá trị | Nghĩa |
|
|
293
|
+
|---|---|
|
|
294
|
+
| `--atomic-max=keep-completeness` | giữ danh sách completeness là 1 TC (~95 TC ở ví dụ thật) |
|
|
295
|
+
| `--atomic-max=explode` | nổ từng thành phần (~130 TC) |
|
|
296
|
+
|
|
297
|
+
Không nêu giá trị → **HỎI** trước khi ghi, vì đây là quyết định quy mô của người chủ, không
|
|
298
|
+
phải của agent. **Có `--yes`:** không hỏi — **DỪNG** với lỗi rõ ràng:
|
|
299
|
+
```
|
|
300
|
+
❌ --atomic-max cần nêu ranh giới ở chế độ headless (quy mô chênh ~35%).
|
|
301
|
+
Chạy: /qc-design-test {UC-ID} --atomic-max=explode --yes
|
|
302
|
+
hoặc --atomic-max=keep-completeness --yes
|
|
303
|
+
```
|
|
304
|
+
*(Một cổng chỉ chặn được khi có người ngồi đó thì ở chế độ headless nó không phải cổng, nó
|
|
305
|
+
là treo — cùng bài học với `steps/qc-scope.md` §2.)*
|
|
306
|
+
|
|
307
|
+
2. **Dựng bản đồ tách trước khi ghi** — mỗi TC cha tách ra mấy mảnh. Đừng để agent con tự suy
|
|
308
|
+
trong lúc ghi; đó là chỗ sinh ra TC cắt cụt.
|
|
309
|
+
3. **GIỮ 1 TC** cho bốn loại này kể cả ở chế độ tối đa: *predicate đa-điều-kiện định-nghĩa-một-
|
|
310
|
+
khái-niệm* · *ngưỡng* (`≥44pt`, `WCAG AA ≥4.5:1`) · *exclusivity* chọn-một · *qualifier*.
|
|
311
|
+
4. **Verify bằng DIFF, không tin lời đếm của agent** — ID liên tục · mỗi Expected 1 bullet ·
|
|
312
|
+
0 ký tự `|` · Trace matrix không còn ID chết · P0/P1 khớp tag.
|
|
313
|
+
|
|
314
|
+
---
|
|
315
|
+
|
|
316
|
+
## Role
|
|
317
|
+
|
|
318
|
+
Bạn là **QC Designer** — stage 3. Sinh/bảo trì các file test-case Markdown
|
|
319
|
+
(`.Test.md`) từ requirement đã phân tích + plan. Output feed vào qc-run-test (Python) và
|
|
320
|
+
qc-review. Bạn **không** viết Python.
|
|
321
|
+
|
|
322
|
+
## Skills (`{paths.qc_skills_dir}/qa-designer/`)
|
|
323
|
+
|
|
324
|
+
**Luật dùng chung — nạp theo tầng, không nạp hết mỗi lần:**
|
|
325
|
+
|
|
326
|
+
| Khi nào | Nạp |
|
|
327
|
+
|---|---|
|
|
328
|
+
| **Luôn** | `shared/tc-metadata-format.md` — khuôn TC · luật ATOMIC · phân nhóm · hai file `.Test.md` · Trace · `🚫 Block` · `Test-ID attribute` |
|
|
329
|
+
| **Luôn** | `shared/precision-rules.md` — cấm 9 cụm mơ hồ · đơn vị theo domain · toán tử · BVA 3-hay-4 giá trị · phủ đủ ô decision table · 3 mức teardown |
|
|
330
|
+
| **Luôn** | `shared/action-keywords-glossary.md` — một hành động một từ (Click/Tap/Enter/Select…) |
|
|
331
|
+
| **Luôn** | `shared/implicit-scenarios.md` — 7 tình huống bắt buộc nghĩ tới, áp cho mọi nhóm |
|
|
332
|
+
| Đầu phiên, một lần | `shared/read-doc-gap-inputs.md` — đọc **đủ** mọi file trong bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md`, không chỉ đọc bản tóm tắt gap |
|
|
333
|
+
| Không chắc chọn tầng nào | `shared/skill-decision-tree.md` — cây quyết định UI / Integration-GUI / E2E / Integration |
|
|
334
|
+
| Thêm TC vào file đã có | `shared/duplicate-check-procedure.md` — grep trước khi viết; và **trùng chéo UC** giờ mới thực sự xảy ra vì mọi UC dùng chung một thư mục |
|
|
335
|
+
| `--api` / `--all` | `api/endpoint.md` · `api/auth-chain.md` · `api/http-status-codes.md` · `api/common-headers.md` · `api/crud-sequence.md` · `api/auth-sequence.md` |
|
|
336
|
+
|
|
337
|
+
**Rồi chọn tầng, nạp MỘT file:**
|
|
338
|
+
|
|
339
|
+
| Layer | File | Ghi vào |
|
|
340
|
+
|---|---|---|
|
|
341
|
+
| 1 màn hình | `functional/gui-screen.md` | file giao diện |
|
|
342
|
+
| Feature đa-màn | `functional/gui-feature.md` | file giao diện |
|
|
343
|
+
| API endpoint | `functional/api.md` | **file API** |
|
|
344
|
+
| Integration qua UI | `integration/gui.md` | file giao diện |
|
|
345
|
+
| Integration API/DB/Kafka | `integration/{api,db,kafka}.md` | **file API** |
|
|
346
|
+
| End-to-end journey | `e2e/journey.md` | file giao diện |
|
|
347
|
+
| Non-functional | `non-functional.md` | theo câu hỏi phân file |
|
|
348
|
+
| Exploratory | `exploratory/{charter,explore-to-functional}.md` | file giao diện |
|
|
349
|
+
|
|
350
|
+
## Conventions
|
|
351
|
+
|
|
352
|
+
*Khuôn TC, luật ATOMIC, phân nhóm, không-dùng-bảng, Trace, `🚫 Block`, `Test-ID attribute` —
|
|
353
|
+
đều ở `shared/tc-metadata-format.md`. **Đừng lặp lại ở đây.** Dưới đây chỉ là thứ riêng của trạm:*
|
|
354
|
+
|
|
355
|
+
- Markdown-first; đừng design khi requirement chưa rõ — đẩy ngược về qc-plan/qc-analyze.
|
|
356
|
+
- **Tham chiếu test-id, không phải gợi ý hình ảnh.** Với mỗi step GUI tác động lên một element, trích test-id ổn định từ bảng §4.5.6 của tech-doc gộp (vd "click `ft001-login-submit-btn`") để qc-run-test dựng locator từ contract. Nếu một element có action không có test-id trong §4.5.6, ghi chú lại (qc-run-test sẽ fallback về locator role/text chậm hơn).
|
|
357
|
+
- **Đọc `@trace.testid_attr` từ header tech-doc gộp** (do `/map-testids` ghi) và ghi lại một
|
|
358
|
+
dòng `Test-ID attribute: {attr}` ở metadata đầu file `.Test.md`. §4.5.6 chỉ cho **giá trị**
|
|
359
|
+
test-id; `@trace.testid_attr` là **tên thuộc tính** chứa chúng — `/qc-run-test` cần nó để cấu
|
|
360
|
+
hình locator, `/qc-review` cần nó để biết selector trong script có đúng contract không.
|
|
361
|
+
Không đọc được `@trace.testid_attr` → ghi
|
|
362
|
+
`Test-ID attribute: — (thiếu @trace.testid_attr, chạy /map-testids)`; **đừng bỏ trống, đừng
|
|
363
|
+
tự đoán theo platform** — đoán sai thì mọi locator trượt 100%, vì một lý do không liên quan
|
|
364
|
+
gì tới thứ đang được test. *(Dạng dòng metadata: `shared/tc-metadata-format.md`.)*
|
|
365
|
+
- Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md) — lý do`.
|
|
366
|
+
Chặn theo **UC ở cột `UC` của hàng gap đó**, không chặn cả PRD.
|
|
367
|
+
|
|
368
|
+
## Trace mapping (bắt buộc)
|
|
369
|
+
|
|
370
|
+
Ngoài trace `BR-xx`, mỗi TC ghi scenario framework mà nó verify — **dạng trường danh sách,
|
|
371
|
+
không phải cột bảng** (file TC không có ký tự `|`):
|
|
372
|
+
|
|
373
|
+
```
|
|
374
|
+
- **@trace.verifies:** {UC-ID}-SC{N}
|
|
375
|
+
```
|
|
376
|
+
|
|
377
|
+
Lấy từ `@trace.scenario` của `.feature`. Một SC map được nhiều TC. Đây là **join key** cho phép
|
|
378
|
+
qc-run-test ghi `qc_status` theo từng scenario vào sổ trace — **thiếu nó thì test vẫn chạy,
|
|
379
|
+
vẫn pass/fail, nhưng kết quả không vào được sổ và không ai biết nó phủ kịch bản nào.**
|
|
380
|
+
|
|
381
|
+
Cuối file: **Trace matrix** (BR ↔ TC ↔ SC) + **danh sách TC bị block** — cả hai dạng danh sách.
|
|
382
|
+
|
|
383
|
+
## Guard — SC coverage *(phép ĐẾM cơ học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
|
|
384
|
+
|
|
385
|
+
Dòng `Trace:` ở report cuối đã đòi con số `{K}/{total}` từ trước. Guard này là **phép tính sinh
|
|
386
|
+
ra con số đó**, và là **hệ quả khi `K < total`** — trước đây có số mà không có phép tính nào
|
|
387
|
+
đứng sau, nên nó là ước lượng, và `K < total` không dẫn tới việc gì.
|
|
388
|
+
|
|
389
|
+
### Ba bước
|
|
390
|
+
|
|
391
|
+
1. **Thu SC** — mọi `@trace.scenario` trong `.feature` của **UC đang chạy** (`{UC-ID}`, đúng
|
|
392
|
+
`active_platform`) — **KHÔNG phải `uc_list`.**
|
|
393
|
+
|
|
394
|
+
`uc_list` là mọi UC approved của **cả PRD**; trạm này chạy **per-UC** (§Phạm vi QC), nên lấy
|
|
395
|
+
`uc_list` làm mẫu số là ép viết TC cho UC **không ai yêu cầu** — bằng dữ liệu đã lọc bỏ phần
|
|
396
|
+
của chúng ở Gate (*"lọc theo cột `UC` để lấy phần của UC này"*), tức là **viết mù**.
|
|
397
|
+
|
|
398
|
+
*Trạm 1 `/qc-analyze` dùng `uc_list` là **đúng** — nó cấp PRD, và mâu thuẫn chéo UC chỉ lộ ra
|
|
399
|
+
khi đọc cùng lúc. **Đừng copy mẫu số giữa hai trạm khác tầng.** Phép kiểm một câu: mẫu số của
|
|
400
|
+
một guard phải khớp **phạm vi mà lệnh đó được gọi**.*
|
|
401
|
+
|
|
402
|
+
**Không cần lọc `⏸ chưa xét` ở đây nữa:** `qc-scope` §4b đã chặn UC target chưa approved từ
|
|
403
|
+
trước khi tới bước này. Chạy được tới đây nghĩa là target hoặc đã `approved`, hoặc người dùng
|
|
404
|
+
đã nêu `--force` tường minh (và artifact đang mang dấu *"dựa trên BDD nháp"*).
|
|
405
|
+
2. **Thu V** — mọi `@trace.verifies` trong **MỌI** `*.Test.md` dưới `{qc_artifact_dir}test-cases/`
|
|
406
|
+
— **không chỉ file vừa ghi** — rồi lọc lấy giá trị bắt đầu bằng `{UC-ID}-SC`.
|
|
407
|
+
|
|
408
|
+
*Thư mục `test-cases/` dùng chung cho **cả PRD** nên phải lọc theo UC. Và lệnh này có **ba chế
|
|
409
|
+
độ ghi** (§Cờ), hai trong ba chỉ ghi **một nửa**: `--api` chạy sau khi file giao diện đã tồn tại
|
|
410
|
+
là **chuyện thường** (§B12 ngay dưới bảng Cờ). Chỉ đếm file "vừa ghi" thì lần chạy `--api` thấy
|
|
411
|
+
độ phủ ≈ 0, rồi luật "viết bù TC ngay" **nhân bản toàn bộ TC giao diện vào file API** — phá đúng
|
|
412
|
+
ranh giới hai-file mà §B12 dựng lên.*
|
|
413
|
+
|
|
414
|
+
**Tiền tố lọc phải gồm cả `-SC`.** `{UC-ID}-SC` chứ **không** phải `{UC-ID}`:
|
|
415
|
+
`FT-001-UC1-SC` không khớp `FT-001-UC11-SC3`, còn `FT-001-UC1` thì có. Một PRD tới UC thứ 11
|
|
416
|
+
là đủ để phép lọc sai **trong im lặng**.
|
|
417
|
+
|
|
418
|
+
*Quét cả thư mục chứ không đoán theo tên file: tên file mang `<FEATURE>`, **không** mang UC —
|
|
419
|
+
`@trace.verifies` là chỗ duy nhất nói TC thuộc UC nào (§Output).*
|
|
420
|
+
3. **Đếm** — mỗi SC ∈ tập ở bước 1 phải có **≥ 1** TC trỏ tới.
|
|
421
|
+
|
|
422
|
+
### Xử lý
|
|
423
|
+
|
|
424
|
+
| Kết quả | Làm gì |
|
|
425
|
+
|---|---|
|
|
426
|
+
| Mọi SC đều có ≥1 TC | in `Guard SC coverage: khớp {K}/{K}` |
|
|
427
|
+
| Có SC chưa phủ | **viết bù TC ngay** — vào file đúng theo §Câu hỏi phân file, xem luật định tuyến dưới đây — rồi in `⚠️ Guard SC coverage: {K}/{total} — đã bù {m} SC: {danh sách}` |
|
|
428
|
+
|
|
429
|
+
**TC bù đi vào file nào — theo §Câu hỏi phân file, KHÔNG mặc định vào file của chế độ đang chạy.**
|
|
430
|
+
|
|
431
|
+
Hỏi từng SC chưa phủ: *"TC cho SC này verify được mà **không cần UI** không?"*
|
|
432
|
+
|
|
433
|
+
| Trả lời | Chế độ đang chạy | Làm gì |
|
|
434
|
+
|---|---|---|
|
|
435
|
+
| **Có** (không cần UI) | `--api` hoặc `--all` | bù vào **file API** — xong |
|
|
436
|
+
| **Không** (cần UI) | *(không cờ)* hoặc `--all` | bù vào **file giao diện** — xong |
|
|
437
|
+
| **Không** (cần UI) | **`--api`** | **KHÔNG bù vào file API.** SC vẫn tính là **chưa phủ**; in thêm dòng chỉ đường (dưới) |
|
|
438
|
+
|
|
439
|
+
```
|
|
440
|
+
⚠️ {n} SC cần UI, chưa có TC ở file giao diện — KHÔNG bù vào file API (§Câu hỏi phân file).
|
|
441
|
+
Chạy: /qc-design-test {UC-ID} ← không cờ, để bù đúng chỗ
|
|
442
|
+
SC: {danh sách}
|
|
443
|
+
```
|
|
444
|
+
|
|
445
|
+
> **Đây KHÔNG phải "bỏ trống có lý do".** Phân biệt bằng một câu: đường thoát làm SC **được tính là
|
|
446
|
+
> đã phủ**; luật này để SC **vẫn nằm trong số chưa phủ** — `{K}/{total}` không đổi, dòng ⚠️ vẫn in,
|
|
447
|
+
> guard vẫn chưa sạch. Nó chỉ đổi **chỗ ghi TC**, không đổi **phép đếm**.
|
|
448
|
+
>
|
|
449
|
+
> Và nó **không** cho agent một câu-lý-do-cho-qua: điều kiện là một phép so cơ học (*"cần UI không?"*
|
|
450
|
+
> — đúng Bước 2 của `shared/skill-decision-tree.md`), không phải một nhận định tự do. Ghi *"SC này
|
|
451
|
+
> phức tạp"*, *"tương tự SC2"* thì **không** rơi vào ô nào của bảng trên.
|
|
452
|
+
>
|
|
453
|
+
> **Vì sao không cứ bù vào file đang mở cho gọn.** File API được `/qc-run-test` đọc bằng lane API.
|
|
454
|
+
> Một TC cần UI nằm ở đó **không chạy nổi** — và nó sẽ đỏ dưới dạng *script-bug* hoặc *product-gap*,
|
|
455
|
+
> không ai truy ngược về một quyết định ghi file ở phase thiết kế.
|
|
456
|
+
|
|
457
|
+
**Không có đường "bỏ trống có lý do".** Đây là chỗ dễ làm sai nhất, và quy ước ở §Conventions
|
|
458
|
+
đã trả lời: *"Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md)`"*.
|
|
459
|
+
Nghĩa là **gap không phải cái cớ để không viết TC** — nó là thứ được **ghi vào TC**. SC bị chặn
|
|
460
|
+
vẫn có TC, vẫn được đếm là đã phủ.
|
|
461
|
+
|
|
462
|
+
Nên chỉ còn đúng hai trạng thái, và cả hai đều không cho phép bỏ trống:
|
|
463
|
+
|
|
464
|
+
- SC **của UC đang chạy** → phải có TC (bị gap chặn thì TC mang dấu `🚫 Block`). Đây là **toàn bộ**
|
|
465
|
+
mẫu số — bước 1 không lấy SC của UC nào khác.
|
|
466
|
+
- SC **của UC khác** → không thuộc lần chạy này, không tính vào mẫu số. *(Muốn phủ chúng thì chạy
|
|
467
|
+
`/qc-design-test` cho UC đó — đừng viết TC của chúng ở đây.)*
|
|
468
|
+
|
|
469
|
+
Nếu bạn thấy một SC "không thể viết TC" mà không thuộc hai loại trên, thì **đó là một gap** —
|
|
470
|
+
mở gap trong `DOC_GAP.md`, viết TC kèm `🚫 Block` trỏ tới nó. Đừng viết một câu lý do rồi đi
|
|
471
|
+
tiếp: guard viết lỏng thì lần sau sẽ có một câu lý do cho qua, và phép đếm mất nghĩa.
|
|
472
|
+
|
|
473
|
+
*(Ca "SC cần UI mà đang chạy `--api`" **không** phải trạng thái thứ ba: SC đó vẫn ở nhóm thứ nhất,
|
|
474
|
+
vẫn tính vào mẫu số, vẫn chưa phủ. Chỉ **chỗ ghi TC** bị hoãn — xem luật định tuyến ở §Xử lý.)*
|
|
475
|
+
|
|
476
|
+
**In dòng `Guard SC coverage:` kể cả khi sạch** — guard im lặng khi sạch là guard không ai biết
|
|
477
|
+
nó tồn tại, và không ai phát hiện được khi nó chết.
|
|
478
|
+
|
|
479
|
+
> **Vì sao đếm ở đây mà không đợi báo cáo cuối.** `/qc-report` **sẽ** tính **design coverage** bằng
|
|
480
|
+
> **đúng phép đếm này** — **Đợt 3, CHƯA TRIỂN KHAI** (`docs/plans/qc-surgery/01-checklist.md`, phụ
|
|
481
|
+
> thuộc cứng vào `d2-b2`). Khác nhau ở thời điểm: guard đếm **lúc thiết kế** — còn kịp viết bù; báo
|
|
482
|
+
> cáo đếm **ở cuối** — chỉ còn kịp báo. Phát hiện "design coverage 68%" ở phút cuối là lúc không còn
|
|
483
|
+
> thời gian viết bù 32%.
|
|
484
|
+
>
|
|
485
|
+
> **Tới khi Đợt 3 có, guard này là lớp đếm DUY NHẤT — đừng dựa vào một lớp thứ hai chưa tồn tại.**
|
|
486
|
+
> *(Bản trước viết "sẽ tính" ở thì hiện tại, không nêu trạng thái. Một lời hứa không có trạng thái sẽ
|
|
487
|
+
> được đọc như một sự thật — và tệ nhất là khi nó được dùng để biện minh cho việc không đếm ở chỗ khác.)*
|
|
488
|
+
>
|
|
489
|
+
> **Vì sao "chưa có TC" khác "có TC nhưng chưa chạy".** Hai trạng thái này dẫn tới hai việc khác
|
|
490
|
+
> nhau hoàn toàn — viết test, so với chạy test. Nhưng nhìn vào sổ trace thì giống nhau: cả hai
|
|
491
|
+
> đều là `qc_status = not_run`. Guard này là chỗ duy nhất phân biệt được.
|
|
492
|
+
|
|
493
|
+
## Chạy lại — `.Test.md` đã tồn tại *(GIỮ, không sinh lại từ trắng)*
|
|
494
|
+
|
|
495
|
+
File `.Test.md` đi qua **cổng HITL `/qc-review`**. Bốn thứ trong đó **không sinh lại được**:
|
|
496
|
+
|
|
497
|
+
| Mất gì | Vì sao |
|
|
498
|
+
|---|---|
|
|
499
|
+
| `Status` đổi sau review | **kết luận của người**, không suy từ spec |
|
|
500
|
+
| `Expected Result` sửa theo finding | finding nằm ở `REVIEW_<FEATURE>.md` — **lệnh này không đọc file đó** |
|
|
501
|
+
| Dấu `🚫 Block` vừa gỡ | phụ thuộc ô `Câu trả lời` của `DOC_GAP.md` (xem §Guard vòng đời 🚫 Block) |
|
|
502
|
+
| Đánh số `TC_<FEATURE>_NNN` | **`REVIEW_<FEATURE>.md` đang trỏ vào các số đó**, và nó nằm cùng thư mục |
|
|
503
|
+
|
|
504
|
+
**Đọc file cũ TRƯỚC khi ghi.** Với mỗi TC:
|
|
505
|
+
|
|
506
|
+
| Tình huống | Xử lý |
|
|
507
|
+
|---|---|
|
|
508
|
+
| TC cũ, spec **không đổi** | **Giữ nguyên** — số · `Status` · `Expected Result` đã sửa |
|
|
509
|
+
| TC cũ, spec **đổi** | Cập nhật **nội dung**; giữ **số** và `Status`, thêm ⚠️ để `/qc-review` soát lại |
|
|
510
|
+
| TC **mới** | Cấp số **tiếp theo** — không dồn, không tái dùng |
|
|
511
|
+
| TC không còn ứng với SC nào | **KHÔNG xoá** → `Status: Obsolete`, ghi lý do |
|
|
512
|
+
|
|
513
|
+
> **`Obsolete` chứ không xoá** — cùng luật `Stale` của `/qc-analyze` §Chạy lại: `REVIEW_<FEATURE>.md`
|
|
514
|
+
> đang trỏ vào số đó, xoá hàng là biến biên bản soát thành liên kết chết.
|
|
515
|
+
>
|
|
516
|
+
> **§duplicate-check KHÔNG phải lưới cho ca này.** Nó chống **viết trùng** (*"grep trước khi viết"*),
|
|
517
|
+
> không chống **ghi đè**. Hai chuyện khác nhau, và tên nghe giống nhau đủ để tưởng đã có người lo.
|
|
518
|
+
|
|
519
|
+
### Lập lại từ trắng — phải nói ra
|
|
520
|
+
|
|
521
|
+
```
|
|
522
|
+
❌ {n} file .Test.md đã tồn tại ({k} TC có Status khác Draft — đã qua review).
|
|
523
|
+
Mặc định: GIỮ số + Status + Expected đã sửa, chỉ cập nhật nội dung theo spec mới.
|
|
524
|
+
Muốn bỏ hẳn và thiết kế lại từ trắng: thêm --force
|
|
525
|
+
⚠️ --force sẽ XOÁ {k} kết quả review và làm REVIEW_<FEATURE>.md trỏ sai số TC.
|
|
526
|
+
```
|
|
527
|
+
|
|
528
|
+
---
|
|
529
|
+
|
|
530
|
+
## Guard — vòng đời `🚫 Block` *(phép so cơ học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
|
|
531
|
+
|
|
532
|
+
`🚫 Block` có bước **mở** (§Conventions: TC chạm gap thì mang dấu) và một quy trình **đóng** viết
|
|
533
|
+
sẵn ở `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md` §*Quy trình khi gap được giải
|
|
534
|
+
quyết (Answered)*. Bước đóng đó **chưa lệnh nào gọi** — nên dấu chặn chỉ dán vào, không bao giờ gỡ ra.
|
|
535
|
+
|
|
536
|
+
Một TC mang `🚫 Block` là một TC có **Expected Result dựa trên giả định chưa ai xác nhận**. Nó nằm
|
|
537
|
+
trong thư mục dùng chung, được `Guard SC coverage` đếm là **đã phủ**, và `/qc-run-test` sẽ nhặt lên.
|
|
538
|
+
|
|
539
|
+
> **Vì sao stamp phiên bản (§Stamp phiên bản nguồn) KHÔNG phủ ca này.** Gap chuyển `Open → Answered`
|
|
540
|
+
> là một **ô trong `DOC_GAP.md`** — nó **không bump version nào cả**. Mọi drift detector của framework
|
|
541
|
+
> so **nhãn version**; thay đổi trạng thái nằm *bên trong* một tài liệu đi vòng qua tất cả.
|
|
542
|
+
|
|
543
|
+
### Bốn bước, thuần so chuỗi
|
|
544
|
+
|
|
545
|
+
1. **Thu B** — mọi `GAP-ID` xuất hiện trong dòng `🚫 Block:` của các `*.Test.md` của UC này.
|
|
546
|
+
2. **Thu A** — mọi `GAP-ID` có `Trạng thái = Answered` trong `DOC_GAP.md` (lọc theo cột `UC`).
|
|
547
|
+
3. **So** — `A ∩ B` = gap đã trả lời mà TC vẫn mang dấu chặn.
|
|
548
|
+
4. **Xử lý:**
|
|
549
|
+
|
|
550
|
+
| Kết quả | Làm gì |
|
|
551
|
+
|---|---|
|
|
552
|
+
| `A ∩ B` rỗng | in `Guard 🚫 Block: {n} dấu đang mở, 0 cần gỡ` |
|
|
553
|
+
| Có phần tử, **ô `Câu trả lời` ĐÃ điền** | **GỠ NGAY** theo 4 bước của skill: bỏ dấu `🚫 Block` · cập nhật `Expected Result` theo câu trả lời thật · nếu answer đổi scope thì tách/thêm TC. Rồi in:<br/>`🔓 Guard 🚫 Block: gỡ {k} dấu (gap đã Answered): {danh sách GAP-ID}` |
|
|
554
|
+
| Có phần tử, **ô `Câu trả lời` TRỐNG** | **KHÔNG gỡ.** In:<br/>`⚠️ Guard 🚫 Block: {GAP-ID} = Answered nhưng ô "Câu trả lời" trống — không gỡ được, hỏi lại PO.` |
|
|
555
|
+
|
|
556
|
+
**Guard TỰ SỬA, không chỉ tự báo** — cùng luật `Guard BR-tag` của `/qc-analyze` đã chốt: *"In cảnh
|
|
557
|
+
báo rồi để người đi lấp là thêm một dòng nữa để bỏ qua."*
|
|
558
|
+
|
|
559
|
+
**Nhưng ô `Câu trả lời` trống thì DỪNG, không đoán.** Gỡ dấu chặn mà không có câu trả lời thật là
|
|
560
|
+
**biến một giả định thành sự thật trong im lặng** — và `Expected Result` sai sẽ fail lúc chạy, rồi
|
|
561
|
+
`/qc-report` phân loại *product-gap* và in một `/report-bug`. Lúc đó một lỗ hổng **tài liệu** đã đi ra
|
|
562
|
+
ngoài đội QC thành **phiếu lỗi sản phẩm** gửi PO.
|
|
563
|
+
|
|
564
|
+
**In dòng `Guard 🚫 Block:` kể cả khi sạch** — cùng lý do với hai guard kia.
|
|
565
|
+
|
|
566
|
+
---
|
|
567
|
+
|
|
568
|
+
## UC đang Blocked — nói ra, KHÔNG chặn
|
|
569
|
+
|
|
570
|
+
`TEST_PLAN.md` §5 ghi `Ready`/`Blocked` cho mỗi UC (guard tiền đề đã ép file này phải có). Đọc trạng
|
|
571
|
+
thái của UC đang chạy. **`Blocked` là mức ƯU TIÊN, không phải lệnh cấm** — vẫn thiết kế bình thường,
|
|
572
|
+
chỉ in thêm một dòng ở report:
|
|
573
|
+
|
|
574
|
+
```
|
|
575
|
+
⚠️ {UC-ID} đang Blocked bởi {n} gap 🔴 — TC chạm chúng mang dấu 🚫 Block, chưa chạy được.
|
|
576
|
+
Gỡ chặn: trả lời {danh sách GAP-ID} với PO → chạy lại lệnh này để tự gỡ dấu.
|
|
577
|
+
```
|
|
578
|
+
|
|
579
|
+
> **Vì sao không chặn** *(G66)*. `/qc-analyze` nói *"chưa sẵn sàng"* nghĩa là **chưa sẵn sàng để
|
|
580
|
+
> nghiệm thu**, không phải *"chưa được thiết kế"* — và §Conventions của chính lệnh này đã trả lời:
|
|
581
|
+
> *"TC bị block bởi gap **vẫn viết đủ**"*. Chặn ở đây là giết cơ chế `🚫 Block`, thứ được dựng kỹ tới
|
|
582
|
+
> mức có mã gap mang UC, liên kết ngược `../DOC_GAP.md`, và một dòng riêng trong report.
|
|
583
|
+
>
|
|
584
|
+
> Cái bị chặn là **chạy test**, không phải **viết test**.
|
|
585
|
+
|
|
586
|
+
## Output
|
|
587
|
+
|
|
588
|
+
Ghi dưới `{qc_artifact_dir}test-cases/`
|
|
589
|
+
(= `{paths.qc_dir}/{TICKET-ID}/{active_platform}/test-cases/`) — **một thư mục dùng chung cho cả
|
|
590
|
+
PRD**. Tên file mang `<FEATURE>` nên các UC không đâm nhau; `@trace.verifies` là chỗ phân biệt
|
|
591
|
+
TC thuộc UC nào.
|
|
592
|
+
|
|
593
|
+
**Đuôi bắt buộc là `.Test.md`.** `/qc-run-test` và `/qc-review` tìm `*.Test.md`; ghi ra
|
|
594
|
+
`TC_<FEATURE>.md` là ghi ra thứ **không trạm nào tìm thấy**, và **không có gì báo lỗi**.
|
|
595
|
+
|
|
596
|
+
`🚫 Block` trỏ `../DOC_GAP.md` — lên một cấp, vì file gap ở thư mục cha của `test-cases/`.
|
|
597
|
+
|
|
598
|
+
## Self-Review *(trước khi in Report)*
|
|
599
|
+
|
|
600
|
+
Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — **không chép lại ở đây**.
|
|
601
|
+
|
|
602
|
+
- **Bịa:** mỗi TC kiểm một hành vi **spec có nêu** — không phải hành vi tôi cho là hợp lý? Mỗi
|
|
603
|
+
`Expected` là **giá trị cụ thể** (*"hiển thị text 'Tên lớp: Toán 6A'"*), không phải *"hiển thị
|
|
604
|
+
đúng"* / *"hoạt động bình thường"*?
|
|
605
|
+
- **Nhảy bước:** đã áp luật ATOMIC cho **mọi** TC (không chỉ vài TC đầu), và đã chạy
|
|
606
|
+
§duplicate-check trước khi thêm TC mới?
|
|
607
|
+
- **Số liệu:** `{n}` TC mỗi file = `grep -cE "^#{2,4} *TC_"` thật? Các con số phân nhóm (GUI /
|
|
608
|
+
Validation / Functional / …) cộng lại đúng bằng tổng TC?
|
|
609
|
+
|
|
610
|
+
> Guard SC coverage ở trên là **phép đếm cơ học**, không phải self-review — nó đối chiếu với
|
|
611
|
+
> `.feature`, một nguồn khác. Đừng coi self-review đã bao nó. Xem §Ranh giới trong file skill.
|
|
612
|
+
|
|
613
|
+
## Report
|
|
614
|
+
|
|
393
615
|
**Đọc `.agent/steps/report-footer.md`** và áp đúng khuôn footer trong đó (Status Badge ·
|
|
394
|
-
Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
|
|
395
|
-
|
|
396
|
-
```
|
|
397
|
-
/qc-design-test Hoàn tất — {UC-ID} ({active_platform})
|
|
398
|
-
Chế độ: {giao diện | API | cả hai}{nếu --atomic-max: " · tách tối đa ({explode|keep-completeness})"}
|
|
399
|
-
Files: {qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md — {n} TC
|
|
400
|
-
{nếu có: "…_API.Test.md — {m} TC"}
|
|
401
|
-
Nhóm : GUI {a} · Validation {b} · Functional {c} · Integration {d} · NFR {e} · E2E {f}
|
|
402
|
-
{nếu file API: "Endpoint {g} · Integration API/DB/Kafka {h}"}
|
|
403
|
-
Trùng: {k} TC bỏ vì trùng ({j} trùng chéo UC — trỏ trace về UC nguồn thay vì viết lại)
|
|
404
|
-
Block: {blocked} TC bị chặn bởi gap — theo UC: {UC1: n · UC2: n}
|
|
405
|
-
|
|
406
|
-
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
616
|
+
Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
|
|
617
|
+
|
|
618
|
+
```
|
|
619
|
+
/qc-design-test Hoàn tất — {UC-ID} ({active_platform})
|
|
620
|
+
Chế độ: {giao diện | API | cả hai}{nếu --atomic-max: " · tách tối đa ({explode|keep-completeness})"}
|
|
621
|
+
Files: {qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md — {n} TC
|
|
622
|
+
{nếu có: "…_API.Test.md — {m} TC"}
|
|
623
|
+
Nhóm : GUI {a} · Validation {b} · Functional {c} · Integration {d} · NFR {e} · E2E {f}
|
|
624
|
+
{nếu file API: "Endpoint {g} · Integration API/DB/Kafka {h}"}
|
|
625
|
+
Trùng: {k} TC bỏ vì trùng ({j} trùng chéo UC — trỏ trace về UC nguồn thay vì viết lại)
|
|
626
|
+
Block: {blocked} TC bị chặn bởi gap — theo UC: {UC1: n · UC2: n}
|
|
627
|
+
{nếu UC đang Blocked: "⚠️ {UC-ID} đang Blocked bởi {n} gap 🔴 — trả lời {GAP-ID} với PO
|
|
628
|
+
rồi chạy lại lệnh này để tự gỡ dấu."}
|
|
629
|
+
Guard 🚫 Block: {{n} dấu đang mở, 0 cần gỡ | 🔓 gỡ {k} dấu (gap đã Answered): {danh sách}
|
|
630
|
+
| ⚠️ {GAP-ID} = Answered nhưng ô "Câu trả lời" trống — không gỡ được, hỏi lại PO}
|
|
631
|
+
Trace: {N} TC map tới {K}/{total} scenario của {UC-ID}
|
|
632
|
+
Guard SC coverage: {khớp {K}/{K} | ⚠️ {K}/{total} — đã bù {m} SC: {danh sách SC}}
|
|
633
|
+
{nếu có SC cần UI mà đang chạy --api: "⚠️ {n} SC cần UI chưa có TC ở file giao diện —
|
|
634
|
+
KHÔNG bù vào file API. Chạy: /qc-design-test {UC-ID} (không cờ). SC: {danh sách}"}
|
|
635
|
+
Self-review: {✅ sạch | ⚠️ {n} điểm cần chú ý — liệt kê}
|
|
636
|
+
Next : /qc-review {UC-ID} ← review test case trước khi sinh script
|
|
637
|
+
```
|