Developer và Tester - Chuyện Chưa Kể

[tvn]

Hôm nay mình xin kể một chuyện mà một bạn đang kể trên group Skype của TVN
Bạn ấy kể rằng:

• Có ai có kinh nghiệm về tình huống này thì xin chia sẻ bí quyết cho mình với nha. Chuyện là, developer không bao giờ nhận mình sai, chỉ đổ lỗi cho tester là sai. Developer nói rằng không phải developer không hiểu vấn đề mà là tester không hiểu vấn đề. Nhưng trong khi đó, developer fix bug này thì lòi ra chục bug khác.

[tvn]

Nếu chắc chắn đó là bug thì đi hỏi Team Lead cho team lead giải quyết thôi, có nhiều bug hỏi ra mới biết cũng chẳng cần sửa

Lôi developer đó ra tẩn cho một trận

team dev Công ty em ở "nước quài" thì đập bằng niềm tin à?

Mặc kệ đi anh ơi, bỏ đi anh, cứ open bug => nó cancel => lại re-open tiếp

Comment: nhìn có vẻ hiền nhưng không hiền

[tvn]

Hồi xưa,... ông nào căng với mình thì mình email offical thôi, giấy trắng mực đen cho phẻ.

Tester phải dựa hơi PM càng nhiều càng tốt
Nếu có Khách hàng ngồi chung dự án thì dựa hơi khách hàng
Phải thể hiện cho khách hàng thấy mình vì quality của sản phẩm, tester ở đây là vì họ
Phải thể hiện cho DEV thấy mình ko rỗi hơi bắt nhảm mà mình bắt theo ý khách hàng. Hết
Còn đối với dự án Testing Service thì khó hơn nhiều
Nhiều lúc khách hàng chính làm đám dev

Tại vì mình nghĩ làm chung Công ty, chung dự án nên cũng không muốn đôi co qua lại không hay. Đang suy nghĩ về việc sẽ nói với lead của dev giải quyết, và nghĩ cách nói chuyện sao cho tế nhị chút.

Em cũng đang gặp trường hợp tương tự, nhưng chưa biết giải quyết sao vì Công ty em là cty làm product

[tvn]

Hồi xưa đi phỏng vấn gặp câu này, mình trả lời: Tester qua giải thích với developer đó, và hai bên cùng thống nhất xem ai sai.

Nhưng người phỏng vấn ở Công ty Thứ Nhất không đồng ý, họ nói: em không xử lý như vậy được, em là tester, khi em đưa bug lên là chắc chắn đó là bug rồi, đó là công sức em làm ra và một khi đưa lên nghĩa là em đã đắn đo cân nhắc hết rồi. Developers bắt buột phải fix thôi, không cãi. Kết quả là em bị out.

Rút kinh nghiệm đợt 1, tới lúc phỏng vấn ở Công ty Thứ Hai, cũng gặp lại câu hỏi này. Em, ngay và luôn, lấy đáp án của Công ty Thứ Nhất để trả lời cho câu hỏi này => thế là out luôn.

Giờ đi làm thì thấy luôn sử dụng cách nguyên thủy của mình (đáp án đã trả lời ở Công ty Thứ Nhất), khi nào bí quá thì gọi anh Leader ^^

Chuyện bạn trả lời câu này như trên, không có nghĩa là bạn "bị out" vì nó, nhiều khi bạn bị out vì những câu khác. Mình nghĩ vậy.

[tvn]

Một số dev rất cứng đầu với tester, nhưng khi nghe hù "méc PM, Team Lead phát" là lại xìu ngay =))

Mình thấy chuyện này cũng bình thường thôi, hay gặp.

[tvn]

Đơn giản là có 1 số người communication xì-kiu của họ mạnh ở face to face communicate, một số khác thì mạnh ở report thôi

Và khi bạn muốn tìm ra phương pháp giải quyết thích hợp thì face to face chiếm ưu thế hơn. Chẳng phải bug nào post xong cũng biết là nên giải quyết thế nào là đúng

