Câu chuyện về bug: sai data type

Mình xin kể lại 1 câu chuyện về bug mà mình gặp gần đây, ticket đã trôi qua được hơn 1 tháng kể từ thời điểm khách hàng báo và đã có 50+ lượt comment qua lại trên jira, nếu bạn tester nào ko follow ticket từ đầu thì chắc lội 50+ comment mà mỗi comment lại dài như sớ thì chắc cũng nản. :))))

Trước tiên mình sẽ giới thiệu 1 chút về sản phẩm của mình làm:

  • Đó là 1 sản phẩm về phân tích dữ liệu (data analytics), nó có 1 cái gọi là spreadsheet, tương tự như excel. Trên spreadsheet, khách hàng có thể đẩy vào dữ liệu dưới dạng text, number, datetime… rồi từ spreadsheet sẽ gọi các function tính toán, các thuật toán, công thức trong ngành khoa học dữ liệu (data science), để cho ra các kết quả cuối cùng (report) bằng text hoặc chart.

Giới thiệu 1 chút về dữ liệu (data):

Data được chia làm 2 loại:

  • Numerical data: là số, số nguyên (10, 2200) hay số thập phân (2.143)
  • Categorical data: dùng để phân loại và nhóm groups, ví dụ male là 0, female là 1, N/A là 2

Tùy vào loại data mà spreadsheet ở trên sẽ tự động convert, ví dụ khách hàng điền text “2.67” thì spreadsheet sẽ convert sang double 2.67. Tương tự, nếu spreadsheet thấy cả cột là text, ko thể convert sang double, thì nó sẽ tạo ra categorical data, ví dụ: BMW là 0, Mercedes là 1, Toyota là 2 …

Giờ đến câu chuyện lịch sử và bug:

  • Version 13.1 (2016): phần mềm vẫn hoạt động như mô tả phía trên
  • Version 13.3 (2018): dev có làm thêm 1 phần optimization để tăng performance, đã thay đổi cách convert dữ liệu, bỏ qua luôn step tự động convert text sang double nếu như text đó dạng number-like –> data “2.67” vẫn là “2.67”, chứ ko phải là 2.67. Vì sao cần optimize, vì với suy nghĩ nếu data là text thì chắc chắn là dạng categorical data, mà categorical lại lưu vào data type là double thì lãng phí memory quá (64bit), tạo thêm cho khách hàng option để lựa chọn, nếu chỉ dưới 256 thì dùng loại Byte (8bit) thôi, hoặc lớn hơn chút thì dùng Integer (32bit), cuối cùng mới là double.
  • Bây giờ (2023) + version 14.0.1: khách hàng kêu là chức năng vẽ chart sai.

Tại sao bug này nằm ở đó lâu như vậy mà không 1 ai kêu ca, đến giờ mới có 1 khách hàng báo? Vì:

  • Nguyên nhân 1: Data của khách hàng lấy 1 database nào đó và data type của column là dạng text (varchar trong DB). Bất ngờ đúng ko? Ai có thể design DB để lưu data dạng number vào 1 column dạng text??? Vì quy trình nó bị convert type 2 lần.
  1. Phần mềm X: Nhập liệu (điền number) –> convert sang text
  2. Database: Save text
  3. Phần mềm bên mình: Get text –> convert sang number –> vẽ chart

Tại sao ko lưu data dạng number luôn từ đầu, có phải mọi thứ đơn giản ko?

  1. Phần mềm X: Nhập liệu (điền number)
  2. Database: Save number
  3. Phần mềm bên mình: Get number –> vẽ chart

Nhưng đời không như mơ, database của khách hàng đã như vậy rồi, ko thể thay đổi được nữa và khách dùng bản 13.1 thấy vẫn chạy ngon mà.

  • Nguyên nhân 2: Từ năm 2016 đến nay 2023, khách hàng mới chịu update phần mềm, bạn có thể mắng là lười update giờ bị chết còn đổ tại ai? Nhưng bình tĩnh xem xét lại thì 1 cty lớn, quy trình nhiều và sản xuất những mặt hàng quan trọng như ngành y dược, công nghiệp thì họ cần sự ổn định, phần mềm ở version cũ mà đáp ứng được nhu cầu là họ sẽ không nâng cấp, trừ khi bị yêu cầu bắt buộc phải nâng cấp để đáp ứng về security hay phần mềm version cũ bị ngừng support (nếu có bug thì cũng kệ).

Vậy tester có lỗi hay không?

Chẹp, khó nói ghê, nếu nói không có thì vô trách nhiệm quá, mà nói thì cũng không đúng hoàn toàn vì mình vào team năm 2020. Mình có test cái đoạn optimization kia đâu.

Ở thời điểm này, fix cái bug của 5 năm trước, thì mình nghĩ là ta nên quên việc lỗi của ai (đổ lỗi cá nhân), thay vào đó là ghi rõ nguyên nhân lỗi, cách fix và tìm cách hạn chế điều này xảy ra trong tương lai, cũng như tạo ra test case / test script để đảm bảo bug không xuất hiện lại.

Mình kể câu chuyện này để nếu có bạn tester nào đọc được bài này thì mong bạn luôn vui vẻ với công việc, ngừng việc cãi nhau với dev (nếu đang như vậy) và đừng chửi bới khách hàng hay những người đã tạo ra “di sản” như vậy. Là con người, ai chẳng có sai lầm, quan trọng là sau sai lầm chúng ta nên làm gì, sửa quy trình và thay đổi phương pháp test để hạn chế bug. Vậy thôi, chúc bạn 1 ngày tốt lành! ^^

5 1 vote
Article Rating
Subscribe
Notify of
guest
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Hana
Hana
1 year ago

Anh Giang cho em hỏi chút ngoài lề với ạ, cũng liên quan đến bug trên môi trường prod, PM có hỏi em câu này mà em không biết phải làm sao cho đúng:

(1) Khi có bug trên prod user báo về => sau khi đã fixed, tested xong và release bug này rồi, làm thế nào để em đảm bảo là bug đó không bị reopen trên prod nữa?
=> Em thấy khá khó để mình đảm bảo được bug không bị reopen lại nữa nhưng tester cần phải kết hợp với dev để tìm ra được root cause của bug. Dựa vào đó để mình nghĩ ra các test case để cover bug đó nhất có thể và các phần bị impact => nhờ đó sẽ tạo ra sự more confidence cho cái product mình làm

(2) Dự án em dạo này gặp bug non-reproduce (user report bug trên prod env nhưng mãi không tìm cách reproduce trên dev env được.) hay có những bug hiếm gặp (cả dev và tester đều biết là có bug này nhưng lúc thì thấy lúc thì không). Nên PM hỏi em làm đã làm những gì khi gặp trường hợp này.
=> Em biết là môi trường prod và dev là không thể giống nhau hoàn toàn nhưng khi gặp bug non-reproduce thì bọn em cũng request KH như sau:

  • Step by step
  • Device, browser, version of browser, version of device.
  • Logs
  • Tần suất xảy ra lỗi (đây là lỗi trên 1 page publish everyone có thể gặp nên em không request số users bị ảnh hưởng.

Nhưng thực sự sau khi làm theo các ý đã request thì vẫn không thể reproduce được => Giờ em không nghĩ ra được thêm gì nữa.

Nếu anh gặp những case như này thì anh sẽ làm làm như thế nào ạ. Thanks anh