Chuyện tình Dev - Tester

Chúng ta của hiện tại "Anh dành hết thanh xuân để fix Bugs, em dành hết thanh xuân để find Bug, chúng ta vì Bug mà cãi nhau rồi chia xa". Tóm lại chỉ tại con Bug =))

Người ta vẫn thường ví mối quan hệ của Dev và Tester giống như một cuộc tình giang dở. Làm sao để họ "cơm lành, canh ngọt" với nhau? Dù là Dev hay Tester chúng ta cũng xem như người trong một nhà. Sống trong một gia đình, điều quan trọng nhất là hòa thuận, đoàn kết, thấu hiểu và chia sẻ. Một vấn đề để giải quyết được thì chúng ta cần phải hiểu rõ về nhau đã. Cùng mình tìm hiểu trong bài viết này nhé:

(*) Công việc của đối phương là gì?

(*) Làm sao để dung hòa hai thế giới?

(*) Agile Testing mindset??? Bạn nghe bao giờ chưa???

(*) Những câu chuyện muôn thuở Dev và Tester

1. Mối quan hệ giữa Dev và Tester

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 do Dev 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". 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 ổn định và chất lượng nhất đến tay người dùng.

Nếu bạn đã biết về Srum thì chắc hẳn bạn sẽ biết trong Scrum không có roles Dev hay Tester mà chúng ta được gọi chung là Developers(Development team). Không hề có sự so sánh khác biệt hay khoảng cách nào bởi vì sao vì chúng ta là một, vậy nên hãy thông cảm và thấy hiểu cho nhau nhé "WE ARE ONE"

2. Công việc của Dev và Tester

Mỗi người chúng ta sinh ra đều mang trong mình một cái tài riêng, một cách nhìn nhận và mindset riêng, cũng như việc "Bắt một con cá leo cây" để đánh giá tài năng của nó thì mãi mãi nó chỉ là đồ vô dụng. Sự khau nhau về bản chất công việc cũng yêu cầu mindset của Dev và Tester có sự khác nhau.

Vậy mindset của Dev-Tester khác nhau như thế nào

Liệu việc khác biệt trong tư duy giữa tester và developer có phải là tốt? Câu trả lời là: CÓ.

Trong khi mối quan tâm của một developer đó là tìm giải pháp cho vấn đề hiện tại, thì một tester quan tâm tới việc tìm ra lỗi và các lỗ hổng trong sản phẩm. Vì lí do này, nên việc giao trách nhiệm những hoạt động testing chủ yếu cho Tester sẽ là phương thức tốt nhất. Khi một developer test một sản phẩm, một vài kịch bản test có thể bị bỏ sót bởi vì cách tư duy đã được hình thành trước và không thể tách suy nghĩ ra khỏi mã code của họ. Nhưng khi một Tester nắm giữ nhiệm vụ này, họ sẽ có cái nhìn mới mẻ và có cơ hội tìm ra nhiều sai sót hơn. Sự khác biệt này chính là tư duy kiểm thử phần mềm được đánh giá cao nhất bởi rất nhiều công ty, và hầu hết công ty thường xây dựng những đội ngũ phát triển và kiểm thử sản phẩm riêng biệt.

Là Dev bạn có bao giờ thắc mắc "Tụi phá app" kia ngoài phá app ra còn làm gì nữa?

Là Tester có bao giờ bạn nghĩ "Bậc thầy tạo ra bug" kia ngoài tạo ra Bugs còn làm gì nữa?

Công việc của Dev- Tester

Chúng ta luôn tin tưởng bản thân mình thì Dev cũng vậy thường có xu hướng tự tin về khả năng lập trình của mình và có xu hướng nghĩ rằng những dòng code của họ hầu như không có lỗi. Nhưng có một sự thật phũ phàng rằng "Ở đâu có code ở đó có bug"

Rõ ràng, nếu Dev nắm chắc kỹ thuật thì chắc chắn sẽ biết chỗ sai của mình. Vậy tại sao khi sản phẩm vào tay Tester, dẫu đã test case đầy đủ, Unit Test ngon lành cành đào mà bug vẫn tuồn ra như quân nguyên? Thế là xung đột bắt đầu và mối quan hệ từ đó "đi xuống"...

3. Dung hòa hai thế giới

Theo mọi người đâu là nguyên nhân dẫn đến cãi vã giữa Dev và Test , đó là do họ không hiểu nhau ngay từ đầu, không đặt mình vào vị trí của nhau. Dev chỉ mãi nghĩ về trường hợp chạy ổn định, nhưng Tester lại nghĩ về những trường hợp "kinh dị" nhất. Bảo sao mà "mối quan hệ lại đi xuống". Vậy làm thế nào giúp Dev có thể thấu hiểu Tester, giao tiếp với Tester dễ dàng hơn:

Suy nghĩ tích cực đặt mình vào vị trí của nhau
Luôn nghĩ về sản phẩm đặt chất lượng sản phẩm lên làm đầu
Bắt đầu từ giai đoạn phân tích yêu cầu nên có sự tham gia của cả 2 bên
Dev nên áp dụng mindset Tester khi viết Unit test
TEST-DRIVEN DEVELOPMENT?
Tỏ ra thoải mái với các cuộc xung đột
Luôn nâng cao skills của bản thân

Trên này mình có nhắc đến khái niệm TEST-DRIVEN DEVELOPMENT. Bạn đã bao giờ nghe đến chưa. Đặc biệt là phía Dev, bình thường sau khi nhận được requirement chúng ta sẽ tiến hành code trước sau đó mới test lại đúng không ạ. Tuy nhiên với quan điểm Agile Testing thì hoàn toàn ngược lại, bạn nên viết Test trước khi Code. Trước đây đối với một lập trình viên có thể bạn không cần biết đến Unit Test nhưng giờ đây để có thể trở thành một Coder chuyên nghiệp chắc chắn bạn phải làm quen với khái niệm này nhé.

Tại sao cần viết Test trước khi Code

Linh hoạt hơn và có thể mở rộng…
Code của chúng ta sẽ sạch sẽ hơn
Ngăn chặn lỗi
Có thể bảo trì dễ hơn

4. Những câu chuyện muôn thuở

Đó là tính năng không phải Bug

Chuyện Dev luôn cãi Bug và không nhận Bug là một chuyện diễn ra khá thường xuyên như cơm bữa. Vậy là Tester chúng ta sẽ xử lý như thế nào. Dưới đây là một ví dụ mình đưa ra để chúng ta cùng phân tích

Hệ thống mất 5s để xử lý một thao tác => Đó có phải bug

Gmail mất 5 giây để xử lý một email, mọi người thường nghĩ như vậy khá tốn thời gian và rõ ràng là một khuyết điểm. Nhưng đội ngũ phát triển đã tìm ra một cách hay để thoát khỏi việc “gắn mác” lỗi bằng cách biến nó thành tính năng “Unsend”, không ngờ tính năng này lại vô cùng hữu dụng trong trường hợp bạn quên đính kèm file hay nhấn nhầm nút gửi khi chưa kịp trau chuốt từ ngữ trong mail.

Vậy trong trường hợp này thì đúng là không phải Bug và Tester có thể tin Dev thật. Tuy nhiên tùy trường hợp thôi nhé ^^

Nó không bị trên máy của tôi .Bug chỉ bị ở Staging??? Local của dev vẫn oki la??? Có cần fixx không

Chiện này lại cũng diễn ra thường thường xuyên luôn nè.

Cái này sẽ tùy vào từng môi trường, data khác nhau mà bug có thể xảy ra hoặc không. Và quan trọng những môi trường đó end-user có hay dùng không. Dựa vào những thông tin này Dev sẽ fixx hay không và đánh độ ưu tiên fix bug hợp lý

Tester: Tái hiện trên máy khác xem có gặp vấn đề hay không. Log bug và note rõ môi trường , OS, browser test

Nó chỉ là support thôi, không quan trọng đâu mình fix sau cũng được cứ release đi đã Tester nhé

Chuẩn bị release thì Tester feedback về tính năng upload ảnh đến Dev. Tuy nhiên Dev nói không ảnh hưởng gì đâu nên cứ Release đi, Dev sẽ fix sau. Tester nhẹ dạ cả tin thế là cũng chấp nhận bỏ support vào backlog và đồng ý Release. Cuối cùng sau khi release thì khách hàng cảm thấy tính năng upload ảnh không được linh hoạt vì up ảnh lên mà không xóa được. Yêu cầu cả dự án Hot fixx luôn -_-

Vậy mới nói có những ticket không phải là Bug mà là Support nhưng vẫn cần fix để đảm bảo sự thân thiện với người dùng. Dev đừng lươn Bugs mà Tester cũng đừng nhẹ dạ cả tin.

Nói gì thì nói. chúng ta cuối cùng cũng chỉ vì dự án mà thôi, hãy luôn cố gắng thấu hiểu và tôn trọng nhau, cùng nhau mang lại những sản phẩm tuyệt vời nhất nhé!

Cảm ơn mọi người đã đọc bài viết của mình, nếu thấy hay hãy upvote để ủng hộ mình! Và comment chủ đề bạn muốn mình chia sẻ tiếp theo nhé ^^

Join group để học hỏi, chia sẻ thêm kiến thức về kiểm thử nhé, mình có chữa đề istqb foundation trên group: https://www.facebook.com/groups/itester

Follow và Upvote để mình có thêm động lực viết bài