[tvn]

Có ai có kinh nghiệm về tình huống này thì xin chia sẻ bí quyết cho mình với nha. Chuyện là, developer không bao giờ nhận mình sai, chỉ đổ lỗi cho tester là sai. Developer nói rằng không phải developer không hiểu vấn đề mà là tester không hiểu vấn đề. Nhưng trong khi đó, developer fix bug này thì lòi ra chục bug khác.

Sự việc này, mình có ý kiến như sau.
Theo mình thì, chuyện developer đổ lỗi cho tester hay người khác và chuyện developer đó fix 1 bug lòi ra 3 bug khác là hai chuyện khác nhau. Mình chỉ muốn đóng góp ý kiến của mình về vấn đề "đổ lỗi cho nhau."

Tại sao khi có vấn đề, chúng ta không cùng ngồi xuống và tìm ra cách giải quyết vấn đề, thay vào đó lại đổ lỗi cho nhau? Có thể do mọi người thích "đá banh"

Mình là Tester (hay là QC/QA - nói chung đang đứng về góc độ quan tâm nhiều đến chất lượng sản phẩm) thì mình phải luôn nhớ nhiệm vụ của mình là gì, mục tiêu của dự án là gì, vai trò của mình trong dự án đó là gì? Tiếp sau đó, mọi vị trí trong dự án cũng phải có suy nghĩ tương tự. Mọi người ở trong cùng 1 nhóm, 1 dự án giống như tất cả mọi người đang ở trên một con thuyền. Team lớn, dự án lớn thì như là thuyền lớn; Nếu là team nhỏ, dự án nhỏ thì là thuyền nhỏ, thuyền nan. "Thuyền to sóng lớn" người Việt Nam mình vẫn hay nói câu này, nhóm dự án lớn thì công việc quản lý càng phức tạp, công việc cũng nhiều, nếu task của ai đó gặp vấn đề thì có thể ảnh hướng đến task của nhiều người khác.

Nếu mọi người đang ở trên cùng thuyền thì tại sao mọi người không cùng nhau lái con thuyền (project) đó đến đích (ví dụ release sản phẩm) đã dự định một cách nhanh nhất và an toàn nhất có thể? Nếu mọi người cùng chèo về một hướng thì có phải con thuyền sẽ đi đến đó nhanh hơn không? Tại sao mọi người phải chèo theo nhiều hướng khác nhau, rồi dành thời gian tranh cãi nên chèo theo hướng nào là tốt hơn? Nói thì nói vậy thôi chứ con người trong xã hội thì mỗi người một tính, không ai chịu ai hết. Mình biết, văn hoá nhóm như thế này phải mất thời gian dài mới có thể xây dựng được. Nhưng nếu mỗi người cố gắng 1 xíu là mọi thứ sẽ nhanh chóng tốt đẹp. Tất cả vì lợi ích chung.

Nhiều bạn cho mình biết, trong Công ty các bạn ấy, các Testers và Developers mới vào làm, được tiền bối dạy rằng "mài không được nhường nó, fight nhiệt tình vào." Thử hỏi "lớp này dạy lớp kia" như thế thì làm sao những người mới vào team họ có thiện cảm và có suy nghĩ nhường nhịn mọi thứ vì mục tiêu cao cả là hoàn thành dự án với chất lượng cao nhất có thể?

Chưa kể, giận cá chém thớt, bực mình chuyện vợ chồng bồ bịch, vào Công ty đổ lên đầu người khác. Nhất là các Leader, lúc đang có tâm trạng không vui, thì member hôm đó y như rằng sẽ ăn hành đủ các món luôn

Sau đây là một số lời khuyên trích từ ISTQB CTFL, nếu ai đã từng học ISTQB thì sẽ biết.

Để cải thiện vấn đề giao tiếp giữa Tester và các đồng nghiệp khác trong nhóm dự án, mọi người nên:

• * Khi trao đổi về vấn đề gì đó, nhất là nói về bug / lỗi của sản phẩm, thì nên bắt đầu hợp tác chứ không phải bắt đầu một cuộc chiến - và nên nhắc mọi người rằng mục tiêu chung của nhóm là tạo ra sản phẩm / hệ thống phần mềm với chất lượng tốt hơn;
  * Khi nói chuyện về lỗi của sản phẩm / hệ thống thì NÊN tập trung vào lỗi, KHÔNG nên tập trung vào NGƯỜI tạo ra lỗi;
  * Bản thân mình cũng nên dành thời gian để cố gắng hiểu người khác và hiểu cảm giác của họ để hiểu lý do tại sao họ đã phản ứng với mình như vậy;
  * Về giao tiếp, tránh đổ lỗi cho nhau sau này, thì trước khi kết thúc buổi bàn bạc, thảo luận, mình nên xác nhận rằng mọi người đã hiểu ý nhau và thống nhất, nhất trí với nội dung đã trao đổi.

Mình xin giới thiệu một đề xuất từ một bạn Nữ dễ thương chuẩn bị bước vào nghề tester, như sau:

• Phương án 1: Nếu developer và tester tranh cãi nhau (không phải là tranh luận), thì bắt 2 em nó ÔM nhau 30 phút.
  Phương án 2: Phạt developer và tester đó, mỗi người ôm 1 cái cây (hay cái trụ gì đó trông Công ty) và nói "Cây ơi, anh/em yêu em/anh 50 lần"
  Nếu làm như vậy, sau này, trước khi bắt đầu "cãi nhau" là nghĩ đến cảnh tượng đó sẽ tởn tới già

//Comment riêng của mình về "giải pháp xử lý" developer và tester. Nếu áp dụng phương pháp 1, không khéo mấy anh developer không lo làm việc mà cứ lo kiếm mấy em tester dễ thương để kiếm chuyện "tranh cãi" suốt Có vẻ khó khả thi .

[Nguyen Duong Hai]

Hi các bạn,
Mình là 1 QA có 6 năm kinh nghiệm và mình rất đồng ý với những gì mà admin đã nói ở trên, trừ cái vụ ôm nhau
Nếu các bạn đã làm việc nhiều năm, hoặc là có quan hệ tốt với Developer các bạn sẽ thấy họ có rất nhiều khó khăn. Những chuyện chưa kể hoặc chẳng ai muốn kể:
1/ Họ estimate 1 task nhưng thường bị ép xuống, mình sẽ không nói lý do ở đây. Hoặc họ tự mình estimate thấp vì sợ bị đánh giá. Cái thời gian bị ép xuống đó, chính là cái thời gian mà đáng lẽ Developer cần có để suy ngẫm về task của mình và requirement. Họ từ developer chuyển thành "coder".
2/ Requirement thường không bao giờ rõ ràng. Như là 1 QA, mình luôn thấy requirement thường có thể hiểu theo nhiều kiểu. Mình tin là các bạn cũng fai confirm lại từ PM và BA về spec như cơm bữa. Và, theo "bản năng", developer sẽ hiểu theo cái cách mà họ đã hiểu trong "5ph estimate", hoặc là hiểu theo cách mà dễ implement nhất. Đáng buồn là đời thường chẳng như mơ.
3/ Developer khác với QA, đôi khi cái họ được phân công là 1 HÀM, chứ không fai 1 CHỨC NĂNG. Họ đôi khi chẳng biết cái mình viết ra để phục vụ cho cái đếch gì, chỉ đơn giản là Dev lead yêu cầu, đồng nghiệp yêu cầu thì họ viết. Nói ngằn gọn là, Developer thường không có cái nhìn tổng quát về chức năng như tester, vì họ chỉ làm 1 phần trong nó mà thôi.

