Quản lý kiểm tra với JIRA và Confluence

Cách tiếp cận (Approach): cách để xem xét hoặc làm gì đó
cambridge.org/dictionary/english/approach

Thuật ngữ

Đối với các điều khoản chưa được đề cập, hãy kiểm tra trên glossary.istqb.org/app/en/search/

Những điều trong thử nghiệm

Tiêu chí chấp nhận (Tiêu chí mà một thành phần hoặc hệ thống phải đáp ứng để được người dùng, khách hàng hoặc tổ chức được ủy quyền khác chấp nhận) được xác định trong Câu chuyện người dùng, có thể được đánh giá bằng đúng/sai, số lượng hoặc tỷ lệ phần trăm.

Kịch bản, mô tả chi tiết cơ hội khi người dùng cuối tương tác với sản phẩm, kèm theo câu chuyện, được viết bằng ngôn ngữ Gherkin.

Trường hợp thử nghiệm, một hiện vật độc lập đã vượt qua / không thành công được sử dụng để kiểm tra một thứ đích. Một kịch bản là một trường hợp thử nghiệm. 1 kịch bản là 1 trường hợp thử nghiệm. 

Kiểm thử, hành động thực thi một trường hợp kiểm thử.

Kết quả kiểm tra, kết quả của một bài kiểm tra, đạt/không đạt/bỏ qua/bị chặn/ v.v.

Các hoạt động trong thử nghiệm

Thử nghiệm thành phần (v)

Thực hiện kiểm tra đơn vị theo cấp/phương pháp, kiểm tra theo gói/kiện, xác minh API call riêng lẻ, kiểm tra xác minh màn hình riêng lẻ.
Làm với bất kỳ cách nào (giả lập, nguyên mẫu), bất kỳ dữ liệu nào (giả mạo) để chứng minh rằng thành phần hoạt động như mong đợi.
Việc kiểm tra này phải được tự động hóa, do nhà phát triển thiết kế.

Hệ thống kiểm tra (n)

API workflow test

 Khi frontend chưa sẵn sàng, hãy kiểm tra bằng cách mô phỏng liên tiếp chuỗi API calls.
 Kiểm tra với dữ liệu được xác định rõ ràng nhất quán trên toàn hệ thống.
 Việc kiểm tra này phải được tự động hóa, được thiết kế bởi Test Engineer lành nghề

Thử nghiệm Frontend Screen flow

Chỉ thực hiện phương pháp phân tích hồi quy đầy đủ cho frontend screen flow sau khi hoàn thành kiểm tra quy trình làm việc API
Kiểm tra với dữ liệu được xác định rõ ràng nhất quán trên toàn hệ thống.
Việc kiểm tra này phải được tự động hóa, được thiết kế bởi Test Engineer lành nghề

Hiệu suất, Bảo mật và kiểm tra phi chức năng khác

Thực hiện theo cách đặc biệt, theo đề xuất thực hành của Cấp cao/Trưởng nhóm để tối ưu hóa chi phí nhất.

Nghiệm Thu

Thực hiện kiểm tra ngẫu hứng, theo hướng khách quan, đóng khung thời gian.
Kiểm tra với dữ liệu được xác định rõ ràng nhất quán trên toàn hệ thống, càng gần với dữ liệu sản xuất càng tốt.
Việc kiểm tra này không nên được tự động hóa (để tiết kiệm chi phí)

Vòng Đời Của Bug

Bug được ghi lại khi nó không thể được sửa trong Sprint và cần được theo dõi, làm việc theo nhóm, báo cáo.

Teamwork tốt sẽ giúp sớm tìm ra bug, sửa lỗi nhanh chóng và ít cần chỉnh đốn/sắp xếp hơn

 

Bug cần được xử trí giống với cách của Story hoặc Task.

Cách để thử nghiệm

Craft test case

Bài thử nghiệm cần được thủ công hoá dưới các dạng cần có của ca thử nghiệm: Kịch bản, Checklist, Coverage maps, etc. Theo mặc định, dùng Kịch bản

Vòng đời của một ca kiểm thử về cơ bản giống như một quy trình làm việc đơn giản

Nội dung của một ca kiểm thử phải cho biết những gì sẽ được kiểm thử, và nên cho biết cách kiểm tra nó.

Plan test 

Với mỗi hoạt động kiểm tra,

Thực hiện kiểm tra và báo cáo

Theo từng bước một

Khi đến lúc kiểm tra (theo kế hoạch kiểm tra) VÀ các tiêu chí đầu vào kiểm tra được đáp ứng

• Phần mềm được triển khai
• Dữ liệu thử nghiệm được cung cấp (ví dụ: cơ sở dữ liệu đã kết xuất)

Then execute test case by case Thực hiện kiểm thử theo từng trường hợp

Cuối cùng

Trạng thái kết quả kiểm tra

PASS Trường hợp kiểm tra được thông qua

FAIL Trường hợp kiểm tra không thành công

SKIP Trường hợp kiểm tra không được thực thi bởi một số quyết định

BLOCKED Trường hợp kiểm tra không thể được thực hiện do trình chặn

BLANK Trường hợp thử nghiệm chưa được đụng tới

Truyền đạt và sử dụng kết quả kiểm tra

Đối với lỗi, hãy gửi danh sách lỗi cho nhóm trong cuộc họp

Đối với bản phát hành, hãy đính kèm hoặc tham khảo báo cáo thử nghiệm vào ghi chú phát hành.

Bug cần được xử trí giống với cách của Story hoặc Task.