Mỗi lần có người hỏi về nghề kiểm thử phần mềm, chúng tôi lại thấy một điều lặp đi lặp lại. Phần lớn mọi người đều tò mò về việc một QA tester thật sự làm gì trong ngày. Có bạn hỏi thẳng rằng nghề này có phải chỉ ngồi bấm thử rồi báo lỗi không. Có bạn lại nghĩ công việc này nhàn vì không viết code. Vì những câu hỏi cứ quay lại, đội ngũ bên mình quyết định kể về một ngày làm việc điển hình, theo đúng trình tự thời gian mà chúng tôi đã từng trải qua.

Vì sao nhiều người hình dung sai về nghề QA?

Hình ảnh phổ biến nhất về QA là ngồi trước màn hình, thử vài thao tác, thấy lỗi thì chuyển cho lập trình viên. Nghe qua thì có vẻ đơn giản. Nhưng khi đi vào thực tế, bạn sẽ thấy người QA giỏi phải hiểu sản phẩm gần bằng người đã xây nên nó. Họ cần biết người dùng thật sẽ thao tác ra sao, kể cả những người không bao giờ đọc hướng dẫn và luôn bấm nhầm đúng chỗ.

Nhiều bạn mới ra trường vì thiếu thông tin nên còn mơ hồ về nghề. Người đang muốn chuyển ngành thì hay vướng vào hai kiểu nghĩ trái chiều. Có người cho rằng công việc nhẹ vì không đụng đến code. Có người lại ngại, nghĩ rằng cả ngày chỉ đối diện với checklist khô khan. Cả hai hình dung này đều lệch khá xa so với những gì chúng tôi từng thấy trong các dự án.

Một ngày làm việc của QA tester diễn ra thế nào?

Ở những dự án đội ngũ từng đồng hành, một ngày của QA thường mở đầu gần giống nhau. Việc đầu tiên là rà lại danh sách lỗi còn tồn đọng. Không phải lỗi nào cũng kịp sửa, nên người QA phải sắp xếp thứ tự ưu tiên. Lỗi nào làm hỏng trải nghiệm của phần đông người dùng thì đẩy lên đầu. Lỗi nào có thể để sang bản cập nhật sau mà không gây hại nhiều thì xếp xuống dưới.

Việc sắp xếp này dựa trên hai tiêu chí. Thứ nhất là mức độ nghiêm trọng, tức lỗi làm hỏng chức năng nào và hỏng đến mức nào. Thứ hai là mức độ khẩn cấp, tức cần xử lý gấp đến đâu trước ngày phát hành. Hai yếu tố này không phải lúc nào cũng đi cùng nhau. Một lỗi nhỏ nằm ngay trên luồng thanh toán có thể cần ưu tiên hơn một lỗi lớn nhưng chỉ xuất hiện ở trang cài đặt ít ai dùng. QA phải cân nhắc từng trường hợp, và đôi khi phải trao đổi với cả nhóm để thống nhất.

Buổi sáng: chạy kịch bản kiểm thử và ghi nhận kết quả

Sau phần rà soát đầu giờ, công việc chính của buổi sáng là kiểm thử theo kịch bản. Trong nghề, người ta gọi đây là test case, tức danh sách các bước cụ thể: làm gì, nhập gì, kỳ vọng kết quả ra sao. QA chạy từng bước và đối chiếu kết quả thực tế với kỳ vọng. Chênh lệch nào xuất hiện thì ghi lại ngay. Đừng để trí nhớ gánh việc đó, vì đến chiều rất dễ quên chi tiết.

Ghi nhận kết quả cũng không chỉ là đúng hoặc sai. Một báo cáo lỗi tốt phải mô tả rõ các bước tái hiện, theo đúng thứ tự để người khác làm lại được. Cần nêu môi trường kiểm thử như trình duyệt, hệ điều hành và phiên bản ứng dụng. Kèm ảnh chụp màn hình hoặc đoạn video ngắn thì càng tốt. Thiếu chi tiết nào, lập trình viên sẽ mất thêm thời gian nhắn hỏi lại, và chính QA lại phải quay về tái hiện từ đầu.

Buổi trưa: những vòng kiểm thử hồi quy lặp đi lặp lại

Có những ngày, một phần việc lặp lại đến mức khá nhàm chán. Điển hình là kiểm thử hồi quy sau mỗi lần cập nhật. Đây là việc chạy lại các kịch bản cũ để chắc chắn bản sửa mới không vô tình làm hỏng chức năng vốn đã ổn định. Nghe thì đơn giản, nhưng với hệ thống có hàng trăm chức năng, khối lượng này không nhỏ chút nào.

Phần việc máy móc này khá tốn sức, nên nhiều đội chọn tự động hóa một phần. Đội ngũ bên mình cũng từng chia sẻ cách giảm bớt việc lặp lại mỗi ngày nhờ giải pháp AI, và tinh thần đó cũng áp dụng được ở đây. Giao phần lặp lại cho công cụ, còn thời gian của con người nên dành cho những lỗi khó đoán hơn, chẳng hạn các tình huống người dùng thao tác lệch chuẩn mà kịch bản chưa từng nghĩ tới.

Buổi chiều: họp nhanh với đội dev và làm việc trên máy kiểm thử

Gần như mỗi ngày, QA đều có một buổi họp ngắn với đội phát triển, thường gọi là daily standup, chỉ kéo dài khoảng mười lăm phút. Mỗi người nói nhanh hôm qua đã làm gì, hôm nay định làm gì và đang vướng chỗ nào. QA tận dụng buổi này để báo các lỗi ưu tiên cao, tránh tình trạng lỗi nghiêm trọng nằm trong danh sách vài ngày mà không ai để ý.

