Không có documentation, không có đầy đủ requirement. Vậy QA dựa vào đâu để biết hệ thống đang hoạt động đúng hay sai?
Khi làm việc với một hệ thống đã vận hành nhiều năm, QA rất dễ gặp tình huống documentation không còn đầy đủ hoặc không phản ánh đúng behavior hiện tại.
Một số business rules chỉ tồn tại trong code. Một số logic được kế thừa từ phiên bản cũ. Có những chức năng mà ngay cả team hiện tại cũng không hiểu hết.
Trong tình huống này, nếu QA bắt đầu bằng cách viết test cases dựa trên suy đoán, có thể:
bỏ sót behavior quan trọng;
hiểu sai business rule;
hoặc coi một behavior đang được sử dụng là bug.
Mục tiêu là giảm những điều QA chưa biết về hệ thống.
Bài viết này đi theo một flow đơn giản:
1. Trước khi viết Test Case, hãy hiểu mình đang test cái gì
Sai lầm phổ biến nhất là bắt đầu viết test khi expected behavior còn chưa rõ.
Hãy tưởng tượng bạn nhận một task:
“Update registration logic to support a new business rule.”
Requirement chỉ có vài dòng.
Khi kiểm tra hệ thống, bạn phát hiện:
một function được nhiều module sử dụng;
một database table được nhiều chức năng đọc và ghi;
một số validation không có trong requirement;
có scheduled jobs chạy tự động;
UI hiện tại khác với documentation cũ.
Lúc này, QA chưa có đủ cơ sở để viết expected result.
Nếu tự suy đoán, test case có thể sai từ đầu.
Nếu chỉ test đúng phần requirement mới, bạn lại có nguy cơ bỏ sót behavior cũ mà những chức năng khác đang phụ thuộc.
Vì vậy,Bước đầu tiên không phải là tăng test coverageMà là giảm những điều chưa biết về hệ thống.
QA cần trả lời ba câu hỏi trước
Mục tiêu ở bước này: chưa cần test nhiều, nhưng phải hiểu đúng phạm vi.
Ba câu hỏi này sẽ định hướng toàn bộ Test Strategy
2. Khi không biết expected behavior, thì tìm hiểu hệ thống đang hoạt động thế nào - dùng Characterization Testing
QA cần xây dựng lại baseline về behavior hiện tại của hệ thống. Một phương pháp hữu ích là Characterization Testing
Characterization Testing giúp QA ghi nhận hệ thống đang thực sự làm gì, thay vì đoán nó phải làm gì.
Câu hỏi cốt lõi là:
“Với input và điều kiện này, hệ thống hiện tại thực sự trả ra kết quả gì?”
Ví dụ với chức năng Registration:
| Thành phần | Điều cần tìm hiểu |
|---|---|
| Input | Player, event, class, registration status |
| Output | Success message, error message, registration result |
| Database | Record được tạo, cập nhật hoặc xóa |
| Side effects | Email, notification, waitlist update |
| Related behavior | Registration list, registration history, reports |
Giả sử khi đăng ký thành công, hệ thống:
- Kiểm tra điều kiện đăng ký.
- Tạo registration record.
- Cập nhật trạng thái.
- Gửi email xác nhận.
- Cập nhật danh sách registration.
QA có thể viết test để ghi nhận những behavior này.
Ví dụ:
Registration thành công phải tạo đúng record.
Registration thất bại không tạo dữ liệu ngoài mong muốn.
Email xác nhận được gửi khi đăng ký thành công.
Registration status trên admin được cập nhật đúng.
Dữ liệu liên quan không bị thay đổi sai.
Điểm cần nhớ
Characterization Test không chứng minh behavior hiện tại là đúng về business. Nó chỉ giúp QA biết behavior nào đang tồn tại.
Nếu gặp behavior lạ, vẫn cần xác minh với Developer hoặc Business Owner trước khi xác định expected result chính thức.
3. Không có Documentation thì tìm Evidence ở đâu?
Một nguồn thông tin hiếm khi đủ. QA cần ghép nhiều evidence lại với nhau.
| Nguồn | QA có thể tìm hiểu |
|---|---|
| UI | User nhìn thấy và thao tác được gì |
| Source code | Logic, validation, conditions |
| Database | Dữ liệu được lưu và thay đổi thế nào |
| Logs | Request đã đi qua đâu, lỗi phát sinh ở bước nào |
| Support tickets | Người dùng thường gặp vấn đề gì |
| Incident history | Production từng lỗi ở đâu |
| Analytics | Flow nào được dùng nhiều |
| Release notes | Hệ thống đã từng thay đổi gì |
| User manuals | Nghiệp vụ được vận hành ra sao |
Cách đọc evidence hiệu quả
UI → thấy behavior từ phía user.
Source code → hiểu logic xử lý.
Database → thấy dữ liệu thật.
Logs → thấy quá trình thực thi.
Tickets / incidents → thấy lỗi thực tế đã từng xảy ra.
Ví dụ:
Documentation nói rằng một registration chỉ có một Age group.
Nhưng database lại lưu nhiều Age group, và admin UI dùng dữ liệu đó để hiển thị registration history.
Nếu chỉ đọc documentation, QA rất dễ bỏ qua phần này.
Đừng hỏi “Nguồn nào đúng nhất?”. Hãy hỏi “Các nguồn này có đang kể cùng một câu chuyện không?”.
4. Dependency Mapping: Một thay đổi có thể ảnh hưởng đến những gì?
Hiểu behavior của một chức năng vẫn chưa đủ. QA còn cần biết chức năng đó đang được những thành phần nào sử dụng
Vì test đúng feature nhưng bỏ sót dependency vẫn có thể làm release lỗi.
Đây là lý do cần Dependency Mapping.
Điểm cần nhớ
Dependency Mapping giúp xác định các thành phần có quan hệ phụ thuộc với chức năng đang được thay đổi. Từ đó, QA có thể xác định những khu vực cần regression testing.
Ví dụ Registration Module có thể liên quan đến:
Registration Form
Registration API
Business logic
Database
Scheduled jobs
Email service
Reports
Export data
Có thể hình dung:
Registration Form → API → Database → Jobs → Reports / Notifications
Nếu Developer thay đổi logic lưu registration, QA không nên chỉ test UI.
Cần kiểm tra thêm:
Record có lưu đúng không?
Module khác đọc record đó có còn đúng không?
Scheduled job có xử lý đúng không?
Report có hiển thị đúng không?
Cách tìm dependency
- Search nơi function hoặc API được gọi.
- Kiểm tra database tables và queries liên quan.
- Tìm scheduled jobs dùng dữ liệu đó.
- Kiểm tra external integrations.
- Trao đổi với Developer hoặc owner của module.
Không cần hiểu cả hệ thống. Bắt đầu từ điểm thay đổi, rồi lần theo những thứ đang phụ thuộc vào nó.
5. Xây dựng Test Coverage: Không thể test mọi thứ: ưu tiên gì trước?
Test coverage tốt không có nghĩa là test tất cả. Nó có nghĩa là test đúng nơi có rủi ro cao nhất.
Một hệ thống đã vận hành nhiều năm có thể có hàng trăm chức năng và rất nhiều business rules. Không thể chạy toàn bộ test cases sau mỗi thay đổi. Vì vậy, cần ưu tiên những luồng có mức độ quan trọng cao.
Một cách hữu ích là xác định Golden Paths.
Golden Paths là các luồng quan trọng mà hệ thống phải duy trì ổn định.
Có thể ưu tiên dựa trên:
Business impact – lỗi có ảnh hưởng nghiệp vụ lớn không?
Usage frequency – flow có được dùng thường xuyên không?
Risk of failure – có nhiều dependencies không?
Data criticality – có ảnh hưởng dữ liệu khó khôi phục không?
Ví dụ với Registration System:
User đăng ký thành công.
Class full → user vào waitlist.
Admin cập nhật registration status.
Registration bị rejected hoặc cancelled.
Reports hiển thị đúng số lượng.
Smoke Test vs Regression Test
Phạm vi regression nên đi theo impact analysis, không nên mặc định “chạy tất cả”.
6. Historical Bugs là một nguồn Test Coverage rất giá trị
Bug đã từng xảy ra là bằng chứng rõ nhất về nơi hệ thống dễ vỡ.
Historical bugs có thể giúp QA nhận ra:
module nào thường lỗi;
edge case nào dễ bị bỏ sót;
dependency nào dễ gây side effect;
business rule nào có nhiều ngoại lệ.
Ví dụ:
Một player đăng ký hai chương trình khác nhau nhưng conflict message chỉ hiển thị một chương trình.
Sau khi fix, regression test nên bao gồm:
Một conflict → hiển thị đúng.
Nhiều conflicts → hiển thị đầy đủ.
Thứ tự đăng ký không làm thay đổi kết quả ngoài mong muốn.
Một production bug quan trọng không nên kết thúc bằng “fix xong rồi close”. Nó nên để lại một regression test, checklist hoặc monitoring rule.
7. Gặp behavior lạ: đừng vội gọi đó là bug
“Không có trong requirement” chưa chắc đồng nghĩa với “sai”.
Một behavior lạ có thể là:
bug cũ;
business rule chưa document;
workaround;
logic mà hệ thống khác đang phụ thuộc.
Ví dụ:
Status tự đổi.
Record vẫn được giữ sau khi cancel.
Một validation không có trong requirement.
Scheduled job sửa dữ liệu tự động.
QA nên:
- Ghi nhận behavior.
- Reproduce lại.
- Kiểm tra bug history, logs, release notes.
- Tìm dependency liên quan.
- Xác minh với Developer hoặc Business Owner
- Ghi lại quyết định cuối cùng.
Hai khái niệm cần tách rõ
QA không nên tự biến behavior hiện tại thành expected behavior nếu chưa có evidence đủ mạnh.
8. Testing không kết thúc ở Staging
Pass regression chưa có nghĩa là release không còn rủi ro.
Production có thể khác môi trường test ở:
data;
traffic;
integration;
scheduled jobs;
những combination hiếm.
Vì vậy Test Strategy nên bao gồm cả kế hoạch sau release. Đặc biệt với những hệ thống có nhiều dependencies, một thay đổi có thể hoạt động tốt trong môi trường test nhưng vẫn phát sinh vấn đề khi chạy với dữ liệu và traffic thực tế.
Một số phương pháp team có thể sử dụng:
Feature Flag
Cho phép bật/tắt feature mới bằng config.
Canary Release
Deploy cho một nhóm nhỏ user trước.
Enhanced Logging
Theo dõi:
request;
database operations;
error;
scheduled jobs;
trạng thái xử lý.
Rollback Plan
Cần xác định trước:
rollback code như thế nào;
database có cần rollback không;
dữ liệu đã thay đổi có khôi phục được không.
Ví dụ sau khi update Registration Logic
Có thể monitor:
số registration thành công;
số registration fail;
error mới;
trạng thái scheduled jobs;
dữ liệu giữa registration và reports có khớp không.
Test Strategy tốt không chỉ nói “test gì trước release”, mà còn phải nói “sau release cần nhìn vào đâu để biết hệ thống vẫn ổn”.
9. Practical Checklist: Không có Documentation thì bắt đầu từ đâu?
Step 1 – Understand Current Behavior
Thử flow hiện tại.
Ghi nhận input, output, state change.
Kiểm tra side effects.
Tạo characterization tests.
Step 2 – Collect Evidence
Kiểm tra Source code và Database.
Tìm kiếm Logs của application.
Tìm lại Historical bugs và Support tickets.
Kiểm tra Release notes.
Xác minh với Developer / Business Owner.
Step 3 – Map Dependencies
Tìm và xác định những Module Shared function / API.
Xác định Database tables và stored procedures liên quan.
Kiểm tra Scheduled jobs và External integrations.
Xác định Downstream systems có thể bị ảnh hưởng.
Step 4 – Define Test Scope
Xác định Golden Paths.
Ưu tiên business-critical và High-risk flows.
Bổ sung Regression tests từ Historical bug.
Xác định Smoke scope và Regression scope cho task hiện tại.
Step 5 – Control Release Risk
Xác định Logs và Metrics cần theo dõi.
Chuẩn bị Feature flag / limited rollout nếu cần.
Xác định Rollback plan.
Theo dõi Production verification sau release.
Takeaway
Không có documentation không có nghĩa QA không thể test. Nhưng QA không nên nhảy thẳng từ requirement thiếu sang test case.
Một flow an toàn hơn là:
Understand → Collect Evidence → Map Dependencies → Define Test Scope → Validate → Monitor
Một Test Strategy tốt cần trả lời được:
Expected behavior này dựa trên evidence nào?
Thay đổi có thể ảnh hưởng đến đâu?
Tại sao những test case này được ưu tiên?
Rủi ro nào vẫn chưa được xác minh?
Sau release cần monitor gì?
Khi documentation không có sẵn, QA không chỉ làm nhiệm vụ tìm bug. QA còn phải từng bước tái xây dựng hiểu biết về hệ thống để mọi thay đổi sau đó có thể được test một cách có cơ sở.
