Những hiểu lầm tai hại về nghề QA ở Việt Nam

QA không phải là một vai trò mới mẻ gì trong ngành công nghiệp phần mềm nói chung hay trong nhánh gia công phần mềm nói riêng. Dù vậy, vẫn còn rất nhiều những hiểu lầm về vai trò của mình mà QA thường mắc phải. Nhân tiện ngày hôm nay tôi vừa có vài trao đổi với Sếp về một số vấn đề tôi cho là không đúng và cần phải thay đổi để đội ngũ QA của công ty ngày một phát triển hơn, tôi cũng nghĩ nên viết lên đây những trăn trở đó cho mọi người cùng đọc. Bài viết này không chỉ hướng đến cộng đồng QA, mà tôi mong cả các bạn Dev cũng nên xem qua để chúng ta làm việc với nhau hiệu quả hơn, hài hòa hơn, vui vẻ hơn.

Đúng và Sai. Testing chỉ là một phần nhỏ trong những công việc mà QA phải làm. Hãy nhớ, QA là viết tắt của Quality Assurance, tức là chúng ta phải làm mọi thứ để "Đảm bảo chất lượng", chứ không chỉ là Kiểm thử. Kiểm thử là một phần quan trọng của quy trình Đảm bảo chất lượng, nhưng không phải là tất cả. Nếu chỉ biết mỗi Test, hoặc chỉ tập trung vào Test, thì vai trò của bạn chỉ mới đạt mức Tester chứ còn lâu mới là QA.

Tôi đã từng làm việc như một Tester cơ bản khi còn đi thực tập năm thứ 3 đại học, và tôi nhận ra rằng công việc của một Tester không khác gì một cái máy tiêu thụ testcase cả. Và Tester không thể làm việc độc lập được. Muốn tạo ra hiệu quả, xung quanh Tester phải có nhiều vị trí hỗ trợ khác như TW (Testcase Writer), CM (Configuration Manager - người đảm bảo môi trường cho việc test), QA (người chủ yếu thẩm định về quy trình và độ an toàn của cả dự án). Mô hình này sẽ hợp lý với những dự án lớn đến cực lớn, nơi mà giới hạn số lượng member là rất cao và khối lượng công việc là cực lớn. Trong các dự án Agile nhỏ và vừa thì mô hình này gây áp lực rất lớn về mặt quản lí mà lại không thể hiện được tính ưu việt.

Trong những dự án Agile vừa và nhỏ như vậy, vai trò QA xuất hiện như một kiểu "đấng toàn năng" làm mỗi thứ một tí để cải thiện chất lượng của không phải chỉ mỗi sản phẩm mà là cả dự án. QA không chỉ kiểm thử khi đã có sản phẩm mẫu, mà còn phải phân tích Spec để tìm điểm mâu thuẫn, chưa hợp lý hoặc quá khó triển khai. QA không chỉ quản lí quy trình kiểm thử và log bug mà còn phải cải thiện cả quy trình quản lí ticket, tham gia vào việc phân công và review task của Dev, và đôi khi còn phải góp phần vào việc quản lí dự án như một PM thực thụ, giao tiếp với khách hàng như một BrSE. Đó chính là điều làm nên cái giá của một QA giỏi, chứ không phải là chỉ mỗi việc Kiểm thử thôi đâu.

Nếu các bạn đã từng làm việc trong các dự án Agile, các bạn chắc cũng biết rằng đặc sản của những dự án này là việc Spec thay đổi liên miên, Khách hàng đổi ý chóng mặt. Điều này vẫn đúng kể cả với những dự án Waterfall quy mô lớn, thậm chí cả những dự án làm Product (phân biệt với Outsourcing) cũng không tránh khỏi. Dù tài liệu yêu cầu (Spec) có được viết kĩ lưỡng tới đâu, thiết kế hệ thống có chi tiết cỡ nào thì Khách hàng cũng là người, họ cũng có quyền sai sót và có thể sai sót. Nhiệm vụ của QA không phải là chỉ quan tâm tới sản phẩm cuối cùng của dự án mà ngay từ khâu đầu vào (thảo luận và thống nhất Specs, thiết kế giao diện, thiết kế hệ thống) cũng cần có sự giám sát chặt chẽ của QA. Một QA làm tròn nhiệm vụ là người phải hiểu toàn bộ Specs ngay khi chúng được viết ra, và bất cứ chỗ nào không hiểu thì cần phải được làm rõ ràng thông qua brainstorming, Q&A hoặc bất kì phương pháp nào khác. Một QA khá giỏi là người có thể và dám nhận định phần nào của Specs hoặc Design là chưa hợp lý, bất khả thi hoặc mâu thuẫn với các phần còn lại. Như đã nói ở trên, nhiệm vụ của QA không chỉ là Testing.