Bạn có thể thấy, với những khó khăn đó, Developer khi bị bạn tìm ra lỗi, sẽ có 1 sự hụt hẫng và sợ hãi không hề nhẹ. Vì người ta nghĩ rằng đó là do người ta dở, và tê hơn là người ta thấy viễn cảnh là phải fix bug. Hơn hết, ở tình huống đó, bạn và Developer đang ở tình thế là 1 người đúng và 1 người phải sai. Mình tin rằng bạn có lúc cũng là người sai và cảm giác chẳng dễ chịu gì, đúng không?

Sẽ có một số ý kiến cho rằng "Chuyện đó để manager giải quyết!". "Dev nói chuyện với manager là xìu ngay!". Mình xin hỏi nếu bạn bị đặt vào tình huống của họ, bạn có thật sự làm việc tốt, thật sự hiểu spec để làm ra product tốt không? Hay chỉ là đồng ý, vâng lệnh làm cho qua chuyện?
Có một số kinh nghiệm này mình rút ra được:
- Nếu không ai giúp Dev những vấn đề ở trên, thì 1 ngày QA có tìm ra 100 bugs, Dev miễn cưỡng fix hết 100 bug thì cũng lòi ra 100 bug khác mà thôi.
- QA, thật lòng mà nói, để thật sự tìm thấy bug nhanh và rõ ràng thì luôn cần Developer giúp đỡ. Developer chính là đồng minh lớn nhất của QA. Bạn nào đã từng làm dự án mà không được nói chuyện với Dev thường xuyên sẽ thấm thía vấn đề này.
- Nếu bạn, hay tất cả mọi người đều ép Developer, thì họ sẽ giấu bug!. Và tin mình đi! Họ mà đã muốn giấu thì bạn khó mà tìm ra đó! Đến lúc mấy bug đó lòi ra thì không vui đâu. Có khi là Hiện pop up chửi bởi này nọ, hoặc là backdoor đó!
Vậy, bạn định sẽ giúp Developer hay bạn định làm 1 thằng công an, đợi developer làm ra lỗi rồi la inh ỏi lên?

Hãy giúp Developer bằng cách:
- Khi họ estimate, hãy estimate cùng họ, nói cho họ biết chỗ nguy hiểm mà bạn có thể nghĩ ra, để giúp họ estimate tốt hơn
- Tìm ra vấn đề càng sớm càng tốt. Họ càng ít tốn công sức làm ra, thì họ càng dễ thay đổi khi thấy cái sai, và tâm lý cũng dễ chịu hơn!
- Hãy làm sao để tự Developer thấy vấn đề, tức là nói làm sao để Dev tự nhận ra họ sai. Đừng nên nói để chứng tỏ rằng tui hay hơn bạn!
- Đừng bao giờ nghĩ mình là QA là mình nắm hết! Developer, theo mình mới là người biết rõ ngóc ngách của hệ thống này
- Khi 2 bạn tranh cãi, 30-30 là 1 trong 2 người đúng, 40% còn lại là đếch thằng nào đúng hết!. Mình đã từng gặp nhiều trường hợp khi BA đi xuống giải quyết, thường là nói "Nghĩ như Dev cũng được!" Hoặc là "Anh lúc đầu muốn như QA vậy, như giờ timeline vậy rồi thôi làm cách này đi!" hoặc là "Ko! em nói cũng đúng nhưng anh còn muốn cái này nè....!" Hãy luôn giữ lời khuyên này để nói chuyện 1 cách ôn tồn.


Đây là kinh nghiệm của mình. Hy vọng từ những câu ví dụ, quote mà mình đưa ra bạn sẽ thấy bạn trong một số trường hợp. Chúc các bạn làm việc vui vẻ và hiệu quả!

[Tanbk54]

cho em vào nhóm skype nữa anh ơi

[tvn]

cho em vào nhóm skype nữa anh ơi

Em add nick anh đi nha, hoangliensonmt, rồi anh add vào.

Vui lòng đọc nội qui nhóm Skype TVN trước khi vào group.