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.
- Phần mềm X: Nhập liệu (điền number) –> convert sang text
- Database: Save text
- 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?
- Phần mềm X: Nhập liệu (điền number)
- Database: Save number
- 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 có 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! ^^
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:
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
Dưới đây là 1 số gợi ý của anh:
1. Lấy toàn bộ thông tin của lỗi như em đã liệt kê –> đọc tìm điểm bất thường. Và hãy cố gắng làm lại giống hệt như step mà khách hàng đã làm. Nếu có thể thì xin remote vào máy của khách để xem tận mắt hoặc xin video.
2. Môi trường prod và dev ko thể giống nhau thì chỉ nên khác về data thôi, chứ code thì nên cùng version (cùng build từ 1 commit)
3. Xác định bug thuộc phần nào sau đó tìm cách test từng phần để thu hẹp phạm vi của bug.
4. Mặc dù lỗi ở page public nhưng ko phải ai cũng gặp, chính bọn em cũng ko gặp thì có thể lỗi đó không phổ biến, có thể liên quan đến client, ví dụ như xóa cache, xóa cookie.
5. Nếu bug đó bị reopen thì thường là chưa tìm được đúng root cause, hoặc bug đó ko chỉ do 1 nguyên nhân, hoặc chính việc fix gây ra bug mới. Bọn anh gặp lỗi có biểu hiện giống nhau nhưng root cause khác nhau khá nhiều.
6. Ko phải cứ có bug thì “chết rồi” hay “tận thế”, nó chỉ là 1 phần ko thể thiếu của phần mềm thôi. Bug ko đáng sợ, bug đó có severity hay priority cao mới là đáng sợ.