Một số chú ý để hạn chế bug phát sinh

Trong chúng ta ai cũng biết bug là thứ đi kèm với mỗi hệ thống. Với bất kì system nào được tao một cẩn thận như thế nào thì vẫn có khả năng miss, bug phát sinh.Điều quan trọng là những bug như thế này thì lần sau vẫn có khả năng phát sinh.Vậy liệu chúng ta có thể quản lý những bug này để hạn chế bug phát sinh được không. Bài viết hôm nay sẽ bàn về vấn đề này

1.Về cách report bug và một số loại bug

Nói về bug thì rất đa dạng về chủng loại, có những bug nhỏ như text hiển thị lộn xộn trên màn hình ... hay những bug to ảnh hưởng đến tiền bạc như fail trong khi thanh toán chẳng hạn ...Nếu nói rằng phải báo bug như thế nào thì tôi có một quy tắc nên viết tất cả những gì có thể liên quan đến bug!

2.Định luật Heinrich

Định luật đã chỉ ra quy tắc mang tính kinh nghiệm thống kê Đó là sau khi một vụ tai nạn lớn xảy ra thì sẽ có 29 vụ tai nạn nhỏ xảy ra và sau này sẽ có khoảng 300 vụ có nguy cơ tai nạn. Theo đó, nếu nói theo một cách ngược lại , dù là bug nhỏ như thế nào nữa nhưng nếu chúng ta thực sự quản lý chặt chẽ, nghiêm túc thì vẫn có thể phòng tránh những tai nạn (bug) to hơn sau này

3.Về format report bug

Về report bug nếu có thể nên quản lý bug bằng các hệ thống quản lý ticket/issue chẳng hạn.Nếu không có , hãy report theo kiểu như wiki cũng ok nhưng format report bug tối thiểu nên chuẩn bị những mục sau。

• summary nội dung bug
• Customer feedback
• timeline bug
• Phân chia xử lý
• Phương án hạn chế phát sinh bug

Summary nội dung bug

Nội dung report bug được trình bày bằng văn phong rõ ràng , thẳng thắn. Nội dung cố gắng trình bày chi tiết nhất có thể, không chỉ là hiện tượng xảy ra, mà có thể màn hình phát sinh bug hay nguyên nhân chẳng han. Nếu viết được thế này thì những member không phải là những người biết kỹ thuật, hoặc bộ phận support cũng có thể hiểu được nội dung bug Ví dụ : Thay vì : 「Phát sinh bug vật lý của DB HogeFuga_master DB」 => 「Hiển thị lỗi internal server error ở màn hình Hoge」 hay là 「Phát sinh bug không post Hoge được 」

Customer feedback

Trình bày nội dung hoặc số bản ghi thông tin liên quan đến bug phát sinh。Hoặc ghi nội dung người nhận, assign bug đó .Nội dung này sẽ giúp ích cho người sửa nếu trực quan hóa độ ảnh hưởng. Hơn nữa, khi phát sinh bug vì cần thiết phải tạo thành format cung cấp thông tin cho đội phát triển nên việc liên hệ để thông báo bug cũng trở nên dễ dàng hơn

Timeline bug

Time line bug là báo cáo liên quan đến tình trạng xử lý bug, thời điểm phát sinh, thời điểm sửa, thời điểm hoàn thành。Hơn nữa, sẽ tốt hơn nếu với mốc thời gian đó thêm nội dung ai làm , khi nào ,làm như thế nào Lý do cho việc phải mô tả những nội dung này vì nó thực sự có ích khi thảo luận về biện pháp phòng tránh bug phát sinh lại.Ví dụ :trong trường hợp từ thời điểm phát sinh bug đến thời điểm xác nhận là 2 tiếng , thì có thể dù chỉ trong vòng 10 phút độ ảnh hưởng của bug đã thay đổi.Hơn nữa, [thời điểm xác nhận -> thời điểm fix bug] và [thời điểm bắt đầu fix -> thời điểm hoàn thành] cũng như thế Về độ ảnh hưởng của bug có thể có thể tính theo công thức Độ ảnh hưởng = phạm vi ảnh hưởng *tính cần thiết(liên quan đến tài chính)* thời gian để fix bug

