Kiểm thử tự động

Technical

Xây bộ kiểm thử chạy được liên tục và đáng tin.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Kỹ thuật cho PM/BA — 2 người đã làm. Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Technical, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Test tự động là mã chạy thay người để kiểm tra phần mềm vẫn đúng sau mỗi thay đổi. Giá trị thật không phải "bắt lỗi" mà là <em>cho phép sửa mà không sợ</em>. Một bộ test hay khiến người ta dám refactor; một bộ test dở khiến người ta sợ cả test lẫn code.

Khi đã làm được

Quyết được test cái gì ở tầng nào (đơn vị / tích hợp / đầu-cuối), giữ bộ test chạy đủ nhanh để không ai bỏ qua, nhận ra và xử lý test chập chờn trước khi đội mất niềm tin vào nó, và biết khi nào KHÔNG viết test là quyết định đúng.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/13 mục · còn khoảng 5 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Kiểm thử tự động là gì?

Test tự động là mã kiểm tra mã. Nó chạy mỗi lần có thay đổi, nên nó bắt được thứ con người không kiểm lại nổi mỗi ngày.

Câu hỏi hữu ích với PM không phải “độ phủ bao nhiêu phần trăm” mà là “đội có dám sửa phần này không?” Sợ sửa là triệu chứng thiếu test.

Ba tầng test — mỗi tầng trả lời một câu khác nhau

Tầng	Trả lời câu	Nhanh cỡ nào	Nên chiếm bao nhiêu
Đơn vị (unit)	Hàm này tính đúng chưa?	Mili giây	Nhiều nhất
Tích hợp	Hai phần ghép lại còn đúng không?	Giây	Vừa phải
Đầu-cuối (E2E)	Người dùng làm được việc đó không?	Phút	Ít nhất, chỉ luồng quan trọng

Đảo ngược tỷ lệ này là lý do phổ biến nhất khiến bộ test chạy 40 phút và không ai đợi nữa.

Khi nào bạn gặp chuyện này

Tình huống	Bạn làm gì	Nếu không
Bộ test chạy 35 phút, mọi người bấm merge trước khi nó xong.	Cắt E2E xuống còn luồng sống còn, đẩy phần còn lại xuống tầng thấp hơn.	Test tồn tại nhưng không bảo vệ gì — chi phí giữ mà không có lợi ích.
Một test fail ngẫu nhiên mỗi vài lần chạy, ai cũng chạy lại cho qua.	Đánh dấu và sửa trong tuần, hoặc xoá. Test chập chờn tệ hơn không có test.	Đội học được rằng đỏ không có nghĩa gì — rồi bỏ qua cả lần đỏ thật.
Đội nói "phần này không ai dám đụng".	Viết test bao quanh phần đó TRƯỚC khi refactor, dù chỉ vài test ở mức tích hợp.	Phần đó đóng băng vĩnh viễn, và mọi tính năng mới phải đi vòng qua nó.

Bắt đầu từ đâu khi gần như chưa có test

Chọn phần đắt nhất khi hỏng — thanh toán, đăng nhập, dữ liệu khách.
Viết E2E cho đúng một luồng sống còn. Một cái thôi, chạy trong CI.
Mỗi lần sửa bug, viết một test tái hiện bug đó trước khi sửa.
Đặt trần thời gian chạy (ví dụ 10 phút) và giữ nó như một ràng buộc thật.
Không đặt mục tiêu phần trăm độ phủ. Nó khuyến khích test rỗng.

Sai lầm thường gặp

Sai lầm	Vì sao hỏng	Làm thay bằng
Đặt KPI độ phủ	Sinh ra test không kiểm tra gì, chỉ chạy qua code.	Đo bằng "dám sửa không", không bằng phần trăm.
Quá nhiều E2E	Chậm và chập chờn; đội bỏ qua.	Đẩy xuống tầng thấp hơn.
Để test chập chờn sống	Phá niềm tin vào toàn bộ bộ test.	Sửa trong tuần hoặc xoá.
Viết test sau cùng, khi còn thời gian	Không bao giờ còn thời gian.	Test đi cùng PR, là một phần của định nghĩa xong.

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Engineering Manager	Bạn bảo vệ thời gian viết test trước áp lực deadline — không ai khác làm được.
Product Manager	Bạn thấy hậu quả: đội sợ sửa nghĩa là mọi ước lượng đều phồng lên. Hỏi "phần này có test chưa" là câu hỏi sản phẩm.
QA / Tester	Bạn quyết cái gì tự động và cái gì vẫn nên kiểm tay.
Technical Product Manager	Bạn đọc được thời gian chạy CI như một chỉ số tốc độ giao hàng.

Definition of done — dấu hiệu bạn đã đạt

Bộ test chạy dưới trần thời gian đã đặt.
Không có test chập chờn nào sống quá một tuần.
Mỗi bug đã sửa có một test tái hiện nó.
Đội dám refactor phần quan trọng nhất.

Tự động hoá cái gì — và cái gì không nên

