Mối quan hệ giữa Developer và Tester

I. Mối quan hệ của Developer và Tester

Trong môi trường sản xuất phần mềm, mối quan hệ giữa Developer và Tester giống như anh trai và em gái. Như mọi người đã biết, anh trai và em gái là cần thiết cho một gia đình đầy đủ, tương tự, Developer và Tester cũng là các yếu tố quan trọng để tạo nên sản phẩm tốt nhất, hoàn hảo nhất.

Ở nhiều công ty sản xuất phần mềm ở Việt Nam, đội ngũ nhân viên chủ yếu là Developer, thậm chí còn có Developer mà không có Tester. Vai trò của tester hiện nay vẫn còn mờ nhạt, nhiều người cho rằng, làm Tester rất là sướng, nhàn, chỉ chăm chăm ngồi chờ bắt lỗi “thằng” khác. Thực tế có phải thế? Chúng ta cùng đi định nghĩa lại công việc của cả 2:

• Developer: Là người xây dựng và phát triển sản phẩm
• Tester: Là người kiểm tra và tìm kiếm lỗi ở sản phẩm Developer tạo ra.

Qua đó, Developer là 1 nhân vật “thiện”, khổ nhọc, vất vả lắm mới làm ra được sản phẩm. Còn Tester lại đóng vai “ác” chỉ ngồi và nhăm nhe bắt lỗi của Developer rồi nhảy lên cười sung sướng khi tìm thấy lỗi. Phải chăng đây chính là nguyên nhân của câu nói: "Kẻ thù số 1 của Developer là Tester".

Trên thực tế, Developer cũng là 1 Tester, họ kiểm tra code của mình, đảm bảo rằng code đó chạy được và chạy đúng. Nhưng đôi khi, họ lại không thể nhận ra được lỗi của chính bản thân mình. Cả Developer và Tester, tuy trông giống như là 1 bên xây dựng còn 1 bên "phá" thành quả của bên kia, nhưng mục đích của cả hai đều là muốn có một sản phẩm hoàn hảo.

Trong quá trình làm việc, có những khi, Developer và Tester tranh cãi nhau về những vấn đề xảy ra trên ứng dụng với các lí do: hiểu sai chức năng, báo sai bug, ...Những lúc như thế rất là gây mất đoàn kết nội bộ, làm ảnh hưởng đến bầu không khí làm việc và mối quan hệ của developer với tester không được tốt như lần đầu nhìn thấy nhau nữa.

Có thể đánh giá mối quan hệ của Developer và Tester qua các 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à Developer. 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à Developer, 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: Developer 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 Developer 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, Developer 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ợ Developer 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. Developer phải làm OT, nhưng Tester phải vừa test phiên bản cũ (lúc Developer code phiên bản mới) và tiếp tục test phiên bản mới sau khi Developer đã làm xong và “đi đâu đó”. Trong thực tế thì khi nào có lỗi thì mới yêu cầu Developer 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à Developer 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. Developer và Tester có mối quan hệ chặt chẽ và hỗ trợ nhau trong công việc. Developer 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ì Developer 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ó Developer, 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.

II. Các vấn đề hay gặp phải và giải pháp

Dưới đây, là một số vấn đề căng thẳng trong môi trường làm việc, khi các Tester thông báo cho Developer:

1. Nó là 1 lỗi không phải là 1 tính năng. Nó không làm việc theo cách đó

• Nhờ quản lí dự án xem chính xác những "tính năng" dùng để làm gì, bằng cách cập nhật tài liệu hướng dẫn
• Nếu không có tài liệu hướng dẫn để làm rõ tình hình, có lẽ do quản lí dự án chưa nghĩ đến những thao tác ngoài dự kiến. Kiểm tra trực tiếp nếu đó là vấn đề lớn? Có cần phải fix ngay lập tức?

1. Nó không bị trên máy của tôi

• Nó hoạt động trên máy của bạn, và bạn không thể tái tạo các vấn đề, vì vậy làm thế nào bạn có nghĩa là để khắc phục nó? Sử dụng máy của tester. Hoặc yêu cầu Tester chứng minh các bước sao chép lỗi chính xác trên máy của bạn.

1. Nó được làm việc ngày hôm qua, nó bị hỏng của anh A.

• Đặc biệt là nếu có nhiều hơn một Developer làm việc trên một hệ thống hoặc nếu mã được phân nhánh. Có lẽ nhiều bản cập nhật đã xảy ra trên các tập tin chia sẻ. Có lẽ một thư viện tài liệu tham khảo đã được sửa đổi. Lấy quản lý cấu hình / phát hành để kiểm tra những gì đã thay đổi kể từ ngày hôm trước hoặc phiên bản và sửa chữa nó. Đừng đổ lỗi hay cáo buộc các lập trình viên của bạn cho một cái gì đó là không thể tránh khỏi. Phần mềm là không ổn định. Tất cả mọi người sớm chấp nhận điều này.

1. Nó không phải là specs mà là một gợi ý.

• Vai trò của một Tester không chỉ là để tìm và đăng nhập lỗi. Nó cũng là để xem những gì sẽ xảy ra khi bất ngờ xảy ra. Để hoạt động như một tài liệu tham khảo cho tiến độ chung của dự án. Để đặt câu hỏi không ai khác đã nghĩ đến. Để cung cấp một góc nhìn khác nhau. Để dự đoán các vấn đề trong tương lai. Để làm nổi bật những khoảng trống trong các yêu cầu, sự hiểu biết và thực hiện. Đề xuất cải tiến đó sẽ làm cho cuộc sống của người sử dụng dễ dàng hơn.

III. Kết luận

Developer là người tạo ra và phát triển sản phẩm. Tester là người kiểm tra sản phẩm. Do đó, cả hai đều là cần thiết cho việc hoàn thành dự án và cũng như để làm cho sản phẩm theo định hướng chất lượng và đáng tin cậy.