Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp được đề xuất

Aya Elgebeely đề cập đến tầm quan trọng của bốn phương pháp đảm bảo chất lượng quan trọng trong phát triển phần mềm.

Aya R. Elgebeely, Nhà phát triển ứng dụng, IBM

Aya Elgebeely hoạt động trong lĩnh vực phát triển ứng dụng tại Trung tâm Thẩm quyền và Toàn cầu hóa Ả Rập (ACGC - Arabic Competence and Globalization Center) thuộc Trung tâm Phát triển Công nghệ của IBM, Ai Cập. Công việc chính của ACGC là hỗ trợ ngôn ngữ hai chiều và toàn cầu hóa để đảm bảo khả năng dịch thuật chính xác và nhận thức văn hóa cho các sản phẩm và dịch vụ IBM khác nhau. Trước đây, cô là một kỹ sư phần mềm trong các nhóm Agile trong hai năm tại tập đoàn Symbyo Technologies. Trong hai năm này, cô đảm nhiệm nhiều vai trò khác nhau, bao gồm cả việc phát triển và thử nghiệm theo quy trình Agile, quá trình phát triển và giám sát, làm việc với các khách hàng khác nhau, phân tích yêu cầu và lập kế hoạch dự án.



07 11 2013

Giới thiệu

Ngành kỹ sư và phát triển phần mềm được xem là ngành nghề khá mới mẻ, tuy nhiên, nó có mặt ở khắp nơi và phát triển nhanh hơn bao giờ hết. Công nghiệp phần mềm nói chung bây giờ được xem là một trong những trụ cột chính của tăng trưởng kinh tế ở nhiều nước. Các công ty phần mềm thường xuyên phải đối mặt với nhiều thách thức khó khăn để cung cấp phần mềm chất lượng cao, và họ cố gắng để đạt được sự hài lòng của khách hàng.

Chất lượng phần mềm là một điều cần thiết

Nhu cầu phần mềm tăng lên đáng kể và nó đã trở thành một phần không thể thiếu trong cuộc sống hàng ngày của mọi người. Vì vậy, hiện nay phần mềm chất lượng cao được xem như là một nhu cầu "phải có" hơn là "nên có". Để có phần mềm chất lượng cao thì cần phải có đội ngũ có trình độ cao giám sát từ lúc bắt đầu và xuyên suốt quá trình dự án. Tuy nhiên hiện nay, các công ty xem chất lượng phần mềm như chỉ đơn thuần là một việc thực hiện bởi người kiểm thử tại thời điểm kết thúc của chu trình phát triển phần mềm.

Ngày nay, thị trường phần mềm đã có nhiều sự lựa chọn thay thế, đó là các giải pháp miễn phí, cũng như sự ra đời của phần mềm mã nguồn mở. Bên cạnh đó, khách hàng và người sử dụng càng chú trọng hơn về chất lượng của phần mềm mà họ mua. Các ứng dụng hay các hệ thống doanh nghiệp cho thấy những sản phẩm hiệu suất kém hoặc không đáp ứng được yêu cầu người dùng sẽ bị loại bỏ, và các sản phẩm khác sẽ diễn ra một cách dễ dàng hơn. Hiện nay nhiệm vụ trọng tâm của các công ty phần mềm là quan tâm đến chất lượng sản phẩm của họ hơn bao giờ hết.

Xem xét chất lượng phần mềm từ đầu đến cuối

Nếu phát sinh một vấn đề đối với việc Đảm bảo chất lượng phần mềm vào giai đoạn kiểm thử, khi mà tất cả các nhiệm vụ của nhóm phát triển đã hoàn tất, thì chi phí để nhóm khắc phục vấn đề là rất cao, đặt toàn bộ dự án vào nguy cơ rủi ro cao. Trong giai đoạn kiểm thử, các nhà phát triển làm hết sức mình để đảm bảo rằng mã của họ có ít sai sót. Sau đó, người kiểm thử làm việc chăm chỉ để phát hiện các lỗi có thể xảy ra trong phần mềm, trong khi các nhà quản lý và khách hàng hy vọng rằng phần mềm của họ đã sẵn sàng để phát hành ra thị trường.

