More than "Just Testing"

Trong bài viết này tôi sẽ không đề cập nhiều đến vấn đề học thuật hay những khái niệm mang tính sách vở. Tôi chỉ muốn chia sẻ góc nhìn cá nhân về "Vai trò" và "Mối quan hệ" của Tester (QA) trong dự án phần mềm. Trong suốt 5 năm làm việc liên trong lĩnh vực IT, trải qua hầu hết các vị trí cơ bản trong một dự án phần mềm như Developer, Quality Assuarance (bao gồm cả Testing và quản lý Process), Team Leader (TL), Project Manager (PM), Bridge Software Engineer (BrSE) .. tôi nhận thấy vai trò của Tester là rất quan trọng nhưng không phải lúc nào cũng được đánh giá đúng.

Vậy đâu là nguyên nhân của vấn đề này? Chúng ta hãy quay trở lại thời sinh viên một chút để tìm hiểu vấn đề này. Khi tôi và các bạn là sinh viên chuyên ngành IT, có thể chúng ta đã biết hoặc nghe đến khái niệm Testing nhưng tôi cá rằng số trường Đại Học ở Việt Nam có dạy về môn "QA & Testing" chỉ đếm trên đầu ngón tay. Sinh viên sẽ được học rất nhiều các ngôn ngữ, công nghệ tiên tiến nhưng sau khi ra trường vẫn rất mù mờ về khái niệm Testing.Đó là điều khá dễ hiểu, ngay cả trong mindset của các Thầy Cô dạy công nghệ (mặc dù không nói ra) thì sinh viên giỏi là phải code ngon. Những kẻ thất bại (đương nhiên là ngoại trừ các bạn gái ra), không code được hoặc code không giỏi mới chọn đến con đường làm Tester. Vô hình chung các bạn sinh viên đã bị tiêm nhiễm suy nghĩ đó trước khi hiểu công việc của một Tester là như thế nào. Và vấn đề đó vẫn đang tồn tại ở hầu hết các trường ĐH dạy về Công nghệ Thông tin hiện nay.

Hậu quả là khi bạn ra trường và join một Project với vai trò là QA, bạn sẽ không được đồng nghiệp đánh giá một cách công bằng cho các đóng góp của mình. Đôi khi bạn sẽ cảm thấy Developer hoặc PM coi thường ý kiến của bạn. Cảm thấy những cố gắng, đóng góp của mình không được ghi nhận .. Và như là một hệ quả tất yếu, những cuộc tranh luận giữa Developer và QA xảy ra như cơm bữa. Khi làm TL, PM tôi đã được nghe rất nhiều, và phải xử lý rất nhiều những cuộc tranh luận như vậy. Thậm chí có những cuộc tranh luận mà hậu quả của nó khá nặng nề, Dev và Test làm trong cùng dự án mà không nhìn mặt nhau.

Ngoài vấn đề mindset, một nguyên nhân nữa là do thiếu phong cách làm việc chuyên nghiệp. Dĩ nhiên đó là vấn đề không chỉ trong ngành Công nghệ Thông tin mà là vấn đề chung của người Việt Nam. Các bạn trẻ của chúng ta không được trang bị những kỹ năng mềm như Kỹ năng giao tiếp, đàm phán, hay xử lý vấn đề ... để rồi dùng cảm xúc cá nhân để xử lý khi có mâu thuẫn. Điều này không chỉ ảnh hưởng trực tiếp tới dự án mà còn không có lợi đối với các mối quan hệ xã hội.

Tôi có được nghe một anh Giám đốc một công ty Phần mềm phát biểu như thế này "Anh không hiểu tại sao lại cần thiết có Tester trong dự án trong khi các bạn Developer code, hiểu rõ code, các bạn ấy có thể làm test tốt hơn Tester". Xét về một mặt nào đó thì anh đúng. Nhưng một sản phẩm phần mềm không phải là sân chơi riêng của Developer. Tôi không ngạc nhiên khi công ty của anh khi đó là một công ty phần mềm nhỏ và sau 5 năm nó vẫn là một công ty phần mềm nhỏ. Hiện tại công ty của anh cũng đã có bộ phận QA, nhưng tôi nghĩ anh đã lỡ nhiều cơ hội. Thật khó để tiến lên khi ngay chính những người lãnh đạo công ty bỏ sót một mắt xích nào đó trong chu trình phát triển phần mềm. Họ đang chạy đua mà không nhận ra mình không hề tiến lên phía trước.

