Defect in software testing

Lời nói đầu

Đối với QA, Tester khi làm việc thì không thể chưa nghe tới "Defect", vậy trong tất cả các trường hợp nói là defect liệu có đúng? Trong bài viết này em sẽ nêu ra khi nào là defect và khi nào không phải là defect.

Trong tiếng anh thì bạn có thể hiểu các định nghĩa như sau:

Còn trong kiếm thử phầm mềm thì sao? Bạn có thể hiểu tương tự ý nghĩa của những định nghĩa đó, và nó được định nghĩa như sau:

Chúng ta sẽ đi sâu vào tìm hiểu chi tiết về defect.

1. Defect là gì

Khi phát hiện Defect hay bug thì việc Tester/ QA cần làm lúc này là report lại defect đó. Các thông tin cần có đó là:

• Defect ID: Mọi bug or defect có số ID duy nhất
• Defect Desscription: Tóm tắt vấn đề
• Product version: Bao gồm phiên bản sản phẩm, ứng dụng khi defect được tìm thấy
• Detail steps: Bao gồm các bược chi tiết của vấn đề, các file ảnh đính kèm để dev có thể hiểu lỗi đó
• Date raised: Ngày mà bug được tìm ra
• Reported by: Người mà tìm và report bug
• Status: Trạng thái của defect, ex: New, In progress, Resolved , Testing, ...
• Fixed by: Người sửa lỗi
• Date closed: Ngày lỗi được closed
• Severity: Mức độ ảnh hưởng của bug đói với phần mềm
• Priority: Độ ưu tiên sửa lỗi

2. Failure là gì

Nếu theo hoàn cảnh và môi trường, defect trong ứng dụng hay sản phẩm được thực thi dẫn đến lỗi hệ thống đó là failure - thất bại

Nhưng bạn cần chú ý:

Có những lý do để defect dẫn đến failure:

• Điều kiện môi trường, những lỗi có thể làm thay đổi việc thực thi phần mềm

• Do lỗi của con người trong quá trình tương tác phầm mềm: nhập giá trị đầu vào sai hoặc đầu ra bị hiểu sai.

  Ví dụ: Tester có thể không nhận thức được tính năng hoặc do môi trường xấu.

• Đôi khi là chính một người nào đó cố tình gây ra sự thất bại trong hệ thống

Một số lưu ý:

Cuối cùng Failure cũng được report lại và chuyển cho người phát triển. Khi nhận được report người phát triển cần phân tích sự cố này có phải là lý do dẫn đến lỗi hệ thống hay không.

3. Defects and failures bắt nguồn từ đâu?

Lỗi trong đặc tả kỹ thuật, thiết kế và khi "làm" phần mềm và hệ thống:

• Đặc tả kỹ thuật là tài liệu văn bản cơ bản trong đó mô tả các Func và Non-Func, có sử dụng cả văn xuôi và hình ảnh.
• Đối với đặc tả kỹ thuật không cần có code. Ngoại trừ code chúng ta có thể kiểm thử các thông số kỹ thuật
• Khoảng 55% của tất cả bug trong sản phẩm là do sai lầm trong đặc tả kỹ thuật
• Tuy kiểm tra đặc tả kỹ thuật mất thời gian và chi phí trong các giai đoạn của sản phẩm, nhưng đây thực sự là bước cần thiết với mỗi dự án.

Error khi sử dụng hệ thống

• Tester không có đủ kiến thức hiểu biết về hệ thống phần mềm. Tester có thể không biết các chức năng của sản phẩm dẫn đến trong khi kiểm thử sẽ có một vài defect hoặc failure
• Dev không hiểu các chức năng của sản phẩm hoặc ứng dụng đúng cách mà họ dựa trên sự hiểu biết của họ, dẫn đến chức năng mà họ phát triển không phù hợp với đặc tả kỹ thuật.

Điều kiện môi trường

• Lý do của việc cái đặt môi trường test lỗi cũng dẫn đến defect hoặc failure.
• Có khoảng 40% thời gian của tester bị tiêu tốn bởi các vấn đề về môi trường, điều này thực sự ảnh hưởng tới chất lượng và năng suất kiểm thử.

=> Cần kiểm tra môi trường, đảm bảo chất lượng trong khi chuyển giao với khách hàng

Thiệt hại cố ý

• Defect hay failure được report bởi tester trong khi kiểm thử phần mềm hay ứng dụng có thể là do thiệt hại cố ý.

Tầm quan trọng của việc phát hiện lỗi sớm

• Lỗi được tìm thấy trong giai đoạn đầu phát triển giúp giảm chi phí sản xuất nhiều. Do đó việc tìm ra lỗi sớm ở giai đoạn đầu rất quan trọng
• Thực hiện bằng cách xem xét các tài liệu kỹ thuật hay quá trình. Nếu defect không được tìm thấy trong giai đoạn này mà đợi đến khi phát triển xong mới tìm thấy thì sẽ làm tăng chi phí sản xuất

Chẳng hạn như:

• Người sử dụng phần mềm ứng dụng hay sản phẩm có thể không đủ kiến thức về sản phẩm
• Có thể do các sản phẩm được sử dụng 1 cách sai lầm dẫn đến defect hay failure
• Developer có thể có dòng mã không chính xác dẫn đến defect trong quá trình thiết kế
• Thiết lập không chính xác môi trường kiểm thử

5. Chí phí của defect

• Chi phí của defect có thể được đo bằng sự tác động của các defect khi tìm thấy defect. Defect được tìm thấy sớm thì chi phí sẽ ít hơn

• Trong cùng một cách defect hay error được tìm thấy trong thiết kế, thì bản thiết kế sẽ được sửa sau đó mới bắt đầu thực thi thì chi phí sẽ rất thấp, nhưng đợi đến khi sản phẩm được thực thi sau đó tester thực hiện kiểm thử tìm ra defect thì lúc đó chi phí sửa chữa là quá đắt.

  Hình ảnh minh họa chi phí sửa lỗi

Nếu lỗi được thực hiện và những khiếm khuyết quả được phát hiện trong giai đoạn yêu cầu sau đó nó là tương đối rẻ tiền để sửa chữa nó.

Tương tự, nếu một lỗi được thực hiện và những khiếm khuyết quả được tìm thấy trong các giai đoạn thiết kế sau đó thiết kế có thể được sửa chữa và tái phát hành với tương đối ít chi phí.

Lời kết

Trong bất cứ vòng đời phát triển dự án nào thì việc phát hiện defect sớm là rất cần thiết, việc này giúp giảm chi phí thời gian và tiền bạc của dự án. Để nâng cao được chất lượng của dự án thì cần chú ý tới tất cả các nơi, các giai đoạn để phát hiện defect. Từ yêu cầu, tài liệu, môi trường, con người,... Và đương nhiên ai cũng có thể phát hiện defect, nên dù bạn là Developer hay QA thì hãy chú ý đến defect nhé.

Tham khảo http://istqbexamcertification.com/what-is-defect-or-bugs-or-faults-in-software-testing/