Kiểm thử và tinh chỉnh Skill: trigger test, functional test

1. Các mức độ kiểm thử

Skill có thể được kiểm thử ở nhiều mức độ tùy nhu cầu:

Một Skill dùng nội bộ cho nhóm nhỏ có nhu cầu kiểm thử khác với Skill triển khai cho hàng nghìn người. Chọn mức độ phù hợp với phạm vi sử dụng.

2. Một mẹo hiệu quả: lặp trên một tác vụ trước khi mở rộng

Cách tiếp cận hiệu quả là lặp đi lặp lại trên một tác vụ khó cho đến khi Claude làm đúng, rồi mới trích phương pháp thắng cuộc đó thành Skill. Cách này tận dụng khả năng học trong ngữ cảnh của Claude và cho tín hiệu nhanh hơn so với kiểm thử dàn trải. Khi đã có nền tảng hoạt động tốt, mới mở rộng ra nhiều ca kiểm thử để phủ rộng hơn.

3. Ba nhóm kiểm thử nên có

3a. Kiểm tra kích hoạt (Triggering test)

Mục tiêu: đảm bảo Skill nạp đúng lúc.

Bộ ca kiểm thử nên gồm cả ba loại:

Nên kích hoạt:
- "Viết test case cho user story này: ..."
- "Tạo test case từ yêu cầu chức năng đăng nhập"
- "Phân tích kịch bản kiểm thử cho màn hình thanh toán"

Nên KHÔNG kích hoạt:
- "Thời tiết Hồ Chí Minh hôm nay thế nào?"
- "Viết một đoạn code Python"
- "Tạo file Excel báo cáo" (trừ khi Skill xử lý việc này)

Kiểm tra ba điểm: kích hoạt với yêu cầu rõ ràng, kích hoạt với cách diễn đạt khác, và không kích hoạt với chủ đề không liên quan.

3b. Kiểm tra chức năng (Functional test)

Mục tiêu: xác minh Skill cho đầu ra đúng.

Ca kiểm thử: Sinh test case cho user story đăng nhập
Cho trước: User story mô tả chức năng đăng nhập email + mật khẩu
Khi: Skill thực thi
Thì:
  - Có đủ ba nhóm kịch bản (happy, biên, ngoại lệ)
  - Test Case ID đúng định dạng quy ước
  - Đủ các cột bắt buộc theo template
  - Trình bày dưới dạng bảng

Các điểm cần kiểm: đầu ra hợp lệ, các bước thực thi thành công, xử lý lỗi hoạt động, và bao phủ các ca biên.

3c. So sánh hiệu quả (Performance comparison)

Mục tiêu: chứng minh Skill cải thiện kết quả so với khi không dùng.

Ví dụ minh họa một phép so sánh:

Không dùng Skill:
- Người dùng phải mô tả quy ước mỗi lần
- Nhiều lượt trao đổi qua lại để chỉnh đúng định dạng
- Kết quả không nhất quán giữa các lần

Dùng Skill:
- Workflow chạy tự động
- Chỉ vài câu hỏi làm rõ
- Đầu ra nhất quán về cấu trúc

Có thể đo bằng cách so cùng một tác vụ khi bật và tắt Skill, đếm số lượt trao đổi và mức độ nhất quán của kết quả.

4. Tinh chỉnh dựa trên tín hiệu

Skill là tài liệu sống, cần điều chỉnh dựa trên hành vi thực tế.

4a. Skill kích hoạt thiếu (Undertriggering)

Dấu hiệu:

• Skill không nạp khi đáng lẽ phải nạp.
• Người dùng phải bật thủ công.
• Có câu hỏi về việc khi nào nên dùng Skill.

Cách xử lý: bổ sung chi tiết và sắc thái cho trường description, đặc biệt là các từ khóa kỹ thuật.

4b. Skill kích hoạt thừa (Overtriggering)

Dấu hiệu:

• Skill nạp cho cả truy vấn không liên quan.
• Người dùng tắt Skill đi.
• Có sự nhầm lẫn về mục đích.

Cách xử lý: thêm điều kiện loại trừ (negative trigger) và viết description cụ thể hơn. Ví dụ:

description: Sinh test case từ user story. Dùng cho phân tích kịch bản
  kiểm thử từ yêu cầu chức năng. KHÔNG dùng cho việc viết code tự động
  hay tạo tài liệu chung.

4c. Vấn đề khi thực thi (Execution issues)

Dấu hiệu: kết quả không nhất quán, hoặc người dùng phải sửa nhiều.

Cách xử lý: cải thiện phần hướng dẫn, bổ sung xử lý lỗi (xem lại Bài 5).

5. Cách kiểm tra nhanh hành vi kích hoạt

Hỏi trực tiếp Claude: "Khi nào bạn sẽ dùng Skill [tên skill]?" Claude sẽ trích lại nội dung description. So sánh câu trả lời với kỳ vọng để biết cần bổ sung từ khóa hay điều kiện loại trừ nào.

6. Tổng kết bài 7

• Kiểm thử Skill theo ba nhóm: kích hoạt, chức năng, và so sánh hiệu quả.
• Nên lặp trên một tác vụ khó đến khi đạt, rồi mới mở rộng phủ rộng.
• Skill kích hoạt thiếu thì bổ sung từ khóa; kích hoạt thừa thì thêm điều kiện loại trừ.
• Skill là tài liệu sống, cần tinh chỉnh liên tục dựa trên hành vi thực tế.

Bài tiếp theo (Bài 8): Đóng gói, chia sẻ và dùng Skill trong nhóm QA — từ nén file, upload, đến triển khai cấp tổ chức và lưu trữ trên GitHub.