Loại kiểm thử	Tự động hoá?	Vì sao
Logic nghiệp vụ, tính toán	Luôn luôn	Chạy nhanh, ổn định, bắt hồi quy tốt nhất
Luồng quan trọng nhất của người dùng	Có	Chậm hơn nhưng bảo vệ thứ không được phép hỏng
Tích hợp với hệ thống ngoài	Có, với bản giả lập	Dùng hệ thống thật làm kiểm thử chậm và hay hỏng vặt
Giao diện chi tiết, màu sắc, khoảng cách	Hiếm khi	Đổi liên tục; chi phí bảo trì vượt giá trị
Trải nghiệm, cảm nhận	Không	Máy không đánh giá được
Ca chạy một lần rồi thôi	Không	Kiểm tay nhanh hơn viết tự động

Nguyên tắc chọn: tự động hoá thứ chạy đi chạy lại và có đáp án rõ ràng. Kiểm thử tự động cho thứ đổi mỗi tuần sẽ tốn nhiều công bảo trì hơn giá trị nó mang lại — và rồi bị tắt đi.

Hình tháp — nhiều ở dưới, ít ở trên

Tầng	Số lượng	Tốc độ	Bắt được gì
Đơn vị	Nhiều nhất	Mili giây	Logic sai trong một hàm
Tích hợp	Vừa	Giây	Các phần ghép lại không khớp
Đầu cuối	Ít nhất	Phút	Luồng người dùng thật sự hỏng

Hình tháp lộn ngược là bệnh phổ biến: nhiều kiểm thử đầu cuối, ít kiểm thử đơn vị. Hậu quả là bộ kiểm thử chạy 40 phút, hay hỏng vặt, và đội bắt đầu bỏ qua kết quả — lúc đó nó tệ hơn không có, vì nó tạo cảm giác an toàn giả.

Dấu hiệu cần sửa ngay: khi có người nói "chạy lại xem sao" và nó đạt. Một kiểm thử lúc đạt lúc không thì không khẳng định gì — hoặc sửa nó, hoặc xoá nó. Giữ lại là cách nhanh nhất để cả bộ mất uy tín.

Vì sao người làm sản phẩm cần quan tâm

Nó quyết định tốc độ giao hàng của bạn. Không có kiểm thử tự động, mỗi lần phát hành cần kiểm tay nhiều ngày — và tần suất phát hành sẽ giảm dần.
Nó quyết định bạn có dám sửa không. Đội không có lưới an toàn sẽ tránh động vào mã nguồn cũ, và nợ kỹ thuật tích tụ từ đó.
Nó là khoản đầu tư có chi phí trả trước. Nếu bạn ép tiến độ bằng cách bỏ kiểm thử, bạn đang vay với lãi suất cao — và hoá đơn đến trong vòng hai quý.

Câu hỏi nên hỏi đội: "Nếu chúng ta cần phát hành gấp một bản sửa lỗi vào chiều nay, mất bao lâu để chắc rằng nó không phá gì khác?" Câu trả lời cho bạn biết tình trạng thật của bộ kiểm thử.

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Product Owner	Hiểu vì sao bỏ kiểm thử để kịp tiến độ là khoản vay lãi cao
QA	Chọn đúng thứ để tự động hoá, và giữ hình tháp không lộn ngược
Engineer	Kiểm thử là thứ cho phép bạn sửa mã nguồn cũ mà không sợ
Team Lead	Kiểm thử hay hỏng vặt phải sửa hoặc xoá, không được để tồn tại
Delivery Manager	Thời gian để chắc rằng một bản sửa an toàn là chỉ số tốc độ thật

Hiccups thường gặp và cách xử lý

Hiccup	Vì sao xảy ra	Xử lý
Bộ kiểm thử chạy 40 phút, không ai chờ	Hình tháp lộn ngược	Chuyển phần lớn xuống tầng đơn vị; giữ tầng đầu cuối cho luồng quan trọng nhất
Kiểm thử hỏng vặt, đội quen bỏ qua	Phụ thuộc thời gian, dữ liệu hoặc hệ thống ngoài	Sửa hoặc xoá — một bộ kiểm thử không đáng tin tệ hơn không có
Tỉ lệ bao phủ cao mà vẫn nhiều lỗi	Kiểm thử chạy qua code nhưng không khẳng định gì	Đo bằng lỗi bị bắt, không đo bằng tỉ lệ bao phủ
Viết kiểm thử sau khi xong tính năng	Bị coi là việc phụ	Kiểm thử là một phần của "xong", không phải việc làm thêm nếu còn thời gian
Kiểm thử giao diện hỏng mỗi lần đổi màu	Tự động hoá nhầm lớp	Không tự động hoá chi tiết giao diện; tự động hoá hành vi
Bỏ kiểm thử để kịp tiến độ	Áp lực ngắn hạn	Ghi nợ và đặt hạn trả; nợ không ghi là nợ không ai trả

Definition of done

Tự động hoá thứ chạy lặp lại và có đáp án rõ ràng; không tự động hoá thứ đổi liên tục.
Hình tháp đúng chiều: nhiều kiểm thử đơn vị, ít kiểm thử đầu cuối.
Không có kiểm thử nào lúc đạt lúc không — sửa hoặc xoá.
Bộ kiểm thử chạy đủ nhanh để đội thật sự chạy nó mỗi lần.
Trả lời được: mất bao lâu để chắc một bản sửa gấp không phá gì khác.