Bug là gì? Nguyên nhân gây ra bug

Như chúng ta đã biết kiểm thử là một quá trình thực hiện, sử dụng các phương pháp nào đó để  tìm ra lỗi của phần mềm để chắc chắn rằng khi phần mềm đến tay người sử dụng nó không còn lỗi. Vậy thì bug hay còn được gọi là lỗi chính là kết quả của toàn bộ công việc kiểm thử nhận được, vậy bug là gì?? nguyên nhân nào gây ra và làm thế nào để Tester có thể tìm ra chúng, quản lý chúng và dọn sạch chúng…

Bug là gì?

Bug có các tên gọi khác như là Defect,  Fault là những lỗi phần mềm được tạo ra trong quá trình code. Lỗi này có thể do code sai, code không hiểu ý tưởng hoặc lỗi có thể đến từ đặc tả yêu cầu phần mềm (SRS), thiết kế… dẫn đến kết quả đưa ra khác so với yêu cầu của khách hàng. Vậy hãy cùng tìm hiểu các nguyên nhân gây ra bug là gì?

Nguyên nhân tạo ra bug

• Bug được tạo ra trực tiếp từ coder trong quá trình code, nó có thể phát sinh trong quá trình xử lý thông tin hoặc kỹ thuật gặp phải một số sai sót.
• Hiểu sai vấn đề cần code và thiết kế phần mềm.
• Trong quá trình trao đổi, tiếp nhận thông tin từ khách hàng. Developer chưa hoàn toàn hiểu, hiểu sai ý tưởng thiết kế phần mềm, vấn đề cần code dẫn đến tạo ra những đoạn code bị sai không đúng với yêu cầu của khách hàng.
• Ảnh hưởng bởi yếu tố thời gian.
• Deadline quá ngắn làm cho developer phải hoàn thành trong thời gian sớm nhất dẫn đến tình trạng làm nhanh, làm ẩu, overstrength, overtime, căng thẳng từ đó những con bug xuất hiện. 
• Thiết kế của phần mềm phức tạp, không logic hoặc không thiết thực để code hoặc vượt quá kỹ thuật code nên không thể thực hiện được. 
• Năng lực của developer còn yếu cách code còn sơ sài, chưa tối ưu,…
• Ví dụ một function đã được test ở bản build version 1 tuy nhiên trong nhiều lần buid đã xuất hiện lỗi hồi quy. Tuy nhiên developer không biết lỗi đó xuất hiện ở version nào nên khó xử lý.
• Quy trình kiểm thử chưa chặt chẽ, thiếu chuyên môn, chất lượng của sản phẩm không đảm bảo dẫn đến khi vận hành trên thị trường không tương thích.
• Developer sử dụng tool hỗ trợ của bên khác nhưng chính bản thân tool đó đã chứa lỗi dẫn  đến các vấn đề phát sinh .
• Thay đổi thiết kế ngay trước khi release thay đổi thiết kế dẫn đến phải thay đổi thay đổi code, tính năng, kiểm thử sẽ không có nhiều thời gian nên dễ dẫn đến sai lầm.

Vòng đời phát triển của bug

Mô tả khái quát về vòng đời của bug

• Trong quá trình kiểm thử, Tester phát hiện ra lỗi,  ghi lên hệ thống quản lý  và assign cho lập trình viên. 
• Developer fix lỗi sau đó chuyển lại cho tester kiểm tra lại. Nếu bug được xử lý OK thì tester báo closed, nếu phần mềm, ứng dụng vẫn lỗi thì trạng thái bug chuyển sang reopen để developer check lại và fix. 

Chi tiết các trạng thái Bug xuất hiện và tồn tại

• New: Trong quá trình thực hiện, người kiểm thử đưa ra kết quả của test case không đúng như mong muốn ban đầu thì đó được gọi là bug và trạng thái lúc này của bug là new.
• Assigned: Sau khi bug được log bởi người kiểm thử thì leader hoặc tester của team hoặc của dự án sẽ gán các bug đó cho developer để fix lại.
• Open: Sau khi lỗi được Log lên bởi tester, leader team phải có trách nhiệm xác minh lại đó có đúng là bug hay không, công việc của lead lúc này là:

           Sau đó developer tiến hành sửa nếu đó đúng là 1 bug. Lúc này bug được gọi là ở trạng thái open.

• Resolved/Fixed: Sau khi developer fix bug thì lập trình viên xác minh rằng lỗi đó đã được fix và chuyển sang trạng thái Resolved/Fixed và push cho tester kiểm tra lại.
• Deploy/Pending retest: Sau khi bug được sửa ở máy local của lập trình viên nó sẽ được gắn trạng thái Deploy/Pending retest, Lập trình viên sẽ đưa code lên môi trường test để chuẩn bị cho team tester thực hiện retest.
• Retest: Sau khi fix bug xong , các tính năng và chức năng đã sẵn sàng hoạt động. Tester sẽ tiến hành kiểm tra lại, thực hiện các test case lỗi để xem bug đó đã được sửa hay chưa.
• Reopen: Bug vẫn tồn tại sau khi developer fix thì lúc này tester sẽ chuyển trạng thái thành Reopen.
• Trường hợp bug đã fix đã close nhưng vẫn xuất hiện lại, lúc này sẽ được tester gắn cho trạng thái Reopen và đẩy lại cho developer.
• Closed: Sau khi lỗi được sửa, tester đưa ra kết luận bug đã được fix thành công và không còn trên ứng dụng, phần mềm lúc này được cấp trạng thái closed. Trạng thái này có nghĩa là bug đã được sửa chữa, chờ kiểm tra và phê duyệt.
• Duplicate: Sau khi log bug, test leader sẽ check lại xem bug đó có bị lặp lại hai hay nhiều lần hay không hoặc 2 bug cùng phản ánh một vấn đề như nhau thì lúc này sẽ ở trạng thái Duplicate ( trường hợp đó có thể là do cùng bug nhưng được log từ 2 tester khác nhau vì có thể cùng một module, một phần mềm được test nhiều hơn 1 tester)
• Rejected: Nếu developer nhận thấy rằng đó không phải là bug do có thể tester hiểu sai về chức năng thì sẽ chuyển trạng thái về Rejected.
• Not a bug: Nếu lỗi đó không có sự thay đổi về chức năng  của ứng dụng, phần mềm thì nó sẽ ở trạng thái không phải là lỗi. (Ví dụ: sau đó có yêu cầu đến từ khách hàng như thay đổi color cho văn bản thì đó không được coi là bug mà chỉ là sự thay đổi về bên ngoài, về diện mạo, giao diện của ứng dụng).

Như vậy trong quá trình log bug team test phải hiểu rõ được bug và nguyên nhân gây ra. Quan trọng hơn leader team phải nắm rõ được bug đó đang ở trạng thái, mức độ nguy hiểm ra sao để báo lại developer fix. Để làm được điều đó yêu cầu team test phải có kiến thức về khóa học Tester, chuyên môn và kỹ thuật cao để tìm ra hết các bug tiềm ẩn.