Có khá nhiều bạn trước khi đi phỏng vấn vị trí QA, hoặc đang làm QA hỏi tôi "Vai trò của Tester là gì? Tại sao lại cần phải có Tester trong dự án?" và dưới đây là câu trả lời của tôi. Vai trò của Tester không chỉ dừng lại ở việc thực hiện test. Đặc biệt trong mô hình phát triển phần mềm được áp dụng phổ biến hiện nay như Agile/Scrum.

1. Tester là BA (Business Analysis)

Trước đây trong các mô hình phát triển phần mềm truyền thống như WaterFall, Tester tham gia vào dự án khá muộn gần như là khi sản phẩm đã hoàn thành. Công việc của Tester khi đó là tạo test case và thực hiện test. Nhưng ngày nay nhận thức đó đã không còn phù hợp. Tester join từ giai đoạn đầu dự án và tham gia tích cực vào các công đoạn khác. Trong những dự án lớn thường có bộ phận BA chịu trách nhiệm đánh giá, phân tích SRS (Software Requirement Specification), confirm những điểm chưa rõ ràng trong Requirement với Khách hàng, để các công đoạn Coding, Testing phía sau thuận lợi hơn. Nhưng trong các dự án nhỏ người làm nhiệm vụ đó không ai khác ngoài Tester. Quá trình study Requirement của Tester sẽ chỉ ra được những điểm chưa rõ ràng trong hệ thống, những thiếu sót trong tài liệu SRS mà Developer không hề để ý đến.

2. Phân tích và hỗ trợ Developer về hệ thống

Điều này nghe có vẻ hơi lạ so với hiểu biết thông thường nhưng Tester là người quan tâm đến tổng quan, cách vận hành của hệ thống nên những câu hỏi của họ có thể làm sáng tỏ nhiều vấn đề. Trước khi User story đến được với Developer, Tester sẽ thảo luận với Product owner về features mà Product owner thực sự mong muốn. Kỹ năng của Tester có thể có ích rất nhiều trong việc phát hiện, nhận dạng những điểm nhập nhằng trong User story. Điều đó đảm bảo Development team phát triển, đưa ra sản phẩm đúng mong đợi của Khách hàng. Khi đó, vai trò của Tester không dừng lại ở việc phát hiện bug, log bug mà còn giúp sản phẩm đi đúng hướng và hạn chế khả năng xảy ra bug

3. Connect các thành viên khác trong Team

Trong mô hình Agile, phương pháp truyền đạt, chia sẻ thông tin dự án hiệu quả, hữu hiệu nhất là communication, face-to-face. Tester là người communication nhiều và thường xuyên nhất trong Agile mà ngay bản thân họ cũng không nhận ra điều đó. Họ tương tác thường xuyên với Development Team (những người vùi đầu trong coding và bug fixing) và Product owner (người hiểu rõ về feature nhưng lại có ít thời gian cho Development Team). Tester đóng vai trò quan trọng trong việc motivate mọi người trong dự án và làm tăng giá trị vào process và sản phầm. Trong quãng thời gian làm việc với vai trò Test Leader, tôi luôn khuyến khích các Tester của mình gặp và trao đổi trực tiếp với Developer về bug, về SRS thay vì log những dòng khô khan lên hệ thống Tool. Communication hiệu quả không chỉ giúp project vận hành trơn tru hơn mà còn cải thiện các mối quan hệ trong Team.

4. Tham gia vào việc lập Planning và estimate

Khi tiếp nhận một User story, Tester sẽ xem xét chi tiết các khía cạnh để có thể test được story đó. Những yếu tố như

• Những yêu cầu ẩn sau story
• Môi trường, device test
• Data test
• Sự phụ thuộc vào các yêu cầu, story khác

Việc đánh giá những yếu tố trên, cùng với estimate coding từ phía Developer sẽ là cơ sở trong việc Planning và Estimate hiệu quả, chính xác.

Trên đây chỉ là 4 vai trò lớn của Tester mà tôi muốn đề cập đến ngoài vai trò chính yếu là thực hiện Test. Ngoài ra tôi chắc rằng bạn cũng có thể nhận thấy tầm quan trọng của họ nhiều hơn nữa trong thực tiễn dự án. Thay cho lời kết tôi muốn gửi đến các bạn Tester một lời nhắn "Be pround of Tester you are!"