Tác giả
Nói mình làm tester, câu hỏi tiếp theo gần như luôn là: "à, ngồi bấm thử app hả?"
Câu đó không sai. Nó chỉ mô tả đúng khoảng một phần tư công việc, và là phần dễ nhất.
Bài này trả lời manual testing là gì, rồi đi thẳng vào bốn nhóm việc thật sự chiếm hết một ngày — vì phần đó là phần không có trong định nghĩa sách vở.
Manual testing là gì?
Manual testing là kiểm thử phần mềm do người trực tiếp thực hiện: mở phần mềm ra, làm đúng các bước một người dùng thật sẽ làm, rồi so kết quả nhận được với kết quả đáng lẽ phải có.
Chỗ khác với automation testing: automation là viết mã để máy tự làm lại các bước đó. Manual thì con người làm.
Nói vậy dễ dẫn tới một kết luận sai: manual là làm tay nên thấp hơn, tạm thời, chờ ngày bị thay. Không phải. Hai thứ giải quyết hai việc khác nhau.
Máy làm rất tốt việc lặp lại chính xác một bước đã biết, hàng nghìn lần, không mỏi, không bỏ sót. Người làm rất tốt việc nhận ra thứ chưa ai nghĩ tới sẽ sai.
Khác biệt đó không nhỏ. Một bộ kiểm thử tự động chỉ tìm được lỗi mà ai đó đã nghĩ ra trước và viết thành mã kiểm tra. Nó chạy xanh toàn bộ trong khi màn hình lệch hẳn một cột, câu thông báo lỗi vô nghĩa, hoặc luồng nghiệp vụ dẫn người dùng vào chỗ không đi tiếp và không lùi lại được. Máy không có khái niệm "cái này vô lý".
Bốn nhóm việc, và bấm thử chỉ là một
- Đọc và hiểu yêu cầu.
Trước khi test được, phải biết "đúng" nghĩa là gì. Nghe hiển nhiên, nhưng đây là chỗ ngốn nhiều thời gian nhất và ít ai ngờ tới.
Tài liệu yêu cầu thường thiếu, đôi khi mâu thuẫn với chính nó, và không ít lần là không có. Việc của tester ở bước này là đọc kỹ đến mức phát hiện ra chỗ mâu thuẫn — và tìm ra nó ở đây rẻ hơn rất nhiều so với tìm ra sau khi đã code xong.
Một mâu thuẫn phát hiện lúc đọc tài liệu tốn một tin nhắn để giải quyết. Cùng mâu thuẫn đó phát hiện sau khi đã lập trình xong tốn một vòng sửa, một vòng test lại, và đôi khi một cuộc họp.
Và khi không có tài liệu nào cả thì vẫn có cách làm.
Nghĩ trước xem cần thử những gì, bằng dữ liệu nào, theo thứ tự nào. Đây là phần trí óc thật của nghề.
Người mới thường bỏ qua bước này và nhảy thẳng vào bấm. Kết quả là test được đúng những gì nghĩ ra tại chỗ, tức là những đường đi hiển nhiên nhất — chính là những đường lập trình viên đã tự thử trước khi giao.
Với form nhập liệu thì có một bộ nhóm kiểm tra dùng lại được cho gần như mọi chức năng.
- Thực hiện.
Chạy qua các ca đã thiết kế, ghi lại kết quả thật. Đây là phần người ngoài nhìn thấy, và là phần duy nhất trông giống "bấm thử app".
Viết lại lỗi sao cho người sửa hiểu được và tái hiện được. Viết dở thì lỗi bị trả về kèm câu "máy tôi chạy bình thường", và cả vòng lặp bắt đầu lại.
Mức nghiêm trọng và mức ưu tiên là hai trường riêng, và lẫn chúng vào nhau là nguồn của phần lớn tranh cãi quanh bảng lỗi.
Bốn nhóm này không chia đều. Hai nhóm đầu — đọc yêu cầu và thiết kế ca kiểm thử — là nơi chất lượng thật sự được quyết định, và cũng là nơi người ngoài nghề không biết là có.
Những kỹ thuật thật sự dùng hàng ngày
Trường lớp dạy một danh sách rất dài. Đi làm thì có vài thứ dùng đi dùng lại.
- Phân vùng tương đương. Một ô nhập chấp nhận số từ 1 đến 100. Không cần thử cả trăm số, vì 50 và 51 sẽ đi qua cùng một đoạn mã. Chia thành các vùng mà mọi giá trị trong vùng được xử lý giống nhau, rồi thử một giá trị mỗi vùng.
- Giá trị biên. Lỗi tụ ở hai đầu, không ở giữa. Với ô chấp nhận 1–100 thì chỗ đáng thử nhất là 0, 1, 100, 101. Đây là kỹ thuật cho ra nhiều lỗi nhất so với công bỏ ra, vì lỗi lập trình ở biên thường là sai một dấu lớn hơn thành lớn hơn hoặc bằng.
- Bảng quyết định. Khi kết quả phụ thuộc nhiều điều kiện cùng lúc, kẻ bảng ra. Ba điều kiện đúng-sai là tám tổ hợp; nghĩ trong đầu thì chắc chắn sót, kẻ ra thì không.
- Kiểm thử tự do. Không theo ca có sẵn. Dùng hiểu biết về hệ thống để đi tìm chỗ yếu, vừa làm vừa nghĩ ra bước tiếp theo dựa trên thứ vừa thấy. Nghe như làm bừa nhưng đây là kỹ thuật cần nhiều kinh nghiệm nhất, và thường ra những lỗi lạ nhất — loại lỗi mà không ai nghĩ tới nên không ai viết ca kiểm thử cho nó.
Bốn kỹ thuật, và cái đầu tiên cần học nhất là giá trị biên. Nó đơn giản, dùng được cho gần như mọi ô nhập, và cho kết quả ngay.
Manual testing có bị AI hay automation thay không
Câu này bây giờ ai vào nghề cũng hỏi. Trả lời tử tế thì phải tách ra ba phần: chỗ chắc, chỗ cũng chắc, và chỗ không chắc.
- Chắc: việc lặp lại và đã biết trước kết quả thì máy làm tốt hơn người. Chạy lại hai trăm ca kiểm thử cũ mỗi lần ra bản mới là việc không nên để người làm — người sẽ mỏi, sẽ nhìn nhanh cho xong, và sẽ bỏ sót đúng lúc quan trọng nhất.
- Cũng chắc: phần nghĩ ra cần thử gì vẫn là việc của người. Máy chạy được ca kiểm thử. Nó không tự biết một luồng nghiệp vụ là vô lý, không tự biết câu thông báo lỗi khiến người dùng bối rối, và không tự biết một quy tắc trong tài liệu mâu thuẫn với quy tắc ở trang trước.
- Không chắc: ranh giới giữa hai vùng trên sẽ dịch tới đâu, và nhanh thế nào. Ai nói chắc câu này là đang đoán, kể cả khi nói rất tự tin.
Điều dùng được ngay: nếu công việc của bạn đang toàn là chạy lại ca kiểm thử cũ, đó là phần đáng lo. Nếu công việc của bạn có phần đọc yêu cầu, thiết kế ca kiểm thử và tranh luận về việc thế nào là đúng — phần đó khó thay hơn nhiều.
Muốn vào nghề thì bắt đầu từ đâu
Ba thứ, theo thứ tự.
- Học cách nghĩ ra tình huống trước khi học công cụ:
Cầm một ứng dụng bất kỳ đang dùng hàng ngày, chọn một chức năng, viết ra hai mươi tình huống cần thử. Làm được việc này thì mọi công cụ chỉ là chuyện học vài buổi. Không làm được thì học công cụ trước cũng không dùng vào đâu.
- Học viết cho người khác đọc:
Nghề này sản phẩm là chữ: ca kiểm thử để người khác chạy lại, báo cáo lỗi để người khác sửa. Viết mơ hồ thì công sức tìm ra lỗi mất trắng ở bước cuối.
- Học đủ kỹ thuật để nhìn được xuống dưới bề mặt:
Không cần biết lập trình để làm tester. Nhưng biết gọi một yêu cầu API, đọc được một câu truy vấn dữ liệu, xem được log — những thứ đó mở ra một lớp lỗi mà test qua giao diện không bao giờ thấy.
Thứ không cần vội: chứng chỉ. Nó có giá trị ở một số công ty và ở việc buộc bạn học có hệ thống. Nó không thay được việc đã từng tìm ra một lỗi thật và viết lại được cho người khác hiểu.
Còn chuyện QA, QC, Tester, QE khác nhau thế nào thì đừng để chức danh làm bạn rối.
Nói lại một câu
Manual testing không phải bấm thử app. Nó là công việc nghĩ ra những cách một hệ thống có thể sai, rồi chứng minh được điều đó theo cách người khác kiểm tra lại được.
Phần bấm là phần dễ nhất. Phần nghĩ mới là nghề.