Kể cả khi QA đã lỡ bỏ qua bước kiểm soát đầu vào ở trên, thì ngay cả khi Test, QA cũng không nên quá tuân thủ theo Specs một cách máy móc. Ngoài lý do Specs có thể sai, không hợp lý hoặc mâu thuẫn với chính nó, QA còn cần phải trao đổi với Dev để biết được đâu là giới hạn của công nghệ hoặc của nền tảng mà ứng dụng đang được lập trình dựa trên. Có những yêu cầu nghe rất hay, rất hoành tráng nhưng Dev không có khả năng thực hiện, hoặc là do giới hạn công nghệ, hoặc là do trình độ của Dev có hạn hoặc thời gian phát triển tính năng bị giới hạn. Hai lí do phía sau có thể liên quan nhiều hơn đến chuyên môn của PM hoặc BA, nhưng với lý do đầu tiên, QA phải nắm được và điều tra kĩ lưỡng hơn bằng phương pháp Kiểm tra chéo (cross-checking) với các Dev khác ngoài dự án hoặc ngoài công ty, cũng như tham khảo các nguồn thông tin trên mạng. Khi tất cả đã clear, QA được quyền và có trách nhiệm đề xuất thay đổi Specs lên Khách hàng, cùng lúc đó chỉ ra những vấn đề còn tồn tại của Specs để stakeholders cùng nhau bàn bạc.

"Sự bất lực của Dev" tôi nói đến ở đây là trường hợp Dev từ chối không hiện thực hóa một chức năng nào đó mà Khách hàng yêu cầu với một trong các lí do sau:

• Yêu cầu của Khách hàng nằm ngoài giới hạn công nghệ.
• Yêu cầu của Khách hàng quá khó so với năng lực của Dev.
• Dev quá lười và nghĩ rằng QA dễ lừa (hay còn gọi là Dev khinh thường QA).

Nên nhớ, công việc của QA là đảm bảo chất lượng cho dự án. Mọi thâm hụt dù là nhỏ nhất đối với tập hợp chức năng của ứng dụng đầu ra đều là gánh nặng lớn trên đôi vai của QA. Bởi vậy, QA phải là người năng nổ nhất, hăng say nhất, có trách nhiệm nhất trong việc điều tra làm rõ và đề ra giải pháp cho vấn đề phát sinh kiểu này. Dù là bất kì lí do nào trong 3 lí do trên, QA đều cần phải làm 3 việc sau đây:

1. Kiểm tra chéo để xác minh sự trung thực của Dev.
2. Báo cáo với PM và nhờ PM confirm về năng lực của Dev cũng như độ khó của Specs.
3. Trong trường hợp Dev nói thật và giới hạn công nghệ không cho phép tính năng đó, QA cần tìm ra một vài giải pháp trung gian vừa cân bằng giữa yêu cầu của Khách hàng, vừa có vẻ dễ triển khai cho Dev. Sau đó QA cần đề xuất vấn đề và giải pháp dự phòng lên cho stakeholders (ở đây là PM và Khách hàng) cùng thảo luận.

