Bài 13 — Testing là gì? Manual vs automation, các loại test và khi nào tự động hóa

Bài 12 đã trang bị cho bạn công cụ đọc cấu trúc trang web thật. Trước khi viết test bằng Playwright, cần nắm thêm một nền tảng nữa: kiểm thử phần mềm (software testing) là gì, có những loại nào, và quan trọng nhất — khi nào nên tự động hóa. Đây là phần phân biệt người bấm nút theo hướng dẫn với người hiểu mình đang làm gì và vì sao.

Testing là gì

Kiểm thử phần mềm là quá trình đánh giá xem phần mềm có hoạt động đúng như mong đợi không, và phát hiện sai lệch (bug) trước khi tới tay người dùng. Về bản chất, mỗi bài test trả lời một câu hỏi: “Với đầu vào này, phần mềm có cho ra kết quả đúng không?”

Một vài thuật ngữ nền tảng:

• Test case (còn gọi là kịch bản kiểm thử): một kịch bản kiểm thử cụ thể, gồm điều kiện đầu vào và kết quả mong đợi. Trong series này hai cách gọi được dùng lẫn nhau.
• Bug (defect): sai lệch giữa hành vi thực tế và hành vi mong đợi.
• Pass / Fail: test pass khi kết quả thực tế khớp mong đợi; fail khi không khớp.
• Assertion: bước kiểm tra khẳng định “giá trị thực tế phải bằng/khớp giá trị mong đợi”.

Manual vs Automation test

Điểm cần nhớ: automation không thay thế manual. Hai cái bổ trợ nhau. Automation lo phần lặp lại, ổn định; manual lo phần cần tư duy con người, đánh giá trực quan, và khám phá cái mới.

Các loại test: Test Pyramid

Test pyramid (kim tự tháp kiểm thử) là mô hình phân tầng test theo phạm vi và số lượng nên có. Từ đáy lên đỉnh:

        /\        E2E (End-to-End)      — ít, chậm, đắt
       /  \
      /----\      Integration           — vừa
     /      \
    /--------\    Unit                  — nhiều, nhanh, rẻ

• Unit test — kiểm thử từng đơn vị code nhỏ nhất (một hàm) một cách độc lập. Nhanh, rẻ, nên có nhiều nhất. Do lập trình viên viết.
• Integration test — kiểm thử nhiều thành phần phối hợp với nhau (ví dụ code + database).
• E2E (End-to-End) test — kiểm thử toàn bộ luồng từ góc nhìn người dùng, qua giao diện thật (mở trang, đăng nhập, mua hàng). Chậm và đắt nhất, nên có ít nhất, tập trung vào các luồng quan trọng.

Playwright thuộc tầng E2E — nó điều khiển trình duyệt thật để mô phỏng người dùng. Đây là loại test bạn sẽ viết suốt series. Hiểu vị trí của nó trong pyramid giúp bạn biết giới hạn: E2E mạnh nhưng chậm và dễ vỡ, nên chỉ dùng cho các luồng cốt lõi, không nhồi mọi thứ vào E2E.

Kiểm thử hồi quy — vì sao automation tỏa sáng

Regression test (kiểm thử hồi quy) là chạy lại các test cũ để chắc rằng thay đổi mới không làm hỏng chức năng đang chạy tốt. Mỗi lần lập trình viên sửa code, về lý thuyết phải hồi quy toàn bộ.

Làm hồi quy bằng tay thì tốn kém và không khả thi khi hệ thống lớn. Đây chính là chỗ automation phát huy: viết một lần, chạy lại nghìn lần, mỗi lần code thay đổi. Phần lớn giá trị của automation test nằm ở hồi quy.

Khi nào NÊN tự động hóa

Ưu tiên tự động hóa khi test có các đặc điểm:

• Lặp lại nhiều lần (chạy mỗi lần build, mỗi ngày).
• Ổn định — chức năng đã chốt, ít thay đổi giao diện.
• Quan trọng — luồng nghiệp vụ cốt lõi (đăng nhập, thanh toán).
• Tốn công làm tay — nhiều bước, nhiều dữ liệu.
• Dễ đoán kết quả — đầu ra rõ ràng đúng/sai.

Khi nào KHÔNG nên tự động hóa

Tự động hóa sai chỗ còn tệ hơn không có, vì tốn công viết và bảo trì mà ít giá trị:

• Chức năng còn thay đổi liên tục — viết xong sửa lại hoài, tốn hơn lợi.
• Chạy một lần rồi thôi — không đáng công tự động.
• Kiểm tra cảm quan — thẩm mỹ, trải nghiệm, “trông có đẹp không” — cần mắt người.
• Test khám phá (exploratory) — dò tìm bug theo trực giác, không có kịch bản cố định.

Một sai lầm phổ biến của đội mới làm automation là cố “tự động hóa 100%”. Mục tiêu đúng không phải số lượng test tự động, mà là tự động hóa đúng chỗ có giá trị cao nhất. Biết chọn cái gì để tự động hóa là kỹ năng quan trọng ngang việc biết viết test.

Bài 14 đi sâu vào cách thiết kế một test case tốt — cấu trúc AAA và các nguyên tắc khiến test dễ đọc, dễ bảo trì.

🛠 Thực hành

1. Phân loại: với một website bán hàng, liệt kê 5 chức năng và quyết định chức năng nào nên tự động hóa, cái nào không, kèm lý do dựa trên tiêu chí trong bài.
2. Xếp tầng pyramid: cho các mô tả test sau, xếp mỗi cái vào tầng unit / integration / E2E: (a) kiểm tra hàm tính thuế, (b) kiểm tra luồng đặt hàng qua giao diện, (c) kiểm tra code lưu đúng vào database.
3. Viết test case bằng lời: mô tả 3 test case cho chức năng “tìm kiếm sản phẩm” (gồm đầu vào và kết quả mong đợi), trong đó có ít nhất một trường hợp bất thường.

Website tham khảo

• ISTQB — Foundation Level Syllabus — tài liệu nền tảng chuẩn về kiểm thử.
• Martin Fowler — The Practical Test Pyramid — bài viết kinh điển về test pyramid.
• Playwright — Why Playwright — vị trí của E2E test và triết lý công cụ.