Câu hỏi đặt ra là: Tại sao nhiều công ty phần mềm tập trung để thúc đẩy các nhóm phát triển đáp ứng thời hạn nghiêm ngặt và kết thúc với nhiều tính năng nhất có thể mà không quan tâm đến việc mã ứng dụng nghèo nàn như thế nào, bỏ qua số lượng lớn các sai sót bên trong các mã, gây ra các sai lầm trong kiến trúc, và bỏ qua các tài liệu?

Việc phát triển vội vã có thể tiết kiệm thời gian của nhóm nghiên cứu tại một thời điểm, nhưng cuối cùng nó khiến họ mất thêm thời gian để làm điều đó nếu có vấn đề phát triển mà không xem xét ngay từ đầu. Nó gây hậu quả lãng phí rất nhiều nguồn lực của nhóm để sửa chữa và tái cấu trúc mã của họ thay vì đầu tư nguồn lực vào việc hữu ích hơn. Nhóm phần mềm biết rõ điều đó, nhưng với những khách hàng khó tính và đội ngũ bán hàng khắt khe kèm theo cái tôi của một số nhà phát triển mà họ viết phần mềm không có bất kỳ sai sót nào, đội Đảm bảo chất lượng (QA) sẽ giúp kiểm tra lại mã nguồn khi hoàn thành.

Các tiêu chuẩn kỹ thuật phần mềm và ứng dụng của chúng

Điều đáng nói là các công ty không nhất thiết phải theo một trong các tiêu chuẩn phát triển phần mềm cũng như không có một quy trình nghiêm ngặt tại chỗ. Có những tiêu chuẩn điển hình khác nhau cho vòng đời phát triển phần mềm (SLDC), chẳng hạn như IEEE, ISO - 12207, hoặc CMMI. Mục đích của những tiêu chuẩn này là để đảm bảo rằng sản phẩm cuối cùng phù hợp với yêu cầu thị trường và đạt được sự hài lòng của người dùng cuối.

Trong thực tế, nhiều ứng dụng phần mềm, ứng dụng di động, và thậm chí là cả hệ thống doanh nghiệp được bán cho các khách hàng khác nhau mỗi ngày mà có thể không được phát triển dựa trên bất kỳ tiêu chuẩn nào. Tuy vậy, người ta vẫn mua chúng. Việc bỏ qua các tiêu chuẩn không có nghĩa là chất lượng phần mềm kém và nhu cầu sử dụng ít hơn đối với các sản phẩm đầu cuối (miễn là nó không phải là phần mềm quan trọng trong cuộc sống, chẳng hạn như phần mềm y tế đòi hỏi phải có sự chấp thuận của tổ chức FDA bên trong nước Mỹ và phải phù hợp với một trong các tiêu chuẩn). Vấn đề không phải là việc theo một tiêu chuẩn nào, mà điều thực sự quan trọng là bỏ qua hay làm giảm bớt tầm quan trọng của chất lượng phần mềm.

Điểm nhấn của bài viết này không phải là về các tiêu chuẩn SDLC cũng như không có một quy trình phát triển và kiểm thử tuyệt vời nào. Điều quan trọng đầu tiên cần nhận ra rằng chất lượng là một phần quan trọng của bất kỳ phần mềm. Công ty không nhất thiết cần phải có một đội ngũ và phương pháp bảo đảm chất lượng chuyên môn cao, nhưng ít nhất nó phải đáp ứng được các yêu cầu và thực tiễn liên quan.


Các bước đảm bảo chất lượng phần mềm trong chu kỳ phát triển

Phần này trình bày các bước ảnh hưởng tích cực đến chất lượng phần mềm mà không tạo ra quá nhiều công việc hay căng thẳng cho đội nhóm phát triển. Chúng đáng được xem xét trong quá trình phát triển và kiểm thử.

Xem xét các yêu cầu

Bạn có đồng ý với tôi rằng thật lãng phí nguồn tài nguyên khi cung cấp ra những sản phẩm sai tính năng không? Việc xem xét lại các yêu cầu trước khi bắt đầu mỗi giai đoạn phát triển sẽ giảm thiểu được rủi ro và đáp ứng đúng những gì mà khách hàng cần. Nó cũng giúp cho việc xem xét các thay đổi tiềm năng và khắc phục những sai lầm có thể xảy ra trong suốt quá trình hoạt động của dự án. Đội nhóm phải kiểm tra lại kỹ lưỡng với khách hàng tất cả những chi tiết về lĩnh vực kinh doanh nên được triển khai. Việc xem xét lại những yêu cầu cũng có thể được thực hiện bằng cách sử dụng nguyên mẫu và các mô hình miền (domain models). Khi nhóm phát triển tiến hành làm việc này trước khi bắt đầu triển khai thực tế, họ sẽ có được một khởi đầu dự án tuyệt vời. Bằng cách đảm bảo chắc chắn rằng các bên liên quan đạt được sự đồng thuận và mỗi bên đều có cùng nhận định như nhau trước khi bắt tay vào thực hiện, khách hàng và quản lý có thể đảm bảo rằng các nhà phát triển sẽ cho ra đời sản phẩm đúng với yêu cầu vào cuối chu kỳ phát triển.

Xem xét và kiểm duyệt lại mã nguồn

Cũng đơn giản như tên gọi của nó, xem xét lại mã nguồn (code review) là một trong những cách thực hiện hiệu quả nhất trong phát triển phần mềm. Nó có tác động trực tiếp đến việc làm giảm thiểu số lỗi (bắt lỗi ở ngoài trước khi đi vào bên trong), nâng cao chất lượng mã nguồn và thiết kế phần mềm. Điều này giúp giảm việc phải tái cấu trúc lại mã nguồn chính và giúp rõ ràng để phát triển các ấn bản sau này.

Nhóm có thể tán thành mã nguồn đơn giản và thiết kế các bảng hướng dẫn theo những yêu cầu dự án và những chi tiết thực hiện. Những bảng hướng dẫn này nên được chia sẻ giữa các thành viên trong nhóm, và bất cứ khi nào có một tính năng mới được phát triển, một hoặc nhiều thành viên trong nhóm (trừ tác giả) nên duyệt lại mã nguồn mới và tìm kiếm bất kỳ lỗi mã hoặc lỗi thiết kế nào.

Việc này giúp cho nhóm bằng nhiều cách, bao gồm nâng cao chất lượng mã nguồn và thiết kế, làm giảm những rủi ro, và ngăn ngừa sự xuất hiện của chúng. Ngoài ra, nó cho phép các nhóm đạt được cái nhìn sâu sắc về công việc của nhau, giảm bớt bàn giao, và tăng cường nhận thức nhóm về các thành phần phần mềm khác nhau và chức năng. Nhóm hợp tác để xác minh và xác nhận chất lượng của mã nguồn và cách thiết kế được thực hiện. Họ nhận được những phản hồi trực tiếp từ đồng nghiệp. Có một lợi ích đôi ở đây: chất lượng mã nguồn tăng lên, nhận thức của mã, và quyền sở hữu dự án cũng tăng lên.

Kiểm thử dựa trên phiên làm việc (session)

Kiểm thử dựa trên phiên làm việc là một phương pháp được phát triển bởi by James Bach, nghĩa là chia nhỏ việc kiểm thử thành các phiên làm việc, trong đó mỗi phiên có một nhiệm vụ (một kết quả được mô tả từ phiên kiểm thử). Mỗi phiên định nghĩa một khung thời gian (từ 20 đến 40 phút), và người kiểm thử nên làm việc liên tục trong lúc phiên kiểm thử được tiến hành.

Nó giống như việc đặt người kiểm thử vào một bong bóng kiểm thử (bó kiểm thử) trong một thời gian và cho phép họ tập trung tìm các lỗi của những tính năng hoặc chức năng đặc biệt của phần mềm. Trong suốt phiên làm việc, việc kiểm thử được theo sát bởi một tập test case, và đây cũng là tư liệu cho những người kiểm thử khác có thể theo dõi. Vì vậy, kiểm thử dựa trên phiên làm việc là tổng hợp của phương pháp và sự sáng tạo trong kiểm thử, bởi vì nó mang lại cho các phòng kiểm thử sự khảo sát tỉ mỉ và sự hiểu biết mà có thể cho phép thời gian hoặc mất thời gian để tìm những lỗi bất thường hoặc những xáo trộn xung quanh phần mềm phát sinh từ phương pháp kiểm thử đó.

Trong suốt phiên làm việc, người kiểm thử nên tư liệu lại các hành vi của phần mềm, chụp lại những bức ảnh, và ghi lại hành vi của phần mềm dưới sự đặc tả và thiết lập đầu vào. Sau khi phiên làm việc kết thúc, bảng sao chép phiên làm việc được thảo luận với trưởng nhóm hoặc quản lý kỹ thuật. Từ buổi thảo luận, họ có thể tìm ra những gì được coi là những hành vi bình thường hoặc không bình thường, và sau đó các báo cáo về lỗi được tạo ra, dựa trên thảo luận này.

