Tester Fresher cần học kỹ năng mềm nào để làm việc hiệu quả trong team Agile?

2 tháng trước · 10 phút đọc

Tại sao kỹ năng mềm quan trọng không kém kỹ năng kỹ thuật?

Mình từng nghĩ: học viết test case tốt, biết dùng Jira, hiểu regression testing là đủ để đi làm. Kết quả? Sprint đầu tiên mình báo bug theo kiểu "trang này bị lỗi" - dev nhìn 5 phút, quay lại hỏi "lỗi ở đâu, bước nào tái hiện, môi trường nào?" Mình ngớ người. Không phải vì không biết test, mà vì không biết cách truyền đạt.

Trong môi trường Agile, tester không làm việc một mình. Mỗi sprint 2 tuần, bạn sẽ họp daily standup mỗi sáng, thảo luận requirement với Product Owner (PO), phối hợp chặt với dev để verify bug. Nếu giao tiếp không rõ, cả team chậm lại - không chỉ riêng bạn.

346162 Trong Agile, tester kết nối trực tiếp với dev, PO và cả team - không phải làm việc đơn độc

Có một con số đáng chú ý: 13.2% dự án CNTT thất bại do communication (giao tiếp kém) (Standish Group CHAOS Report) trong các dự án phần mềm thất bại có nguyên nhân chính từ giao tiếp kém, không phải lỗi kỹ thuật. Với tester fresher, kỹ năng mềm còn giúp bạn xây dựng uy tín nhanh hơn - dev tin tưởng bug report của bạn, PO hiểu bạn đang test gì, team manager thấy bạn chủ động.

Bài này mình tập trung vào 5 kỹ năng mềm cụ thể nhất, kèm ví dụ câu nói thực tế để bạn dùng luôn.

Giao tiếp khi báo bug - kỹ năng số 1 không thể thiếu

Bug report là sản phẩm trực tiếp của tester. Dev đọc bug report của bạn để biết phải fix gì, PO đọc để hiểu mức độ ảnh hưởng, manager đọc để ưu tiên sprint. Báo bug mà thiếu thông tin, dev sẽ mất thêm 30 phút chỉ để tái hiện lỗi.

Mình thấy fresher hay mắc 3 lỗi này:

Lỗi 1 - Mô tả quá chung: "Nút thanh toán không hoạt động" - dev không biết trình duyệt nào, bước nào trước đó, dữ liệu gì.

Lỗi 2 - Không ghi expected vs actual: Bạn thấy kết quả khác kỳ vọng, nhưng không ghi rõ hệ thống nên ra gì, thực tế ra gì.

Lỗi 3 - Thiếu steps to reproduce: "Tôi click vào giỏ hàng thì lỗi" - không ai reproduce được.

346163 Bug report đủ thông tin giúp dev fix nhanh hơn, không mất thời gian đi hỏi lại

Đây là cấu trúc một bug report rõ ràng bạn có thể dùng ngay:

Tiêu đề: [Trang thanh toán] Nút "Đặt hàng" không phản hồi khi giỏ hàng có sản phẩm hết hàng

Môi trường: Chrome 120, Windows 11, staging server
Bước tái hiện:
1. Đăng nhập tài khoản user thường
2. Thêm sản phẩm "Áo thun XL" (đang hết hàng) vào giỏ
3. Vào trang thanh toán, click "Đặt hàng"

Kết quả thực tế: Nút không phản hồi, không có thông báo lỗi
Kết quả kỳ vọng: Hiển thị thông báo "Sản phẩm X đã hết hàng, vui lòng xóa khỏi giỏ"
Độ ưu tiên: High - ảnh hưởng luồng thanh toán chính

Khi gặp dev, thay vì nói "cái này bị lỗi", hãy nói: "Mình tìm được bug ở trang thanh toán, mình đã note steps to reproduce và đính kèm video, bạn xem Jira ticket [TK-123] nhé." Câu đó ngắn nhưng đủ - dev biết vấn đề ở đâu, biết có đủ thông tin để xem.

Hỏi requirement đúng cách - đừng sợ hỏi nhưng hỏi cho thông minh

Requirement mơ hồ là chuyện thường ngày trong dự án thực tế. PO viết: "Trang profile cho phép user cập nhật thông tin cá nhân." Nghe có vẻ rõ, nhưng tester phải hỏi thêm: cập nhật được những trường nào? Có giới hạn ký tự không? Upload avatar có validate định dạng file không? Thay đổi email có cần xác nhận không?

Fresher hay rơi vào 2 thái cực: không dám hỏi vì sợ bị cho là không hiểu, hoặc hỏi lung tung không có chuẩn bị làm PO bực bội.

346164 Chuẩn bị câu hỏi trước khi gặp PO giúp buổi họp ngắn hơn và hiệu quả hơn

Cách mình thường làm: đọc requirement, tự viết ra test case draft trước, chỗ nào không chắc mới đánh dấu câu hỏi. Khi gặp PO, mình nói:

"Mình đọc ticket về trang profile. Mình có 3 điểm cần xác nhận để viết test case đầy đủ hơn: (1) Field email có thể thay đổi không, hay chỉ thay đổi được tên và số điện thoại? (2) Avatar có giới hạn dung lượng không? (3) Sau khi cập nhật thành công, redirect về trang nào?"

Câu đó thể hiện bạn đã đọc kỹ requirement, đã suy nghĩ trước, và câu hỏi có mục đích cụ thể - không phải hỏi vì lười đọc.

Một mẹo nhỏ: khi requirement có điều kiện biên không rõ, hỏi theo dạng "Nếu user làm X thì hệ thống nên phản hồi Y hay Z?" Câu hỏi dạng scenario này giúp PO hình dung và trả lời nhanh hơn câu hỏi trừu tượng.

Nói gì trong daily standup - ngắn, rõ, không lan man

Daily standup là cuộc họp 15 phút mỗi sáng trong Agile. Mỗi người trả lời 3 câu: làm gì hôm qua, làm gì hôm nay, có blocker gì không. Nghe đơn giản, nhưng fresher hay bị lạc đề hoặc nói thiếu thông tin.

Ví dụ fresher hay nói: "Hôm qua mình test... xong mấy cái... hôm nay mình tiếp tục test thêm." Cả team không biết bạn đang ở đâu trong sprint, test feature nào, có vấn đề gì không.

346165 Standup rõ ràng giúp cả team biết tiến độ và unblock nhau đúng lúc

Cấu trúc chuẩn cho tester trong standup:

Hôm qua: "Mình hoàn thành test case cho feature đăng nhập - 12/15 test cases passed, có 2 bug ở luồng forgot password, đã log lên Jira."

Hôm nay: "Mình sẽ test feature đăng ký tài khoản, dự kiến xong trước 3h chiều."

Blocker (nếu có): "Mình đang chờ staging server được deploy version mới từ dev team. Nếu trước 10h chưa deploy được, mình cần nhờ bạn Nam support."

Nếu không có blocker thì nói: "Không có blocker." Đừng im lặng hay nói "bình thường" - câu đó không có thông tin.

Một điểm mình hay nhắc fresher: đừng sợ báo blocker. Báo sớm giúp team xử lý kịp thời. Giấu blocker đến cuối ngày mới nói thì cả team mất thời gian.

Hợp tác với developer - không phải địch thủ, là đồng đội

Có một hiểu lầm phổ biến với fresher: tester tìm bug để "bắt lỗi" dev. Tư duy đó tạo ra căng thẳng không cần thiết và làm chậm cả team.

Thực tế? Tester và dev cùng mục tiêu: sản phẩm chạy đúng trước khi đến tay user. Bug được phát hiện sớm ở test thì dễ fix hơn nhiều so với bug nổ production.

Một tình huống hay xảy ra: tester log bug, dev comment "đây không phải bug, đây là feature". Fresher thường không biết xử lý thế nào.

346166 Thảo luận trực tiếp với dev giúp giải quyết bug nhanh hơn comment qua lại trên Jira

Cách xử lý bình tĩnh và hiệu quả:

"Mình log bug này dựa trên requirement ticket [TK-50] ghi là 'Hệ thống phải validate email đúng format'. Nếu behavior hiện tại là intended, bạn có thể nhờ PO confirm để mình update lại expected result trong test case không?"

Câu đó không tranh luận, không nhường bộ, nhưng dẫn đến hành động tiếp theo rõ ràng. Bạn có evidence (requirement), bạn đề xuất giải pháp (confirm với PO), không ai bị mất mặt.

Về ngôn ngữ hàng ngày với dev: thay "cái này sai rồi" bằng "mình thấy kết quả khác với requirement, bạn xem giúp mình được không?" Khác nhau rất nhỏ nhưng ảnh hưởng đến không khí làm việc cả ngày.

Mình không cần code giỏi để làm việc tốt với dev. Chỉ cần nói bằng evidence, đề xuất bước tiếp theo, không mang cảm xúc vào technical discussion. Ba điều đó đủ để được dev tôn trọng.

Viết tài liệu test case dễ hiểu - người khác đọc cũng test được

Test case của bạn không chỉ cho mình đọc. Khi bạn nghỉ phép, đồng nghiệp phải dùng test case đó để test. Khi onboard người mới, họ đọc test case để hiểu luồng hệ thống. Test case viết tốt = tài liệu sống của dự án.

Một test case viết kém thường có dạng: "Test chức năng đăng nhập - pass". Không ai biết bạn test gì, điều kiện nào, input nào.

346167 Test case rõ ràng giúp cả team reproduce và verify mà không cần hỏi lại người viết

Test case tốt cần đủ 5 thành phần:

Thành phần	Ví dụ
Test case ID	TC_LOGIN_003
Mô tả ngắn	Đăng nhập với email chưa verify
Precondition	Tài khoản tồn tại nhưng chưa xác nhận email
Steps	1. Mở /login 2. Nhập email+pass đúng 3. Click Đăng nhập
Expected result	Hiển thị thông báo "Vui lòng xác nhận email trước khi đăng nhập"

Khi viết steps, dùng động từ hành động cụ thể: "Nhập", "Click", "Chọn", "Điều hướng đến" - không viết "Vào đăng nhập" hay "Thực hiện đăng nhập" vì không rõ làm gì.

Một mẹo nhỏ: sau khi viết xong, thử đọc lại với tư duy "mình chưa biết gì về feature này". Nếu bước nào không tự hiểu được, thêm chi tiết vào. Bước đó mất thêm 2 phút nhưng tiết kiệm cả buổi giải thích sau này.