Từ điển thuật ngữ BA

Kiểm thử hộp đen

Cách kiểm thử chỉ dựa vào đầu vào và đầu ra theo yêu cầu, không cần biết bên trong code viết thế nào. Đây là kiểu test mà QC và người dùng nghiệp vụ làm hằng ngày.

Lỗi phần mềm

Cách gọi dân dã của một lỗi trong phần mềm khiến hệ thống chạy sai so với mong đợi. Trong tài liệu chuẩn thì từ chính xác là defect, còn bug là từ cả team dùng hằng ngày.

Khiếm khuyết phần mềm

Chỗ sai nằm trong code, cấu hình hoặc tài liệu khiến hệ thống không đáp ứng đúng yêu cầu đã chốt. Đây là từ chuẩn dùng trong báo cáo và biên bản nghiệm thu, thay cho chữ bug nói miệng.

Vòng đời của lỗi

Chuỗi trạng thái mà một defect đi qua từ lúc được phát hiện tới lúc đóng: New, Assigned, Open, Fixed, Retest, Verified, Closed, cộng các nhánh rẽ như Reopen, Rejected hay Deferred.

Môi trường hệ thống

Các bản cài đặt riêng biệt của cùng một hệ thống dùng cho từng mục đích: DEV để lập trình, SIT để ghép nối, UAT để khách nghiệm thu, PROD là hệ thống thật đang chạy.

Bản vá khẩn

Bản sửa gấp đưa thẳng lên môi trường thật để chặn một sự cố đang gây thiệt hại, bỏ qua phần lớn lịch phát hành thông thường nhưng vẫn phải test và ghi lại đầy đủ.

Mức độ ưu tiên

Thứ tự cần xử lý một defect, quyết định bởi tác động kinh doanh và lịch phát hành chứ không chỉ bởi mức hỏng. Một lỗi nhỏ vẫn có thể ưu tiên cao nếu khách nhìn thấy mỗi ngày.

Đảm bảo chất lượng

Tập hợp hoạt động hướng vào quy trình để lỗi ít có cơ hội sinh ra: đặt chuẩn tài liệu, review, audit, cải tiến cách làm. QA nhìn vào cách làm việc chứ không nhìn từng build.

Kiểm soát chất lượng

Hoạt động soi sản phẩm đã làm ra để tìm chỗ sai so với yêu cầu: chạy test case, log bug, verify lại sau khi dev fix. Ở Việt Nam, QC còn là tên gọi của chính người làm việc đó.

Kiểm thử hồi quy

Chạy lại các phần đã chạy đúng trước đây để chắc rằng thay đổi mới không làm hỏng cái cũ. Càng sửa nhiều, càng phải chạy, và đây là lý do chính khiến người ta đầu tư test tự động.

Ghi chú phát hành

Bản ghi ngắn đi kèm mỗi lần phát hành: phiên bản này có gì mới, sửa lỗi nào, còn hạn chế gì, cần làm gì trước và sau khi cập nhật. Người vận hành và khách đọc nó để khỏi bị bất ngờ sáng hôm sau.

Kiểm thử xác minh nhanh

Kiểm tra nhanh và có trọng điểm vào đúng phần vừa được sửa hoặc vừa thêm, xem nó có hoạt động hợp lý không trước khi bỏ công test sâu và chạy hồi quy.

Mức độ nghiêm trọng

Mức độ ảnh hưởng của một defect lên hệ thống và nghiệp vụ, do QC đánh giá dựa trên hậu quả kỹ thuật. Nó khác với priority, tức thứ tự cần sửa trước sau.

Kiểm thử sơ bộ

Bộ kiểm tra nhanh vài chức năng xương sống ngay sau khi nhận build, để quyết định build này có đáng test tiếp hay trả lại cho dev. Thường chạy trong 15 tới 60 phút.

Kiểm thử tích hợp hệ thống

Giai đoạn kiểm thử ghép các hệ thống hoặc module lại với nhau để xem dữ liệu chạy qua ranh giới giữa chúng có đúng không. Đây là nơi lộ ra phần lớn lỗi tích hợp trước khi tới tay người dùng.

Ca kiểm thử

Một ca kiểm thử cụ thể gồm tiền điều kiện, các bước thao tác, dữ liệu đầu vào và kết quả mong đợi, để hai người khác nhau chạy đều ra cùng một kết luận đúng hay sai.

Độ phủ kiểm thử

Tỉ lệ phần đã được kiểm thử so với phần cần kiểm thử, tính theo yêu cầu, theo chức năng hoặc theo dòng code. Con số này chỉ có nghĩa khi nói rõ đang phủ trên cái gì.

Kế hoạch kiểm thử

Tài liệu chốt phạm vi kiểm thử, cách test, ai làm, môi trường và dữ liệu nào, tiêu chí bắt đầu và kết thúc. Nó tồn tại để lúc gấp gáp không ai tự ý bỏ bớt phần quan trọng.

Kịch bản kiểm thử

Mô tả ngắn một tình huống cần kiểm thử ở mức nghiệp vụ, chưa đi vào từng bước bấm. Một scenario thường đẻ ra nhiều test case chi tiết bên dưới.

Kiểm thử Chấp nhận Người dùng

Giai đoạn kiểm thử cuối cùng do người dùng thực hiện để xác nhận hệ thống đáp ứng yêu cầu nghiệp vụ.