Hồi mới học testing mình gặp một đống từ kết thúc bằng chữ test: Unit Test, Smoke Test, Static Test, Regression Test, Performance Test. Nhìn qua cứ tưởng chúng nằm chung một bảng phân loại, học hết bảng là xong.
Không có cái bảng thần kỳ đó.
System Test nói về test level. Functional Test nói về đặc tính đang kiểm tra. Static Test nói về có chạy đối tượng hay không. Regression Test lại nói về mục đích sau một thay đổi. Một bài test hoàn toàn có thể đeo vài nhãn cùng lúc.
Ví dụ: tester chạy lại flow chuyển tiền sau khi dev sửa cách tính phí. Đây có thể đồng thời là system testing, dynamic testing, functional testing và regression testing. Không có nhãn nào đấm nhau cả.
Test level không phải test type
Bốn level thường gặp đã nằm ở bài Testing Levels:
| Level | Test object thường gặp | Mục tiêu chính |
|---|---|---|
| Component testing | Function, class, module hoặc component | Kiểm tra từng phần riêng |
| Component integration testing | Giao diện giữa các component | Kiểm tra cách các phần code nói chuyện với nhau |
| System testing | Một hệ thống tương đối hoàn chỉnh | Kiểm tra hành vi end-to-end và đặc tính hệ thống |
| Acceptance testing | Sản phẩm trong bối cảnh sử dụng hoặc vận hành | Đánh giá hệ thống đã sẵn sàng để được chấp nhận chưa |
Team vẫn hay nói “loại test này là UAT”, người nghe vẫn hiểu. Nhưng khi cần giải thích cho rõ thì cứ gọi đúng chiều phân loại của nó.
Static testing và dynamic testing
Static testing
Static testing kiểm tra một work product mà không chạy chính đối tượng đó. Review requirement, walkthrough test case, code review và static analysis đều nằm trong vùng này.
Giả sử requirement ghi:
Mật khẩu phải dài từ 8 đến 16 ký tự và tối thiểu 20 ký tự nếu là tài khoản quản trị.
Chưa cần build cũng thấy hai rule đá nhau nếu tài khoản quản trị vẫn bị giới hạn 16 ký tự. Bắt được ở đây thì sửa một đoạn document. Đợi đến system test mới bắt thì BA, dev, tester và có khi cả database cùng làm lại.
Static testing phát hiện defect trong requirement, design, code hay testware. Bug và defect thường được dùng như từ đồng nghĩa; không có luật rằng bug chỉ nằm trong code còn defect chỉ nằm trong document. Phần đó đã xử lý ở Error, Defect và Failure.
Dynamic testing
Dynamic testing cho test object chạy rồi quan sát hành vi. Gọi một function trong unit test, bắn request vào API hay bấm app trên điện thoại đều là dynamic testing.
Nếu actual result lệch expected result, thứ ta quan sát được là failure. Từ failure đó team mới điều tra defect nằm ở code, config, data hay chỗ nào khác.
Functional testing và non-functional testing
Functional testing
Functional testing hỏi hệ thống làm gì. Nó kiểm tra business rule, flow, tính toán và những hành vi đã được yêu cầu.
Ví dụ với đăng nhập:
- Đúng username và password thì vào được tài khoản.
- Sai password năm lần thì tài khoản bị khóa theo rule.
- Tài khoản đã khóa không tạo được session mới.
Smoke testing thường chọn một nhóm chức năng quan trọng để xem build có đủ ổn cho việc test sâu hơn không. Còn chữ sanity test được mỗi công ty dùng một kiểu; đừng tranh luận bằng mồm, hãy hỏi scope thực tế của bộ test đó gồm những gì.
Non-functional testing
Non-functional testing hỏi hệ thống làm tốt đến đâu hoặc có những đặc tính chất lượng nào. Một số nhóm quen thuộc:
| Nhóm | Câu hỏi ví dụ |
|---|---|
| Performance | API chịu được bao nhiêu request và phản hồi trong bao lâu? |
| Security | Người không có quyền có đọc được dữ liệu này không? |
| Usability | Người dùng có hiểu và hoàn thành được flow không? |
| Accessibility | Người dùng bàn phím hoặc screen reader có thao tác được không? |
| Compatibility | Tính năng có chạy đúng trên browser, OS hoặc thiết bị được hỗ trợ không? |
| Reliability | Hệ thống có duy trì hoạt động ổn định trong điều kiện đã nêu không? |
UI testing không nằm gọn trong một phía. Click nút gửi form và kiểm tra request là functional; kiểm tra focus, contrast và cách screen reader đọc form lại nghiêng về non-functional.
Black-box và white-box
Black-box testing thiết kế test dựa trên input, output và hành vi được mô tả, không dựa vào cấu trúc bên trong. Equivalence partitioning, boundary value analysis, decision table và state transition là các kỹ thuật black-box.
White-box testing dựa trên cấu trúc bên trong như statement, branch hoặc đường đi của code. Biết source code tồn tại không tự động biến mọi test thành white-box; test phải thật sự dùng cấu trúc đó để chọn coverage item.
Giữa hai phía còn có chữ gray-box, dân dự án dùng khá nhiều để chỉ tình huống tester biết một phần kiến trúc, database hoặc implementation rồi tận dụng nó khi test. Đây là cách nói thực dụng, không phải một nhóm kỹ thuật chính trong CTFL.
Confirmation testing và regression testing
Dev báo bug đã fixed. Ta có hai câu hỏi khác nhau:
- Con bug cũ đã hết chưa?
- Thay đổi vừa rồi có làm hỏng thứ khác không?
Confirmation testing trả lời câu đầu. Chạy lại điều kiện từng làm bug xuất hiện và kiểm tra fix có hoạt động không. Mọi người thường gọi là retest.
Regression testing trả lời câu thứ hai. Ta chọn các vùng có thể chịu ảnh hưởng và chạy lại test liên quan. Có lúc phải chạy cả bộ, nhưng không có luật rằng mỗi bug fix đều kéo toàn bộ kho test case ra chạy từ đầu đến cuối.
Giả sử dev sửa query đăng nhập:
- Confirmation: dùng account từng tái hiện bug để xem đăng nhập đã được chưa.
- Regression: test thêm account thường, account khóa, sai password, session cũ và những flow dùng chung query hoặc authentication service.
Scope regression là bài toán impact và risk. “Chạy hết cho chắc” nghe an toàn, đến lúc bộ test chạy ba ngày mà tối nay phải release thì nó bắt đầu bớt chắc.
Exploratory, ad-hoc và monkey testing
Exploratory testing là lúc học sản phẩm, thiết kế test và thực thi test diễn ra cùng nhau. Nó vẫn có thể có charter, timebox, note và debrief. Không có test case viết sẵn không đồng nghĩa với không có đầu óc.
Ad-hoc testing ít formal hơn, dựa nhiều vào trực giác và hiểu biết của người test tại thời điểm đó. Monkey testing lại thiên về thao tác ngẫu nhiên hoặc bán ngẫu nhiên, đôi khi do tool sinh ra. Ba chữ này hay bị quẳng chung vào một rổ “bấm linh tinh”, nhưng làm vậy thì mất sạch ý nghĩa.
Ví dụ mình muốn exploratory test màn hình upload file trong 45 phút. Charter có thể là:
Tìm cách làm upload thất bại hoặc tạo trạng thái khó hiểu bằng loại file, kích thước file và việc mất mạng.
Từ đó mình vừa thử, vừa học constraint, vừa ghi lại đường đi tiếp theo. Nó tự do hơn scripted testing, nhưng không phải ngồi đập bàn phím cầu bug hiện lên.
Chốt lại
Khi ai đó nói “đây là loại test gì?”, hỏi ngược một câu là đủ:
Bạn đang muốn phân loại theo level, theo đặc tính chất lượng, theo cách thiết kế hay theo mục đích chạy lại?
Xác định đúng cái trục rồi thì đống thuật ngữ tự nhiên bớt loạn. Bài tiếp theo sẽ đi từ các test condition sang high-level test case và RTM, tức là bắt đầu biến requirement thành thứ có thể quản lý coverage được.
