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

Tác giả: Phạm Hữu Ngọc

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.

Nội dung chính

Khi mình làm việc ở công ty đầu tiên trong sự nghiệp
Mình đã có một cái nhìn khác về việc tìm ra bug
Bài học rút ra

Chắc hẳn chúng ta đều khá quen thuộc với nội dung của bức hình bên dưới 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.

Khi mình làm việc ở công ty đầu tiên trong sự nghiệp

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,…

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:

History (Lịch sử): sản phẩm phải nhất quán với các phiên bản trước đó
Image (Hình ảnh): nhất quán với giao diện và hành vi được mong đợi của sản phẩm
Comparable Products (Sản phẩm tương đương): nhất quán với các đối thủ cạnh tranh, tài liệu tham khảo hoặc các giải pháp khác cho các vấn đề tương tự
Claims (Tuyên bố): nhất quán với các tuyên bố bằng văn bản hoặc miệng về sản phẩm
User Expectations (Kì vọng của người dùng): nhất quán với những gì một người dùng hợp lý mong đợi
Product (Sản phẩm): nhất quán với chính nó
Purpose (Mục đích): nhất quán với các lý do để tạo/ sử dụng sản phẩm
Standards and Statutes (Tiêu chuẩn và Pháp lệnh): nhất quán với các tiêu chuẩn hoặc các cơ quan khác
Familiarity (Sự quen thuộc): không nhất quán với các vấn đề đã thấy trước đó
Conversations (Các cuộc trò chuyện): nhất quán với các kết luận từ đối thoại

Mình đã có một cái nhìn khác về việc tìm ra 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.

Phạm Hữu Ngọc

Web Application Developer

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

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.

Bài học rút ra

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.

Càng biết nhiều, ta càng hiểu mình còn chưa biết gì.

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é.

Đô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.