Những bước trên đây đều là nghĩa vụ của QA chứ không phải là tôi cố ý vẽ thêm việc cho các bạn làm. Tôi học được điều này từ khi bắt đầu làm Tester cho đến tận khi tôi lên chức Test Leader ở công ty cũ và ngay cả khi trở thành QA ở công ty hiện tại, tôi đã luôn cố thực hiện đầy đủ. Tất nhiên, sức người có hạn. Bạn có thể làm nhiều hay ít tùy năng lực, tùy quỹ thời gian, tùy tình huống cũng như tùy hệ thống quản lí ở team bạn. Tuy vậy, nếu muốn trở thành một QA giỏi giang, được trọng vọng, được kính nể thì những bước nêu trên là cần thiết dù nghe có vẻ hơi thừa thãi.

Đây là một hiểu lầm phổ biến ở các QA non kinh nghiệm, cho rằng Tester/QA chỉ là role phụ trong một dự án phát triển phần mềm, có trách nhiệm giúp đỡ Dev kiểm thử sản phẩm. Sai, sai và rất sai. QA và Dev là hai vai trò ngang hàng, cùng đồng hành và hỗ trợ lẫn nhau như Âm và Dương trong vòng trong Thái cực vậy. Đôi khi QA có hỗ trợ Dev trong việc giải thích làm rõ Specs, đôi khi Dev có hỗ trợ QA trong việc setup môi trường kiểm thử, tuy nhiên hỗ trợ lẫn nhau hoàn thành công việc là nguyên tắc chung của Làm việc nhóm chứ không phải dành riêng cho role nào cả.

Về cơ bản, công việc của QA và Dev là hoàn toàn độc lập và nên được giữ càng độc lập với nhau càng tốt. Họ có thể trao đổi với nhau nhiều thứ, từ quan điểm test cho tới cách mà một đoạn code bất kì hoạt động, nhưng đó là vì lợi ích chung của dự án, chứ không phải là vì nghĩa vụ của role này là support cho role kia.

Cũng theo hiểu lầm này, QA được cho rằng sẽ "chỉ đâu đánh đấy", khi nào ném cho build mới thì test, khi nào không có build mới thì ngồi chơi nằm chờ. Sai quá sai. Việc test của QA là vô hạn định, vô hạn lặp lại chứ không phải là chỉ test khi có build mới. Mà ngoài Test ra, như trên đã nói, QA còn cả tỉ thứ việc khác để làm. Sẽ là tốt nhất khi Dev chủ động yêu cầu QA kiểm tra xem đoạn code mới viết có hoạt động đúng như mong muốn không, hoặc QA chủ động yêu cầu Dev giải thích cho mình hiểu cách thức hoạt động của đoạn code này, tính năng nọ. Nhưng sẽ không bao giờ là tốt nếu QA chỉ đóng một vai trò mờ nhạt như một cái bóng của Dev cả.

Riêng về chủ đề này, tôi đã có chỉ ra những điểm sai cố hữu và nêu quan điểm rất rõ tại đây. Chỉ xin nhắc lại, như trên tôi đã nói, mối quan hệ giữa QA và Dev giống như là Âm và Dương trong một vòng tròn Thái cực. Âm Dương phải cân đối, hài hòa, xoay chuyển hợp lý nhịp nhàng thì dự án mới có thể thành công mĩ mãn được. QA và Dev không những không phải kẻ thù mà còn phải là bạn bè thân thiết, phải là anh em một nhà, phúc cùng hưởng họa cùng chia, nghĩ cho nhau, nghĩ vì nhau và tôn trọng lẫn nhau thì sản phẩm cuối cùng mới có hình hài vuông tròn đẹp đẽ. Việc giữ cho dự án trong ấm ngoài êm thế này cũng là một phần trách nhiệm quan trọng của QA vậy đó.

Nhắn nhủ

Tháng trước vì quá bận nên tôi đã dịch một bài blog từ web nước ngoài về Viblo, có ghi nguồn đầy đủ. Trong lúc dịch có viết sai vài chữ. Có phải vì thế mà tôi nhận được những 5 lượt vote down từ các bạn đọc hay không thì tôi cũng không rõ (vì tôi xét thấy nội dung rất ổn, không có vấn đề gì). Tôi buồn và hơi giận nên đã xóa bài đó. Bài này là tôi tự tay viết tương tự như nhiều bài khác của tôi, mong là sẽ nhận được nhiều hơn những lượt vote up của bạn đọc. Xin chân thành cảm ơn.