Kỹ thuật đoán lỗi (Error Guessing) & checklist lỗi kinh nghiệm cho hệ thống ngân hàng

1. Tóm tắt nhanh & màn hình giao dịch bạn sẽ test

Nếu bạn đã quen với phân vùng tương đương, giá trị biên hay bảng quyết định, bạn đang dùng các kỹ thuật HÌNH THỨC — suy ra ca kiểm thử từ đặc tả một cách có công thức. Kỹ thuật đoán lỗi (error guessing) đi theo hướng khác: nó khai thác chính những gì đặc tả KHÔNG NÓI TỚI — thói quen của lập trình viên, các lỗi đã từng xảy ra trong quá khứ, và trực giác nghiệp vụ của một tester dày dạn. Trong core banking, đây không phải kỹ thuật 'phụ' mà là tuyến phòng thủ cuối cùng, vì rất nhiều lỗi nghiêm trọng nhất — sai số làm tròn dồn tích, giao dịch đồng thời vượt hạn mức, double-debit do timeout — gần như không lộ ra qua các kỹ thuật hình thức thông thường, chỉ lộ ra khi tester biết CHÍNH XÁC loại lỗi nào hay xảy ra ở đâu.

2. Error Guessing là gì & vì sao core banking cần

Theo phân loại ISTQB, kỹ thuật đoán lỗi thuộc nhóm 'kỹ thuật kiểm thử dựa trên kinh nghiệm' (experience-based test techniques), cùng nhóm với kiểm thử khám phá (exploratory testing) và kiểm thử theo checklist (checklist-based testing). Điểm khác biệt cốt lõi so với kỹ thuật hình thức (phân vùng tương đương, giá trị biên, bảng quyết định, chuyển trạng thái): kỹ thuật hình thức suy luận ca kiểm thử một cách CÓ THỂ LẶP LẠI từ đặc tả — hai tester khác nhau, theo đúng quy trình, sẽ ra một bộ ca gần giống nhau. Kỹ thuật đoán lỗi thì PHỤ THUỘC VÀO NGƯỜI: chất lượng ca kiểm thử tỉ lệ thuận với kinh nghiệm, hiểu biết miền nghiệp vụ, và mức độ 'nhớ lỗi cũ' của tester. Vì vậy, một Error Guessing chuyên nghiệp không phải nhắm mắt đoán bừa mà PHẢI được hệ thống hoá bằng checklist và defect taxonomy — nội dung ta xây ở chương 3.

Vì sao core banking đặc biệt cần kỹ thuật đoán lỗi dù đã có đầy đủ kỹ thuật hình thức? Vì rất nhiều lỗi nghiêm trọng nhất trong ngân hàng không nằm ở MỘT giao dịch đơn lẻ (nơi phân vùng tương đương/giá trị biên/bảng quyết định phủ tốt), mà nằm ở HÀNH VI HỆ THỐNG khi nhiều giao dịch tương tác: sai số làm tròn dồn tích qua hàng nghìn kỳ tính lãi, hai giao dịch chạm cùng một hạn mức cùng lúc, một giao dịch timeout rồi được retry. Không có công thức hình thức nào tự động sinh ra những ca này — chúng đến từ kinh nghiệm quan sát các postmortem, báo cáo audit, và sự cố production đã từng xảy ra ở chính hệ thống hoặc hệ thống tương tự.

3. Xây dựng Defect Taxonomy — checklist lỗi kinh nghiệm

Defect Taxonomy (bảng phân loại lỗi kinh nghiệm) là danh sách các NHÓM NGUYÊN NHÂN GỐC gây lỗi mà một hệ thống/miền nghiệp vụ hay gặp phải, được tổng hợp từ lịch sử sự cố thật thay vì suy diễn lý thuyết. Với core banking, taxonomy này nên xoay quanh những nhóm nguyên nhân xuất hiện lặp lại qua nhiều dự án ngân hàng: làm tròn số thập phân, hạn mức và giá trị biên động theo thời gian thực, tranh chấp tài nguyên khi nhiều giao dịch chạy đồng thời, timeout kèm khả năng retry gây trùng lặp, quy đổi tiền tệ nhiều bước, và trạng thái giao dịch bị treo giữa chừng.

Điều khiến bảng này khác một checklist thông thường: mỗi dòng đều trả lời câu hỏi 'vì sao kỹ thuật hình thức KHÓ bắt được lỗi này' — đây chính là lý do error guessing tồn tại như một kỹ thuật riêng, không phải bản sao yếu hơn của EP/BVA. Một defect taxonomy tốt không tĩnh: nó là TÀI SẢN SỐNG, được thêm dòng mới sau mỗi postmortem, và được gắn nhãn theo nghiệp vụ (chuyển khoản, hạn mức, lãi suất, thanh toán quốc tế...) để tester mới trong đội cũng áp dụng được ngay mà không cần nhiều năm kinh nghiệm.

4. Quy trình áp dụng Error Guessing có hệ thống

Error guessing 'chuyên nghiệp' khác error guessing 'nghiệp dư' ở đúng một điểm: nó có QUY TRÌNH, không phải cảm hứng nhất thời. Bốn bước dưới đây giúp bạn biến trực giác thành một hoạt động có thể lặp lại, đo lường và bàn giao lại cho đồng đội.

▶ Bước 1: Thu thập nguồn kinh nghiệm thật: báo cáo postmortem, backlog lỗi cũ, báo cáo kiểm toán nội bộ, và phỏng vấn đội vận hành/hỗ trợ khách hàng.

▶ Bước 2: Phân loại lỗi thu thập được theo NHÓM NGUYÊN NHÂN GỐC (làm tròn, hạn mức, đồng thời, timeout...) thay vì theo từng màn hình hay tính năng riêng lẻ.

▶ Bước 3: Với mỗi nhóm lỗi, viết ca kiểm thử nhắm thẳng vào ĐIỀU KIỆN gây ra lỗi đó, ghi rõ kết quả mong đợi, rồi đưa vào bộ hồi quy tự động hoặc thủ công.