Kỹ Năng Mềm Tester: Làm Việc Team Và Communication Trong Agile
6 tháng trước · 8 phút đọc
Tại sao kỹ năng mềm quyết định tester sống hay chết trong team?
Mình nhớ lần đầu vào team Agile, nghĩ nhiệm vụ tester chỉ là tìm bug rồi báo. Kết quả? Dev không hiểu bug mình báo là gì, BA phàn nàn mình không đọc requirement kỹ, standup 15 phút mình không biết nói gì ngoài "hôm qua em test, hôm nay em test tiếp".
Thực ra, phần lớn nhà tuyển dụng IT đánh giá kỹ năng mềm quan trọng không kém kỹ năng kỹ thuật khi tuyển fresher. Với tester, điều này càng đúng hơn - vì công việc tester là cầu nối giữa dev và BA, giữa yêu cầu và sản phẩm thực tế.
Tester là cầu nối - thiếu giao tiếp tốt, cả team mất phương hướng
Kỹ thuật test có thể học trong vài tháng. Nhưng kỹ năng mềm không có trong giáo trình nào - phải tự rèn. Bài này mình chia sẻ những gì mình học được (và học sai) từ môi trường Agile thực tế, để bạn không phải mất 6 tháng đầu loay hoay như mình.
Giao tiếp với dev: nghệ thuật báo bug mà không gây chiến
Báo bug sai cách là lý do số 1 khiến tester và dev "xung đột" âm ỉ. Dev không ghét bug - họ ghét bug báo thiếu thông tin, không reproduce được, hoặc tông văn "tại sao anh code thế này".
Bug report tốt không cần nhiều chữ, chỉ cần đủ thông tin:
- Steps to reproduce rõ ràng: viết như hướng dẫn nấu ăn - bước 1, bước 2, bước 3
- Expected vs Actual: kỳ vọng gì, thực tế ra sao
- Environment: thiết bị, trình duyệt, version
- Severity và Priority: bug này quan trọng đến mức nào
Mình từng viết bug report kiểu "trang này bị lỗi, không load được". Dev hỏi lại 5 câu. Mất cả buổi sáng cho 1 bug. Sau mình đổi thành: "Trang checkout không load khi giỏ hàng có >10 sản phẩm, Chrome 120, Windows 11. Màn hình trắng sau 3 giây, console log error 500.". Dev fix trong 20 phút.
Bug report đủ thông tin giúp dev fix nhanh hơn 3-5 lần
Ngoài bug report, còn cần biết khi nào nên chat Slack, khi nào cần gặp trực tiếp. Rule mình hay dùng: bug đơn giản → comment trên Jira. Bug phức tạp, cần clarify → chat. Bug nghiêm trọng ảnh hưởng release → gặp trực tiếp hoặc gọi.
Tone khi giao tiếp với dev: trung lập, không buộc tội. Thay vì "code anh sai rồi", thử "mình thấy kết quả này không khớp với spec, bạn xem giúp mình với". Khác nhau nhiều lắm.
Làm việc với BA: đọc requirement như đọc hợp đồng
BA (Business Analyst) viết requirement, tester đọc requirement để test. Nghe đơn giản. Nhưng thực tế, requirement thường thiếu thông tin, mơ hồ, hoặc mâu thuẫn - và tester phải phát hiện trước khi dev code.
"Người dùng có thể đăng nhập bằng email hoặc số điện thoại." Câu này thiếu gì?
- Email có phân biệt hoa/thường không?
- Số điện thoại format nào? +84, 0 hay cả hai?
- Nhập sai bao nhiêu lần thì khóa tài khoản?
- Quên mật khẩu xử lý thế nào?
Đây là lý do tester phải học hỏi BA từ sớm. Không phải để sửa requirement - mà để đặt câu hỏi đúng lúc, trước khi dev code sai.
Câu hỏi đúng lúc tránh được cả tuần fix bug
Cách mình hay làm: sau khi đọc requirement, liệt kê ngay những điểm chưa rõ ra Jira comment hoặc Google Doc chung. BA trả lời, mình update vào test case. Cách này giúp mình không bị "BA nói khác, dev hiểu khác, mình test cái khác" - lỗi phổ biến nhất trong team Agile mới hình thành.
Một tip nhỏ: đừng hỏi nhiều câu cùng lúc qua chat. Tập hợp tất cả câu hỏi lại, hỏi một lần trong buổi refinement hoặc gửi 1 message danh sách. BA và dev đều bận, họ trân trọng người hỏi gọn.
Daily standup trong Agile: 15 phút quyết định cả ngày
Standup hàng ngày (daily standup) là meeting ngắn 15 phút mà team Agile làm mỗi sáng. Ba câu hỏi chuẩn:
- Hôm qua mình làm gì?
- Hôm nay mình sẽ làm gì?
- Có blocker gì không?
Tưởng dễ. Nhưng fresher thường mắc hai lỗi:
Lỗi 1 - Quá chung: "Hôm qua em test. Hôm nay em test tiếp." Không ai biết bạn đang test cái gì, tiến độ đến đâu.
Lỗi 2 - Quá dài: Kể lại toàn bộ quá trình test từ sáng tới chiều. Standup không phải buổi báo cáo chi tiết.
15 phút standup - nói đúng, nói đủ, không nói thừa
Công thức mình dùng:
"Hôm qua mình test xong luồng [đăng ký tài khoản], phát hiện 2 bug, đã tạo ticket trên Jira. Hôm nay test tiếp luồng [thanh toán]. Hiện chưa có blocker."
Năm câu. Rõ ràng. Ai cũng hiểu. Nếu có blocker thực sự - ví dụ "API chưa ready, mình không test được" - nêu rõ và nhờ support luôn trong standup, đừng đợi đến cuối ngày.
Blocker không báo đúng lúc là nguyên nhân phổ biến nhất khiến sprint bị trễ. Mình từng giữ im lặng 2 ngày vì nghĩ "chắc chờ thêm chút", kết quả delay cả sprint. Từ đó mình học: báo blocker sớm không phải yếu - mà là chuyên nghiệp.
Những kỹ năng mềm khác fresher hay bỏ qua
Ngoài giao tiếp với dev và BA, còn một số kỹ năng mềm tưởng nhỏ nhưng ảnh hưởng nhiều đến cách team nhìn nhận tester:
Quản lý thời gian trong sprint: Agile chạy theo sprint 1-2 tuần. Tester phải tự estimate thời gian test cho từng story, không đợi được assign. Fresher hay ước lượng thiếu - test nhanh hơn thực tế - rồi không biết làm gì khi xong sớm, hoặc ước lượng thừa rồi không kịp deadline.
Cách tập: chia task ra từng ngày. Thứ Hai test feature A, thứ Ba test feature B, thứ Tư buffer cho regression. Ghi lại thực tế mất bao lâu để lần sau estimate chính xác hơn.
Tự học và adapt nhanh: Stack công nghệ thay đổi, tool thay đổi, process thay đổi. Tester cần habit đọc tài liệu khi có tool mới thay vì đợi ai hướng dẫn.
Nhận feedback không phòng thủ: Reviewer comment bug report của bạn thiếu thông tin - đừng giải thích tại sao mình làm vậy. Ghi nhận, fix, làm tốt hơn lần sau. Đây là kỹ năng khó nhất nhưng quan trọng nhất.
Kỹ năng mềm không học một lần là xong - phải rèn mỗi ngày
Nếu bạn đang chuẩn bị chuyển ngành sang tester, mình khuyên song song với học kỹ thuật, hãy luyện ngay 3 thứ: viết rõ ràng, hỏi đúng câu, và lắng nghe trước khi phản bác. Ba thứ này không cần tool, không cần code - chỉ cần ý thức.
Checklist rèn luyện kỹ năng mềm tester - từ ngày đầu đến phỏng vấn
Đây là checklist mình tổng hợp từ kinh nghiệm thực tế và từ những gì được hỏi trong phỏng vấn tester. Không phải để làm một lần - mà để nhìn lại mỗi tuần.
Bạn có thể tải về và tự đánh dấu tiến độ: Tải checklist rèn kỹ năng mềm tester
Tuần 1-2 (Foundation):
- Viết 5 bug report hoàn chỉnh (có đủ Steps, Expected, Actual, Severity)
- Luyện giải thích 1 bug cho người không biết IT nghe hiểu
- Đọc 1 tài liệu requirement và liệt kê 5 điểm chưa rõ
Tuần 3-4 (Team Simulation):
- Tham gia (hoặc xem lại recording) 3 buổi standup thật/giả lập
- Luyện nói standup 3 câu trong <30 giây với bạn cùng học
- Thực hành nhận feedback: nhờ người khác review bug report và không phòng thủ
Chuẩn bị phỏng vấn:
- Chuẩn bị câu trả lời: "Bạn xử lý thế nào khi dev không đồng ý bug bạn báo?"
- Chuẩn bị câu trả lời: "Describe daily standup trong Agile team"
- Có ít nhất 1 ví dụ thực tế về lần bạn giao tiếp tốt/xử lý conflict trong team
Checklist này giúp bạn biết mình đang ở đâu trong hành trình
Nếu bạn muốn có nền tảng kỹ thuật vững chắc song song với rèn kỹ năng mềm, khóa Kiểm thử phần mềm đi từ cơ bản đến thực chiến - từ viết test case, bug report đến làm quen với quy trình Agile thực tế. Mình thấy đây là điểm xuất phát tốt cho người trái ngành.
Nhớ: kỹ năng mềm không có "xong". Nhưng có checklist, bạn biết mình đang đi đúng hướng.