Tổng quan về đảm bảo chất lượng phần mềm

1. Chất lượng phần mềm và đảm bảo chất lượng phần mềm

   1.1. Định nghĩa chất lượng phần mềm

   Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức, cá nhân khác nhau. Trong phạm vi của bài viết này trình bày một số định nghĩa tiêu biểu.

   *Định nghĩa theo IEEE(1991):

   • Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả.

   • Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mong đợi của khách hàng hay người sử dụng.

   *Phân tích hai quan điểm của IEEE:

   • Theo quan điểm thứ nhất của IEEE: chúng ta sẽ bị phụ thuộc quá nhiều vào tài liệu đặc tả của yêu cầu, dẫn đến nếu việc xấc định yêu cầu bị sai, thiếu thì một phần mềm được làm đúng với đặc tả chưa chắc đã là một phần mềm có chất lượng.

   • Theo quan điểm thứ hai của IEEE: khách hàng đôi khi không có kiến thức về công nghệ, họ có thể đưa ra những mong muốn hết sức vô lý và có thể thay đổi yêu cầu với phần mềm nhiều lần, thậm chí thay đổi ngay trong giai đoạn cuối. Điều này gây nhiều khó khăn cho việc phát triển phần mềm.

   *Định nghĩa theo Pressman: Chất lượng phần mềm là sự phù hợp của các yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm được ghi lại rõ ràng bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềm được phát triển chuyên nghiệp.

   Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải được đáp ứng khi phát triển phần mềm:

   • Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra của phần mềm.

   • Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.

   • Các đặc tính ngầm định cần được đáp ứng trong quá trình phát triển cho dù không được nói đến rõ ràng trong hợp đồng.

   1.2. Định nghĩa đảm bảo chất lượng phần mềm

   Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software Quality Assure) là một tập hợp các hành động cần thiết được lên kế hoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách.

2. Lỗi phần mềm

   2.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm

   • Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhưng có thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó".
   • Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:
     • Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.
     • Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhưng lại không có trong sản phẩm thực tế.
     • Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả.

   2.2. Các nguyên nhân gây lỗi phần mềm

   Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả các nguyên nhân chủ quan và các nguyên nhân khách quan. Dưới đây là chín nguyên nhân chủ yếu gây ra lỗi phần mềm:

   *Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu thường nằm ở phía khách hàng. Một số lỗi thường gặp là: định nghĩa sai yêu cầu, lỗi không hoàn chỉnh, thiếu các yêu cầu quan trọng hoặc là quá chú trọng các yêu cầu không thật sự cần thiết.

   *Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Hiểu lầm trong giao tiếp giữa khách hàng và nhà phát triển cũng là nguyên nhân gây lỗi. Những lỗi này thường xuất hiện trong giai đoạn đầu của dự án. Một số lỗi hay gặp phải: hiểu sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trình bày bằng lời nói và tài liệu, hiểu sai về phản hồi và thiếu quan tâm đến những đề cập của khách hàng.

   • Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và nhà cung cấp để tránh lỗi trong giao tiếp. Ủy ban do quản trị dự án đứng đầu và khách hàng phải giới thiệu những người hiểu về mặt nghiệp vụ vào ủy ban đó.

   *Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợp các nhà phát triển cố tình làm sai lệnh các yêu cầu trong tài liệu đặc tả. Nguyên nhân của việc này đến từ các áp lực thời gian, ngân sách, hay cố tình sử dụng lại các mô-đun từ các dự án trước mà chưa phân tích đầy đủ những thay đổi để thích nghi với các yêu cầu mới.

   • Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải pháp như thế nào, sắp xếp ưu tiên xem bỏ được yêu cầu nào hay sử dụng lại được mô-đun nào.

   *Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia thiết kế hệ thống, các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhà phân tích xây dựng phần mềm theo yêu cầu. Các lỗi điển hình bao gồm:

   • Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai.

   • Quy trình định nghĩa có chứa trình tự lỗi.

   • Sai sót trong các định nghĩa biên như > 3 hay ≥ 3.

   • Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.

   *Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên gây ra các lỗi lập trình. Những lý do này bao gồm: sự hiểu sai các tài liệu thiết kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sót trong việc áp dụng các công cụ phát triển; sai sót trong lựa chọn dữ liệu...

   *Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình: Các lỗi phần mềm có thể đến từ việc không tuân thủ các tài liệu và tiêu chuẩn lập trình của các tổ chức phát triển phần mềm.

   *Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ chính quá trình kiểm thử khi mà người kiểm thử để lọt lỗi.

   Những lỗi này đến từ các nguyên nhân sau đây:

   • Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.
   • Lỗi trong tài liệu và báo cáo kiểm thử.
   • Việc sửa chữa các lỗi được phát hiện không hoàn chỉnh do áp lực thời gian hay do thiếu cẩn thận.

   Giải pháp: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu của dự án.

   *Các lỗi thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước của tiến trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phức tạp mà các tiến trình được thực bằng nhiều bước, mỗi bước có thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có thể đến từ việc viết các thủ tục.

   *Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo trì khi có những sai sót trong các tài liệu liên quan. Những lỗi này có thể là nguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì.

   2.3. Chi phí cho việc sửa lỗi phần mềm

   Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của vòng đời phần mềm. Tuy nhiên công việc này nên được thực hiện càng sớm càng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìm và sửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phí cho sửa lỗi sẽ trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức phát triển phần mềm.

   Theo tài liệu của Boehm, chi phí cho việc tìm và sửa lỗi phần mềm sẽ tăng theo hàm mũ trong biểu đồ sau:

   _Sơ đồ 1: Chi phí cho việc sửa lỗi phần mềm _

3. Quy trình xử lý lỗi phần mềm

   Trước khi giới thiệu về qui trình xử lý lỗi phần mềm, sau đây sẽ trình bày về các trạng thái có thể có của lỗi.

Sơ đồ 2: Các trạng thái của lỗi

Trong đó: * New: Lỗi mới * Assigned: Lỗi đã được gán cho nhân viên phát triển * Resolved: Lỗi đã được xử lý * Confirmed: Lỗi cần được chứng thực, thảo luận lại * Canceled: Lỗi được xác định là không phải lỗi, lỗi được bỏ qua * Next: Lỗi không thuộc phạm vi của dự án, hoặc sẽ được xử lý trong một giai đoạn khác của dự án * Accept: Các lỗi có thể chấp nhận được. Ví dụ: Các lỗi do Framework * Closed: Trạng thái đóng. Lỗi đã được sửa thành công.

Mỗi tổ chức phát triển phần mềm sẽ sử dụng một công cụ quản lý lỗi riêng, trong đó có thể kể đến Mantis là một công cụ được sử dụng khá phổ biến hiện nay. Phần tiếp theo sẽ trình bày một qui trình xử lý lỗi phần mềm hiện đang được sử dụng trong thực tế ở một số tổ chức phát triển và gia công phần mềm:

Sơ đồ 3: Qui trình xử lý lỗi

Theo đó, qui trình xử lý lỗi có thể bao gồm 6 bước chính:

• Bước 0_Bắt đầu: Phát hiện phần mềm có lỗi
• Bước 1_Đưa lỗi lên hệ thống quản lý lỗi
• Bước 2_Gán lỗi cho nhân viên phát triển
• Bước 3_Xử lý lỗi
• Bước 4_Kiểm thử lại
• Bước 5_Đóng lỗi

3.1. Bước 1: Đưa lỗi lên phần mềm quản lý lỗi

• Người thực hiện: tất cả các thành viên trong đội dự án như quản trị dự án, nhóm kiểm thử, nhóm giải pháp, nhóm lập trình.
• Trạng thái của lỗi là NEW.

*** Một số thông tin cần có về lỗi: **

• Category: Thư mục lỗi dùng để phân loại lỗi, lỗi thuộc phần chức năng nào phải chọn đúng phần thư mục lỗi tương ứng để thuận tiện cho việc tra cứu, thống kê lỗi của chức năng.
• Severity (trọng số của lỗi): Thông số này biểu hiện độ nghiêm trọng của lỗi, thông thường lỗi sẽ thuộc một trong ba trọng số dưới đây:
• Minor: Các lỗi định dạng (font chữ, cỡ chữ, màu sắc của các đối tượng, chiều dài của các đối tượng), lỗi chính tả, lỗi validate dữ liệu.
• Major: Các lỗi ràng buộc dữ liệu, lỗi chức năng nghiệp vụ của hệ thống (nhưng chưa gây ra treo hệ thống hay không làm cho hệ thống không xử lý được tiếp).
• Crash: Các lỗi chức năng nghiệp vụ của hệ thống gây treo hệ thống, không xử lý được tiếp.
• Reproducibility: Khả năng tái tạo lỗi. Khi phát hiện ra lỗi, nhân viên kiểm thử cần thực hiện lại phần chức năng phát hiện ra lỗi để xét khả năng tái tạo lỗi và lựa chọn đúng khả năng tái tạo lỗi.
• Priority: Mức độ ưu tiên trong việc sửa lỗi.
• Summary: Tóm tắt nội dung lỗi, có thể coi là tiêu đề của lỗi.
• Description: Đây là phần mô tả lỗi, phải mô tả rõ 3 phần nội dung:
• Các bước thực hiện.
• Kết quả trả về từ hệ thống o Kết quả mong muốn
• Notes: Dùng để đưa các lưu ý, trao đổi về lỗi của các thành viên trong dự án.