Biện pháp phòng tránh bug phát sinh

Ở thời điểm report có thể chưa có một biện pháp phòng tránh bug hoàn hảo nhưng cần phải đưa ra biện pháp trước khi close ticket .Hơn nữa,nếu không đưa nguyên nhân bug rõ ràng thì sẽ có trường hợp phương pháp phòng tránh bug bị sai. Do đó, khi trình bày phương pháp hạn chế bug xảy ra nên ghi rất rõ cặp tương ứng [nguyên nhân - giải pháp ] đi kèm Để đưa ra biện pháp , chúng ta cùng chỉ rõ một số nguyên nhân như sau

• Nguyên nhân mang tính trực tiếp làm phát sinh bug
• Nguyên nhân gián tiếp dẫn đến bug
• Lý bo bản chất : tại sao các bug lại phát sinh Theo như định luật Heinrich,với 1 bug thì có thể dẫn đến 300 nguy cơ bug tiềm ẩn hoặc là tùy theo thói quen, sự cố gắng của member mà có thể hạn chế bug phát sinh . Tuy nhiên , nếu chỉ đưa ra mỗi nguyên nhân trực tiếp thì có nhiều trường hợp giải pháp sẽ không giải quyết được . Theo đó, những bug này phát sinh lại đến từ nguyên nhân gián tiếp. Do đó giải pháp thực sự tốt là có thể đáp ứng được cả 3 nguyên nhân bên trên Sau khi tìm ra nguyên nhân, chúng ta sẽ đưa ra biện pháp nhằm làm hạn chế bug phát sinh, cũng như mức độ ảnh hưởng của nó thông qua hai vấn đề Phạm vi ảnh hưởng ：dù có bug tương tự xảy ra thì liệu có thể tối thiểu hóa mức độ , phạm vi ảnh hưởng của nó không Thời gian cho đến khi fix xong bug dù có bug tương tự xảy ra thì liệu có thể tự động fix hoặc giảm thời gian fix được không

4.Về chu kì thảo luận phòng tránh bug

Nhìn lại ,đánh giá team

Để đưa ra biện pháp hạn chế bug phát sinh thì định kì thường xuyên tổ chức đánh giá lại là việc khá quan trọng 。Đặc biệt với những member để phát sinh bug thì không nên ý kiến theo suy nghĩ chỉ trích lỗi của member đó . Các data, report cần được chuẩn bị để từ đó cùng thảo luận đưa ra biện pháp phù hợp . Để thu nhập được nhiều ý kiến của mọi người , điều quan trọng phải tạo ra không khí thoải mái tự do.Khi đó ,có thể nhìn nhận và đánh giá các biện pháp được đưa ra.Hơn nữa tiến trình của công việc vẫn phải focus theo hướng đi từ nguyên nhân ->tìm ra biện pháp tương ứng Ngoài ra, có một option khác là có thể đưa thêm đánh giá khác từ các member ngoài team.Từ đó , có thể mở rộng phạm vi giải quyết vấn đề hơn .

Solution tốt

Về một biện pháp tốt nếu nó được sắp xếp theo thứ tự sau

1. Về vấn đề loại này là biện pháp có thể ngăn chặn xảy ra bug lần thứ 2
2. Solution có thể phát hiện tự động vấn đề loại này khi phát triển
3. Solution có thể phục hồi tự động dù phát sinh vấn đề này
4. Solution có thể local hóa, hạn chế phạm vi ảnh hưởng khi vấn đề phát sinh

Solution chưa tốt

1. Thêm các solution với mục đích trốn tránh trách nhiệm
2. Chỉ ra không đầy đủ solution thêm các nội dung vào document
3. Solution yêu cầu cải thiện tính cách/ cố gắng /sự nhẫn nại của member
4. Solution yêu cầu chế độ double check /triple check gắn kèm nhiều lý do
5. Thêm các chỉ thị vào tài liệu Cần chú ý là đôi khi chúng ta vẫn lỡ làm theo các bước trên mặc dù nghĩ nó là không tốt

Source http://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda