Software Defects

Mục tiêu chính của developers là viết code để tạo ra một phần mềm trong khi các testers lại có mục tiêu chính là để tìm defects hoặc bugs trong phần mềm của developer. Bây giờ chúng ta cùng xem xét thế nào là defects và thế nào là bugs.

Defect hoặc bug của phần mềm: Các chức năng phần mềm mà không phù hợp với các tài liệu đặc tả yêu cầu được gọi là defect hoặc bug.

1. Coding defects: Các yêu cầu đã được code không chính xác do đó một số thành phần hay hoạt động của một chức năng nào đó thực hiện không phù hợp với các tài liệu đặc tả yêu cầu. Các khiếm khuyết này thường xuyên xảy ra khác được thực hiện bởi các developers là do

• bỏ sót code thực hiện các yêu cầu được liệt kê trong tài liệu đặc tả yêu cầu.
• Code các yêu cầu không được quy định trong tài liệu đặc tả yêu cầu. Những khiếm khuyết này thường bị tạo ra bởi sự vô ý của developers.

Ví dụ: Yêu cầu theo tài liệu đặc tả: Nếu người dùng nhấp vào liên kết 'Home' trong một trang web thì trang "Home" nên được hiển thị cho người dùng. Tester quan sát trong khi test là "Home" link: Tester nhận thấy rằng Trang 'About me' hiển thị mỗi lầ nhấp vào 'Home' link, đó là một sự sai lệch trong các luồng dữ liệu so với tài liệu đặc tả yêu cầu. Đó chính là một ví vụ về coding defect.

2. 'Bỏ sót yêu cầu đặc tả' defects Một yêu cầu hợp lệ là cái mà bắt buộc và phải code (hoặc thực hiện) mà bị bỏ sót. Nguyên nhân gốc rễ của lỗi này là do không nắm bắt được yêu cầu này trong các tài liệu đặc tả. Những gì quan sát được là "các yêu cầu bị bỏ sót 'vì các yêu cầu bị bỏ qua từ tài liệu đặc tả yêu cầu. Những loại defects thường được gây ra bởi quá trình phân tích và giám sát.

Ví dụ: Tester quan sát trong khi test các Website: Tester thấy 'Disclaimer' link bị thiếu trong các trang web. Theo quy định / hướng dẫn quản trị trang web nó là bắt buộc để hiển thị "Disclaimer" link trong website vì vậy testers đưa ra kết luận rằng "Disclaimer" link bị thiếu và developers sẽ fix lỗi này.

3. "Tài liệu đặc tả yêu cầu mới" defects: Một yêu cầu mà không có trong phạm vi dự án để code (hoặc thực hiện) nhưng sau đó nó đã được xác định bắt buộc phải code (hoặc thực hiện) để giải quyết những rủi ro có thể xuất hiện trong quá trình phát triển (hoặc sau khi thực hiện). Những loại defects này thường được gây ra bởi người phân tích yêu cầu chưa có nhiều kinh nghiệm trong việc đánh giá phạm vi thành công hay thất bại của dự án.

ví dụ: Yêu cầu theo tài liệu kỹ thuật: Hệ thống A truyền dữ liệu với hệ thống B để hệ thống B xử lý dữ liệu. Hệ thống B: Chịu trách nhiệm

• Lọc Hồ sơ học sinh bao gồm những người đã đạt được hơn 80% quyết định thông qua tại các kỳ thi
• Chuyển thông tin quy trình lọc hồ sơ học sinh này đến bộ phận học bổng. Tester quan sát trong khi tiến hành system integration testing: Tester tìm thấy những dữ liệu không được chuyển vào hệ thống B và tiếp tục điều tra nó thì phát hiện thấy rằng nguyên nhân gốc rễ là bộ nhớ hạn chế hệ thống tức là B không tải bất cứ dữ liệu nào mặc dù hệ thống A truyền hơn 100.000 dữ liệu hồ sơ học sinh. Để giải quyết lỗi này các bên liên quan dự án quyết định tạo bổ sung (hoặc mới) yêu cầu. Vì vậy, yêu cầu bổ sung (hoặc mới) được tạo ra như dưới đây trong tài liệu đặc tả. Hệ thống A: Truyền hồ sơ học sinh (hồ sơ có chứa thông tin của mỗi học sinh) đến hệ thống C Hệ thống C: Hệ thống này được tối ưu hóa quá trình truyền tải (hoặc xử lý) khối lượng lớn dữ liệu tức là trong hệ thống này đã lọc hồ sơ học sinh những hồ sơ của những người đã đạt được hơn 80% quyết định thông qua tại các kỳ thi và gửi đến hệ thống B để xử lý tiếp. Hệ thống B: Chuyển thông tin quy trình lọc hồ sơ học sinh này đến bộ phận học bổng.