3.2. Bước 2: Gán lỗi cho nhân viên phát triển

• Nhân viên kiểm thử thực hiện gán lỗi cho nhân viên phát triển, người sẽ chịu trách nhiệm về phần chức năng bị lỗi.

• Trạng thái của lỗi là ASSIGNED.

• Lưu ý: Trưởng nhóm kiểm thử, quản trị dự án có thể xem xét lại các lỗi có trạng thái NEW và ASSIGNED trên hệ thống phần mềm quản lý lỗi: o Nếu thấy không phải là lỗi thì đưa lỗi về trạng thái CANCELLED và nêu rõ nguyên nhân đưa lỗi về CANCELLED.

• Nếu thấy nhân viên kiểm thử mô tả không rõ ràng, thiếu thông tin thì chuyển lỗi sang trạng thái CONFIRMED và yêu cầu nhân viên kiểm thử bổ sung thêm thông tin.

• Nếu thấy lỗi không thuộc phạm vi phát triển của dự án trong giai đoạn hiện tại thì chuyển lỗi về trạng thái NEXT.

  Quản trị dự án xem xét lại các lỗi có trạng thái NEW hoặc ASSIGNED, nếu thấy là lỗi nhưng có thể chấp nhận được thì chuyển lỗi sang trạng thái ACCEPTED và nêu rõ nguyên nhân đưa lỗi về trạng thái ACCEPTED.

3.3. Bước 3: Xử lý lỗi

Nhân viên phát triển xem xét các lỗi được gán cho mình:

• Nếu thấy đúng là lỗi và đã mô tả lỗi rõ ràng, đầy đủ thông tin, nhân viên phát triển thực hiện sửa lỗi và chuyển lỗi về trạng thái RESOLVED, đồng thời bắt buộc nêu rõ hướng giải quyết và các chức năng bị ảnh hưởng trong phần NOTES.
• Các trường hợp khác: Nếu thấy không phải là lỗi của hệ thống, nhân viên phát triển sẽ yêu cầu nhân viên kiểm thử bổ sung thêm thông tin, hoặc thấy là lỗi nhưng có thể chấp nhận được lỗi thì nhân viên phát triển chuyển lỗi sang trạng thái CONFIRMED và nêu rõ lý do chuyển lỗi sang trạng thái CONFIRMED trong phần NOTES.

3.4. Bước 4: Kiểm thử lại

Theo phân công của trưởng nhóm kiểm thử, nhân viên kiểm thử thực hiện kiểm thử lại các chức năng có lỗi đang ở trạng thái RESOLVED:

• Nếu lỗi đã được sửa thì chuyển lỗi về trạng thái CLOSED.
• Nếu lỗi chưa được sửa hoặc mới chỉ sửa một phần thì chuyển lỗi về trạng thái ASSIGNED và nêu rõ những phần chức năng nào chưa chỉnh sửa để nhân viên phát triển tiến hành sửa tiếp.
• Nếu thấy có thể chấp nhận lỗi thì chuyển lỗi về trạng thái ACCEPTED. Đồng thời khi cập nhật kịch bản kiểm thử thì sẽ để kết quả của case đó là fail (vì vẫn là lỗi).
• Lưu ý: Nếu phần chức năng bị ảnh hưởng gây ra lỗi mới thì đưa một lỗi mới lên phần mềm quản lý lỗi.

*Tổng kết

Bài viết đã trình bày được những định nghĩa và những vấn đề cơ bản xung quanh phần mềm, công nghệ phần mềm, lỗi phần mềm và xử lý lỗi phần mềm.

Các vấn đề cụ thể bao gồm:

• Các định nghĩa về phần mềm, công nghệ phần mềm, chất lượng phần mềm, bảo đảm chất lượng phần mềm, lỗi phần mềm.
• Các vấn đề liên quan đến lỗi phần mềm và qui trình xử lý lỗi phần mềm.