Hình 1 mô tả quy trình kiểm thử dựa trên phiên làm việc trong một thời gian ngắn. Đối với bất kỳ sự thay đổi mới nào trong phần mềm, các phiên kiểm thử khác nhau được lên kế hoạch, mỗi một phiên đặc tả một mục tiêu và một nhiệm vụ. Trong suốt phiên kiểm thử, người kiểm thử dùng các test case hoặc làm thăm dò kiểm thử hoặc cả hai. Khi phiên kiểm thử kết thúc, các lỗi được tìm thấy trong suốt phiên làm việc được báo cáo lại.

Hình 1. Quy trình kiểm thử dựa trên phiên làm việc
Sơ đồ, kiểm thử mỗi tác vụ để tìm ra sai sót

Kiểm thử dựa trên rủi ro

Các nhóm phát triển thường xuyên tái bản cho cùng một phần mềm, bởi vì có nhiều sự thay đổi — lớn hoặc nhỏ — xảy ra trong quá trình phát triển. Một điều quan trọng của việc Đảm bảo chất lượng phần mềm là phải kiểm thử kỹ lưỡng phần mềm sau mỗi lần tái bản chính. Mặt khác, nó tốn thời gian và khó để chạy một bộ kiểm thử hồi quy cho toàn bộ phần mềm trong mỗi lần tái bản. Tuy nhiên, nó không an toàn để kiểm thử cho các tính năng đã thay đổi hoặc giảm bớt các bộ test case khó xử. Một đoạn mã có thể giải quyết một lỗi nhưng nhiều lúc lại phá vỡ các mã khác trong chương trình.

Các tiêu chuẩn của mô hình kiểm thử dựa trên rủi ro đứng ở giữa. Ý tưởng cơ bản của nó là để sắp xếp các tính năng và chế độ thiếu sót của phần mềm theo thứ tự giảm dần, từ những điều quan trọng nhất hoặc những rủi ro lớn nhất đến những tính năng tốt nhất hoặc rủi ro đơn giản (một trong những công cụ làm điều này là FMEA: các chế độ thiếu sót và các phân tích tác động). Người kiểm thử cho ra một danh sách bằng tay khi kiểm thử một tái bản mới dưới một lịch trình chặt chẽ, người kiểm thử tập trung đảm bảo những điều vừa giới thiệu không phá vỡ bất kỳ điều gì. Thật dễ dàng để đảm bảo những thay đổi không phá vỡ bất kỳ các tính năng quan trọng nhất trong phần mềm và không có các nguy cơ nghiêm trọng nhất xảy ra.


Tóm tắt

Tất cả các công ty đều muốn có được vị thế cao trong thị trường CNTT đầy cạnh tranh, và phải mất công sức để tạo ra những phần mềm tốt mà mọi người thích. Thật không may, đôi khi áp lực từ phía khách hàng hoặc quản lý thiếu kiên nhẫn có thể khiến cả đội bỏ qua việc kiểm tra chất lượng phần mềm, và họ có thể sẽ cung cấp một sản phẩm có chất lượng thấp hơn mong đợi. Chất lượng kém của phần mềm được nhận thấy chỉ khi nó hoạt động sai.

Thực tiễn và phương pháp thảo luận trong bài viết này bao quát toàn bộ chu kỳ phát triển. Bao gồm các phân tích yêu cầu, thiết kế và phát triển, và cuối cùng là giai đoạn kiểm thử. Và chúng cho ta thấy rằng việc phòng ngừa rủi ro là dễ dàng hơn nhiều so với việc đưa ra các thay đổi ở cuối của dự án, khi món nợ kỹ thuật và chi phí cho việc thay đổi là cao.

Trong bài viết này, vai trò chất lượng và tầm quan trọng của phần mềm được nhấn mạnh để cho thấy rằng việc bỏ qua chất lượng phần mềm có thể khiến các công ty khó đạt được mục tiêu kinh doanh của họ. Ngoài ra, bài viết giới thiệu cho người đọc một số hoạt động dễ dàng và hiệu quả hơn có thể tiết kiệm thời gian, tiền bạc, và công sức trong khi nâng cao chất lượng của sản phẩm.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=952029
ArticleTitle=Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp được đề xuất
publish-date=11072013