Tôi đã NGƯNG PHẢN BÁC với Tester khi biết điều này!

Chắc hẳn chúng ta đều khá quen thuộc với nội dung của bức hình trên phải không ạ, chuyện tranh luận giữa DEV và TESTER là điều khó tránh khỏi khi làm việc. Hồi đó mình cũng từng hay như vậy nhưng sau một quá trình làm việc và được một người anh chỉ bảo, mình đã thay đổi tư duy của mình, và hạn chế tình huống phía trên xảy ra.

Chào mọi người, Mình là một Ruby on Rails Developer khoảng 3 năm tuổi nghề. Năm nay mình 25 tuổi, một độ tuổi cũng chưa đủ để gọi là trưởng thành nhưng cũng không còn nhỏ nữa, sau vài năm làm trong nghề lập trình, mình đã được học hỏi rất nhiều thứ và dần hoàn thiện bản thân. Trong đó có một kiến thức đã giúp ích cho mình sau này rất nhiều, đó là xác định 1 con bug.

Chuyện xảy ra hồi đầu năm 2021, khi mình làm việc ở công ty đầu tiên trong sự nghiệp, là một fresher Developer, nên mình cần phải học hỏi rất rất nhiều. Tuy nhiên hồi đó mình hay bị bảo thủ và tự cao, luôn cho mình là đúng, vậy nên mình rất hay phản bác, cằn nhằn về những con bug mà QC báo lên.

Trừ những con bug về logic đã có trong tài liệu của BA trước đó thì mình sẽ xử lý ngay, còn có khi QC báo những con bug ở các trường hợp đặc biệt, những tình huống mà ít khi xảy ra trong thực tế, hay những con bug về những logic không nằm trong thiết kế ban đầu của BA, mình đều phản bác rất nhiều, hay những tình huống bắt buộc mình phải xử lý thì mình vẫn luôn cằn nhằn, có nhiều lần khiến cho không khí làm việc trong team khá là căng thẳng. Mình luôn tự hỏi: tại sao mình lại phải dành nhiều thời gian và công sức chỉ để đi xử lý, ngăn chặn những tình huống khá là hiếm gặp hoặc có thể là không có trong thực tế sử dụng?

Cho đến khoảng giữa năm 2021, khi team của mình có thêm 1 anh senior QC, thì lúc này mình đã được thay đổi nhiều về cách suy nghĩ và nhìn nhận. Cũng giống như các anh chị QC khác, mình cũng hay tranh luận về một số con bug mà anh ấy đưa lên. Nào là nó không định nghĩa trong tài liệu, nó là bug từ hồi xưa giờ sao em sửa, rồi nào là người dùng thực tế người ta không có làm vậy đâu, vv...vv

Nhưng sau đó mình đã được tham gia những buổi thuyết trình của anh ấy về định nghĩa thế nào là Bug, Bug là trách nhiệm của cá nhân hay cả team, vv..vv, điều đó đã giúp mình cải thiện về cách nhìn nhận rất nhiều. Đặc biệt là buổi thuyết trình về HICCUPPS, 1 tập hợp các nguyên tắc để xác định bug:

Nhờ những kiến thức này, mình đã có một cái nhìn khác về việc tìm ra bug, đó là mình phải luôn đảm bảo sản phẩm làm ra phải thật chất lượng, không thể để xảy ra sự cố dù là tỉ lệ thấp nhất và đó là trách nhiệm - mục tiêu chung của cả team. Mình không còn ghét phải fix bug nữa, mà mỗi lần có bug được báo lên, mình rất vui vẻ đón nhận, và biết rằng team lại ngăn chặn được 1 quả bom hẹn giờ trong tương lai.

Đến bây giờ, tuy không còn làm việc ở công ty cũ nữa, nhưng mình rất cảm kích về những kiến thức quý giá mà mình đã học được, và đó là những hành trang quý báu cho con đường sự nghiệp còn dài. Hiện tại khi mình đang làm ở công ty mới, mình sẽ phải tự kiểm tra kỹ code của mình, chứ không còn QC làm chốt chặn cuối nữa, nhưng mình vẫn rất tự tin và áp dụng những kiến thức mà mình đã có được từ những anh chị QC ở công ty cũ để có thể đảm bảo code của mình thật chất lượng và hạn chế bug trên production.

Từ câu chuyện này, mình hy vọng mọi người sẽ rút ra được một bài học vô cùng quan trọng khi làm việc trong lĩnh vực công nghệ. Đó chính là tôn trọng và học hỏi từ mọi người xung quanh, không bao giờ nên tự cao và tự cho mình là đúng. Đôi khi, những con bug mà chúng ta thấy là không quan trọng, nhưng nó lại ảnh hưởng rất lớn đến trải nghiệm của người dùng. Chúng ta cần tìm hiểu, cập nhật kiến thức mới và luôn luôn tập trung vào sự hoàn thiện của sản phẩm để mang lại giá trị tốt nhất cho khách hàng và người dùng.

Việc học hỏi, cập nhật kiến thức và đón nhận ý kiến từ các thành viên khác trong team là cách tốt nhất để trở thành một nhà phát triển phần mềm thành công, chúc mọi người sẽ gặt hái được nhiều thành quả trong con đường phía trước nhé.