Với những ai đã từng làm việc trong môi trường sản xuất phần mềm chắc hẳn đều thấy được vai trò quan trọng của các Lập trình viên (Dev – Developer) vì một lẽ đơn giản và rất dễ hiểu:
Không có Dev thì sẽ không có phần mềm. Ở nhiều công ty sản xuất phần mềm Việt Nam, các nhân viên chủ yếu là Dev, thậm chí là chỉ có Dev mà không có Kiểm thử viên (Tester). Điều này rất phổ biến đối với các công ty có khách hàng trong nước – Phần lớn các khách hàng này thiếu sự hiểu biết về phần mềm, việc ứng dụng phần mềm, cũng như là chất lượng sản phẩm phần mềm.
Trong bối cảnh đó, vai trò của Tester là rất mờ nhạt. Lối suy nghĩ cho rằng Tester – những người tìm lỗi phần mềm – là những người làm việc phụ và không quan trọng trong việc sản xuất phần mềm là rất phổ biến trong giới IT cũng như một bộ phận lớn những người ngoài ngành IT. Có lần tui nói chuyện với một người bạn làm trong công ty xây dựng rằng tui làm Tester. Người bạn đó đưa ra một nhận xét mà tui không biết nên cười hay nên khóc: “Mi làm tester là sướng rồi. Tụi Dev hắn làm hết trơn, mi chỉ việc xem tụi hắn làm sai chỗ mô rồi báo cho tụi hắn sửa chớ có làm chi mô mà cực”. Có lẽ cũng chính vì suy nghĩ này ăn sâu vào nhiều người nên quan hệ giữa Tester và Dev thường là không thân thiện cho lắm. Nói một cách hình ảnh thì Dev đóng vai “thiện”, chịu nhiều cực khổ, tốn bao nhiêu công sức mới làm ra được phần mềm. Còn Tester đóng vai “ác”, rảnh rỗi, chỉ chăm chăm vô việc đi tìm bắt cái chỗ sai của người ta và sung sướng khi tìm thấy!
“Oan” này của Tester chắc phải to hơn cả “Oan Thị Kính”!
Để hiểu là Tester chịu “oan“ như thế nào thì phải hiểu vai trò của Tester trong công việc sản xuất phần mềm trước. Tester tìm lỗi của phần mềm – điều này chính xác. Tìm lỗi, báo cáo lỗi, kiểm tra lỗi đã được sửa hay chưa là các công việc chính của một tester. Nhưng vai trò của Tester là như thế nào? Lấy một ví dụ: Mấy hôm nay báo, đài, tivi hay đưa tin cái hệ thống bán vé tàu hỏa qua mạng nó bị quá tải, nó bị nghẽn, không thể mua vé được. Thực tế xảy ra trái ngược với tuyên bố của đơn vị chủ quản hệ thống này (Năm nay là năm thứ 2 triển khai hệ thống này, và vẫn lặp lại các vấn đề cũ). Nếu có Tester, các vấn đề này sẽ không xảy ra, hay người ta sẽ biết trước khi nào thì nó xảy ra để có giải pháp. Ví dụ thứ hai: Đôi khi ta thường nghe thấy công ty này, công ty kia bỏ ra cả trăm triệu đồng để xây dựng một cái hệ thống phần mềm. Nhưng khi làm xong thì không thể sử dụng được trong thực tế vì có quá nhiều lỗi. Nếu có tester, điều này sẽ rất khó xảy ra (Ở đây loại trừ các nguyên nhân về quy trình, người dùng không biết được mình muốn gì, kỹ năng quản lý).
Nói tóm lại, Dev là người tạo ra phần mềm, còn Tester là người giúp cho phần mềm đó có khả năng “sống” được trong thực tế. Qua đó, tăng hiệu quả đầu tư, giảm chi phí, tiết kiệm công sức và bảo vệ kết quả lao động của cả nhóm dự án (trong đó có Dev).
Có thể so sánh và đánh giá mối quan hệ giữa Tester và Dev ở một vài khía cạnh sau:
1. Về mặt tâm lý:
Khi người ta tập trung vào công việc của mình, vượt qua thử thách và hoàn thành công việc đó thì phản ứng tự nhiên là vui sướng. Ai làm code chắc cũng đều có lúc cười một mình, nói “lảm nhảm” một mình khi gặp phải những chức năng khó. Để rồi cười sung sướng hay nhảy cẫng lên khi cái chức năng đó chạy. Tester cũng vậy. Sau khi bỏ công sức ra để tìm lỗi (làm thế nào để tìm ra lỗi cũng không đơn giản như nhiều người tưởng) thì người ta cũng có quyền cười chứ?! Đó là cười vì công sức mình bỏ ra đã đem lại kết quả chứ không phải là “cười trên sự đau khổ của người khác” như nhiều người nói.
2. Về vấn đề hiệu quả chi phí và hiệu quả công việc:
Ai cũng biết là các khách hàng nước ngoài (Nhật, Mỹ, …) luôn đặt vấn đề đảm bảo chất lượng lên cao, và họ luôn kiểm thử (test) lại rất kỹ càng trước khi cho triển khai phần mềm ra thực tế hay thanh lý hợp đồng. Các lỗi do phía khách hàng tìm ra phần lớn là bắt buộc phải sửa, và người sửa cũng chính là Dev. Thêm vào đó là uy tín giảm sút, phải làm thêm giờ (OT – Overtime) cho kịp tiến độ, khả năng trễ hợp đồng, tỷ lệ rủi ro tăng cao, … Những nghiên cứu cho thấy, các lỗi được phát hiện càng sớm chừng nào thì chi phí, độ phức tạp, thời gian, công sức để sửa chữa càng thấp chừng nấy. Nếu bạn là Dev, bạn sẽ muốn làm việc theo kế hoạch, sửa những lỗi do chính những người cùng làm việc với mình phát hiện từ sớm và nhận thưởng khi kết thúc dự án, hay muốn làm việc thoải mái suốt 70% thời gian dự án để rồi cuối dự án phải OT liên tục, tốn nhiều thời gian, công sức để sửa các lỗi (sửa cái này thì đụng tới cái khác) và không có thưởng khi kết thúc dự án?
3. Về khối lượng công việc:
Dev phải code nhiều chức năng, sửa các lỗi , OT, tìm hiểu nghiệp vụ, tìm hiểu công nghệ cho nên công việc của Dev căng thẳng và mất nhiều công sức. Nhưng không phải ai cũng biết rằng, Dev chỉ nghiên cứu nghiệp vụ của một vài chức năng mà họ đảm nhận, còn Tester phải nghiên cứu và nắm chắc nghiệp vụ của toàn bộ chương trình để có thể test và hỗ trợ Dev các vấn về về nghiệp vụ. Mỗi dự án khác nhau thường là có các nghiệp vụ hoàn toàn khác nhau. Trong khi đó, sự thay đổi về công nghệ áp dụng của Dev trong các dự án khác nhau là không nhiều.
Dev phải làm OT, nhưng Tester phải vừa test phiên bản cũ (lúc Dev code phiên bản mới) và tiếp tục test phiên bản mới sau khi Dev đã làm xong và “đi đâu đó”. Trong thực tế thì khi nào có lỗi thì mới yêu cầu Dev về sửa, nếu không thì thôi. Còn Tester, luôn luôn ngồi đó và tìm lỗi.
4. Về vấn đề Teamwork:
Dù là Dev hay Tester thì cũng đều là thành viên của một team, mỗi người một vai trò, một chức năng, nhưng có cùng một mục đích là hoàn thành sản phẩm trong thời gian ngắn nhất với chất lượng cao nhất và hiệu suất tốt nhất.
Dev và Tester có mối quan hệ chặt chẽ và hỗ trợ nhau trong công việc. Dev code tốt thì Tester sẽ tốn ít thời gian và công sức để tìm lỗi. Tester tìm ra càng nhiều lỗi và càng sớm thì Dev càng tốn ít thời gian, công sức để sửa (chắc chắn là phải sửa khi khách hàng tự kiểm tra) về sau. Chất lượng sản phẩm, hiệu suất làm việc theo đó cũng tăng lên, rủi ro và độ căng thẳng và thời gian làm việc giảm.
5. Về vấn đề cạnh tranh việc làm:
Những ai dành sự quan tâm cho ngành IT có lẽ cũng nhận thấy rằng, Ấn Độ, Trung Quốc, Philippines, … đang nổi lên là những nước đứng đầu về dịch vụ gia công phần mềm với chất lượng cao, chi phí thấp. Các công ty phần mềm Việt Nam gặp rất nhiều khó khăn để cạnh tranh trên thị trường vì không đủ năng lực, sản phẩm làm ra không đảm bảo chất lượng. Qua đó, ảnh hưởng đến những ai làm trong lĩnh vực gia công phần mềm (trong đó có Dev, tester) ở nhiều góc độ: công việc không ổn định, thu nhập không cao, thiếu việc làm, … Một sản phẩm bị khách hàng quốc tế đánh giá là không đảm bảo chất lượng sẽ là nguyên nhân hàng loạt dự án với giá trị lớn sẽ bỏ ta để đi qua các nước khác.
Tổng kết lại, thái độ đúng đắn cho quan hệ giữa Dev và Tester là phải nhận thức được vai trò không thể thiếu của nhau, là mối quan hệ tương hỗ, hợp tác chứ không phải đối đầu, là có chung một mục đích. Các vấn đề nên được xem xét ở góc độ “làm thế nào để giải quyết và làm cho sản phẩm tốt hơn”.
Và điều cuối cùng tui muốn khẳng định một lần nữa:
“Tester không đóng vai ác!”
Không có Dev thì sẽ không có phần mềm. Ở nhiều công ty sản xuất phần mềm Việt Nam, các nhân viên chủ yếu là Dev, thậm chí là chỉ có Dev mà không có Kiểm thử viên (Tester). Điều này rất phổ biến đối với các công ty có khách hàng trong nước – Phần lớn các khách hàng này thiếu sự hiểu biết về phần mềm, việc ứng dụng phần mềm, cũng như là chất lượng sản phẩm phần mềm.
Trong bối cảnh đó, vai trò của Tester là rất mờ nhạt. Lối suy nghĩ cho rằng Tester – những người tìm lỗi phần mềm – là những người làm việc phụ và không quan trọng trong việc sản xuất phần mềm là rất phổ biến trong giới IT cũng như một bộ phận lớn những người ngoài ngành IT. Có lần tui nói chuyện với một người bạn làm trong công ty xây dựng rằng tui làm Tester. Người bạn đó đưa ra một nhận xét mà tui không biết nên cười hay nên khóc: “Mi làm tester là sướng rồi. Tụi Dev hắn làm hết trơn, mi chỉ việc xem tụi hắn làm sai chỗ mô rồi báo cho tụi hắn sửa chớ có làm chi mô mà cực”. Có lẽ cũng chính vì suy nghĩ này ăn sâu vào nhiều người nên quan hệ giữa Tester và Dev thường là không thân thiện cho lắm. Nói một cách hình ảnh thì Dev đóng vai “thiện”, chịu nhiều cực khổ, tốn bao nhiêu công sức mới làm ra được phần mềm. Còn Tester đóng vai “ác”, rảnh rỗi, chỉ chăm chăm vô việc đi tìm bắt cái chỗ sai của người ta và sung sướng khi tìm thấy!
“Oan” này của Tester chắc phải to hơn cả “Oan Thị Kính”!
Để hiểu là Tester chịu “oan“ như thế nào thì phải hiểu vai trò của Tester trong công việc sản xuất phần mềm trước. Tester tìm lỗi của phần mềm – điều này chính xác. Tìm lỗi, báo cáo lỗi, kiểm tra lỗi đã được sửa hay chưa là các công việc chính của một tester. Nhưng vai trò của Tester là như thế nào? Lấy một ví dụ: Mấy hôm nay báo, đài, tivi hay đưa tin cái hệ thống bán vé tàu hỏa qua mạng nó bị quá tải, nó bị nghẽn, không thể mua vé được. Thực tế xảy ra trái ngược với tuyên bố của đơn vị chủ quản hệ thống này (Năm nay là năm thứ 2 triển khai hệ thống này, và vẫn lặp lại các vấn đề cũ). Nếu có Tester, các vấn đề này sẽ không xảy ra, hay người ta sẽ biết trước khi nào thì nó xảy ra để có giải pháp. Ví dụ thứ hai: Đôi khi ta thường nghe thấy công ty này, công ty kia bỏ ra cả trăm triệu đồng để xây dựng một cái hệ thống phần mềm. Nhưng khi làm xong thì không thể sử dụng được trong thực tế vì có quá nhiều lỗi. Nếu có tester, điều này sẽ rất khó xảy ra (Ở đây loại trừ các nguyên nhân về quy trình, người dùng không biết được mình muốn gì, kỹ năng quản lý).
Nói tóm lại, Dev là người tạo ra phần mềm, còn Tester là người giúp cho phần mềm đó có khả năng “sống” được trong thực tế. Qua đó, tăng hiệu quả đầu tư, giảm chi phí, tiết kiệm công sức và bảo vệ kết quả lao động của cả nhóm dự án (trong đó có Dev).
Có thể so sánh và đánh giá mối quan hệ giữa Tester và Dev ở một vài khía cạnh sau:
1. Về mặt tâm lý:
Khi người ta tập trung vào công việc của mình, vượt qua thử thách và hoàn thành công việc đó thì phản ứng tự nhiên là vui sướng. Ai làm code chắc cũng đều có lúc cười một mình, nói “lảm nhảm” một mình khi gặp phải những chức năng khó. Để rồi cười sung sướng hay nhảy cẫng lên khi cái chức năng đó chạy. Tester cũng vậy. Sau khi bỏ công sức ra để tìm lỗi (làm thế nào để tìm ra lỗi cũng không đơn giản như nhiều người tưởng) thì người ta cũng có quyền cười chứ?! Đó là cười vì công sức mình bỏ ra đã đem lại kết quả chứ không phải là “cười trên sự đau khổ của người khác” như nhiều người nói.
2. Về vấn đề hiệu quả chi phí và hiệu quả công việc:
Ai cũng biết là các khách hàng nước ngoài (Nhật, Mỹ, …) luôn đặt vấn đề đảm bảo chất lượng lên cao, và họ luôn kiểm thử (test) lại rất kỹ càng trước khi cho triển khai phần mềm ra thực tế hay thanh lý hợp đồng. Các lỗi do phía khách hàng tìm ra phần lớn là bắt buộc phải sửa, và người sửa cũng chính là Dev. Thêm vào đó là uy tín giảm sút, phải làm thêm giờ (OT – Overtime) cho kịp tiến độ, khả năng trễ hợp đồng, tỷ lệ rủi ro tăng cao, … Những nghiên cứu cho thấy, các lỗi được phát hiện càng sớm chừng nào thì chi phí, độ phức tạp, thời gian, công sức để sửa chữa càng thấp chừng nấy. Nếu bạn là Dev, bạn sẽ muốn làm việc theo kế hoạch, sửa những lỗi do chính những người cùng làm việc với mình phát hiện từ sớm và nhận thưởng khi kết thúc dự án, hay muốn làm việc thoải mái suốt 70% thời gian dự án để rồi cuối dự án phải OT liên tục, tốn nhiều thời gian, công sức để sửa các lỗi (sửa cái này thì đụng tới cái khác) và không có thưởng khi kết thúc dự án?
3. Về khối lượng công việc:
Dev phải code nhiều chức năng, sửa các lỗi , OT, tìm hiểu nghiệp vụ, tìm hiểu công nghệ cho nên công việc của Dev căng thẳng và mất nhiều công sức. Nhưng không phải ai cũng biết rằng, Dev chỉ nghiên cứu nghiệp vụ của một vài chức năng mà họ đảm nhận, còn Tester phải nghiên cứu và nắm chắc nghiệp vụ của toàn bộ chương trình để có thể test và hỗ trợ Dev các vấn về về nghiệp vụ. Mỗi dự án khác nhau thường là có các nghiệp vụ hoàn toàn khác nhau. Trong khi đó, sự thay đổi về công nghệ áp dụng của Dev trong các dự án khác nhau là không nhiều.
Dev phải làm OT, nhưng Tester phải vừa test phiên bản cũ (lúc Dev code phiên bản mới) và tiếp tục test phiên bản mới sau khi Dev đã làm xong và “đi đâu đó”. Trong thực tế thì khi nào có lỗi thì mới yêu cầu Dev về sửa, nếu không thì thôi. Còn Tester, luôn luôn ngồi đó và tìm lỗi.
4. Về vấn đề Teamwork:
Dù là Dev hay Tester thì cũng đều là thành viên của một team, mỗi người một vai trò, một chức năng, nhưng có cùng một mục đích là hoàn thành sản phẩm trong thời gian ngắn nhất với chất lượng cao nhất và hiệu suất tốt nhất.
Dev và Tester có mối quan hệ chặt chẽ và hỗ trợ nhau trong công việc. Dev code tốt thì Tester sẽ tốn ít thời gian và công sức để tìm lỗi. Tester tìm ra càng nhiều lỗi và càng sớm thì Dev càng tốn ít thời gian, công sức để sửa (chắc chắn là phải sửa khi khách hàng tự kiểm tra) về sau. Chất lượng sản phẩm, hiệu suất làm việc theo đó cũng tăng lên, rủi ro và độ căng thẳng và thời gian làm việc giảm.
5. Về vấn đề cạnh tranh việc làm:
Những ai dành sự quan tâm cho ngành IT có lẽ cũng nhận thấy rằng, Ấn Độ, Trung Quốc, Philippines, … đang nổi lên là những nước đứng đầu về dịch vụ gia công phần mềm với chất lượng cao, chi phí thấp. Các công ty phần mềm Việt Nam gặp rất nhiều khó khăn để cạnh tranh trên thị trường vì không đủ năng lực, sản phẩm làm ra không đảm bảo chất lượng. Qua đó, ảnh hưởng đến những ai làm trong lĩnh vực gia công phần mềm (trong đó có Dev, tester) ở nhiều góc độ: công việc không ổn định, thu nhập không cao, thiếu việc làm, … Một sản phẩm bị khách hàng quốc tế đánh giá là không đảm bảo chất lượng sẽ là nguyên nhân hàng loạt dự án với giá trị lớn sẽ bỏ ta để đi qua các nước khác.
Tổng kết lại, thái độ đúng đắn cho quan hệ giữa Dev và Tester là phải nhận thức được vai trò không thể thiếu của nhau, là mối quan hệ tương hỗ, hợp tác chứ không phải đối đầu, là có chung một mục đích. Các vấn đề nên được xem xét ở góc độ “làm thế nào để giải quyết và làm cho sản phẩm tốt hơn”.
Và điều cuối cùng tui muốn khẳng định một lần nữa:
“Tester không đóng vai ác!”