Nếu sản phẩm là ứng dụng nội bộ, QA đôi khi phải truy cập từ xa vào một máy kiểm thử dùng chung. Thay vì cài đặt mọi thứ trên máy cá nhân, cả đội dùng chung một môi trường để cấu hình được đồng nhất. Cách này hạn chế tình trạng “trên máy tôi chạy được” vốn rất hay gặp. Bạn nào chưa quen thao tác này có thể xem hướng dẫn truy cập máy tính chia sẻ để kiểm thử từ xa, bên mình đã tổng hợp khá chi tiết các bước. Khi tìm hiểu thêm về cách công cụ tự động phối hợp với kiểm thử, bạn cũng nên đọc qua ranh giới giữa tự động hóa và việc con người trực tiếp làm để hiểu vì sao có những việc không nên giao hoàn toàn cho máy.

Cuối ngày: cập nhật trạng thái trước khi tắt máy

Trước khi kết thúc, QA thường cập nhật lại trạng thái các lỗi đã báo. Lỗi nào lập trình viên vừa sửa xong thì cần kiểm tra lại, gọi là retest. Lỗi nào còn đang xử lý thì giữ nguyên trạng thái chờ. Bước này nhỏ nhưng quan trọng, vì nó giúp cả nhóm biết chính xác sản phẩm đang ở giai đoạn nào, và sáng hôm sau ai cũng bắt đầu từ một bức tranh rõ ràng.

Những kỹ năng giúp bạn trụ vững với nghề QA

Kỹ năng đầu tiên, và có lẽ quan trọng nhất, là tư duy logic đi cùng sự tỉ mỉ. Lỗi phần mềm hiếm khi nằm ngay trên đường đi chính. Chúng thường ẩn trong những tình huống ít gặp: nhập sai định dạng, mất mạng giữa chừng, hay bấm liên tiếp hai lần quá nhanh. Người QA giỏi là người nghĩ ra các tình huống lệch chuẩn đó trước khi người dùng thật vô tình chạm tới.

Tỉ mỉ không có nghĩa là chậm chạp. Đội ngũ chúng tôi từng gặp một bạn QA mới vào nghề kiểm tra quá kỹ đến mức trễ hạn báo lỗi cho bản phát hành. Tỉ mỉ đúng cách là biết ưu tiên: soi kỹ phần lõi ảnh hưởng đến nhiều người dùng, còn phần phụ ít rủi ro thì lướt nhanh hơn để dành thời gian cho chỗ quan trọng.

Giao tiếp quyết định QA có được đội dev tin hay không

Kỹ năng thứ hai là giao tiếp, và đây là phần nhiều người ngoài nghề không ngờ tới. QA không chỉ báo lỗi rồi thôi. Họ phải giải thích cho lập trình viên hiểu vì sao đây là lỗi thật và nó ảnh hưởng ra sao. Đôi khi họ còn phải trình bày với người quản lý sản phẩm rằng lỗi này đủ nghiêm trọng để cân nhắc lùi ngày phát hành.

Giao tiếp tốt còn thể hiện ở cách viết báo cáo lỗi. Một báo cáo rõ ràng, khách quan, không chỉ trích cá nhân sẽ giúp không khí làm việc dễ chịu hơn. Ngược lại, báo cáo mơ hồ hoặc giọng văn gay gắt rất dễ gây hiểu lầm, trong khi mục tiêu chung vẫn chỉ là làm sản phẩm tốt hơn cho người dùng.

Vài kỹ năng bổ trợ nên rèn dần

• Hiểu cơ bản cách hệ thống vận hành, kể cả khi không trực tiếp viết code, để đoán lỗi có thể nằm ở đâu.
• Làm quen với các công cụ quản lý lỗi phổ biến như Jira hoặc TestRail để phối hợp với cả nhóm trơn tru hơn.
• Biết lúc nào nên để công cụ tự động chạy lại kịch bản cũ, lúc nào cần con người trực tiếp kiểm tra bằng mắt.

Không ai có đủ những kỹ năng này ngay từ đầu. Phần lớn người làm QA giỏi hiện nay cũng từng bối rối những tháng đầu, từng báo lỗi thiếu chi tiết và từng tranh luận sai chỗ với dev. Khác biệt nằm ở chỗ họ chịu rút kinh nghiệm sau mỗi lần vấp, rồi dần hình thành cách làm việc của riêng mình.

Nếu đang cân nhắc theo nghề QA, hãy bắt đầu từ một sản phẩm quen thuộc

Hiểu quy trình làm việc thật của QA tester giúp người đang cân nhắc nghề này bớt mơ hồ, và thực tế hơn nhiều so với việc chỉ đọc mô tả công việc trên tin tuyển dụng. QA không phải nghề chỉ ngồi bấm nút tìm lỗi, cũng không phải nghề nhàn vì không cần biết code. Nó đòi hỏi tư duy phản biện, sự kiên trì với chi tiết nhỏ và khả năng làm việc với nhiều kiểu tính cách khác nhau.

Nếu bạn thật sự tò mò, đừng chờ có bằng cấp mới bắt đầu. Hãy chọn một ứng dụng dùng mỗi ngày và thử đóng vai người kiểm thử: bấm những thao tác lạ, nhập dữ liệu sai định dạng, quan sát hệ thống phản ứng ra sao rồi ghi lại mọi điều bất thường. Trải nghiệm nhỏ này làm đều đặn trong vài tuần sẽ cho bạn cảm nhận thật hơn bất kỳ bài mô tả nghề nghiệp nào, và đó là điều đội ngũ chúng tôi tin là đáng làm nhất trước khi quyết định theo nghề.