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 R. Elgebeely (ayag@eg.ibm.com) 07 11 2013
Nhà phát triển ứng dụng
IBM

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.

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à

© Copyright IBM Corporation 2013 Nhẫn hiệu đăng ký

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 1 của 7
được đề xuất
developerWorks® ibm.com/developerWorks/vn/

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ử.

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 2 của 7
được đề xuất
ibm.com/developerWorks/vn/ developerWorks®

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

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 3 của 7
được đề xuất
developerWorks® ibm.com/developerWorks/vn/

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

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

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 4 của 7
được đề xuất
ibm.com/developerWorks/vn/ developerWorks®

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.

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 5 của 7
được đề xuất
developerWorks® ibm.com/developerWorks/vn/

Tài nguyên
Học tập

• Khám phá vùng phần mềm Rational trên developerWorks với những tài nguyên kỹ thuật, thực
hành tốt nhất, và thông tin về Rational và tích hợp phần mềm và hệ thống cung cấp.
• Theo dõi các webcast và sự kiện công nghệ của developerWorks về các sản phẩm IBM và các
lĩnh vực công nghệ thông tin.
• Tham dự các buổi phổ cập công nghệ miễn phí trực tuyến trên developerWorks để tiếp cận
nhanh sản phẩm và công cụ IBM, cũng như các xu hướng công nghệ.
• Xem các demo theo yêu cầu trên developerWorks, trải dài từ các hướng dẫn cài đặt và thiết
lập sản phẩm cho người mới bắt đầu đến các tính năng nâng cao cho các nhà phát triển có
kinh nghiệm.

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

• Tải về bản dùng thử của phần mềm Rational.

• Đánh giá phần mềm IBM theo cách phù hợp nhất với bạn: bạn có thể tải về, dùng thử trực
tuyến hay trên môi trường đám mây.

Thảo luận

• Tham gia diễn đàn phần mềm Rational để cùng thảo luận.
• Cùng tham gia thảo luận để nâng cao kinh nghiệm trong diễn đàn Rational, cafés, và thư viện
wiki.
• Tham gia vào cộng đồng Rational để chia sẻ kiến thức và kết nối đến các thành viên.
• Xem lại và đánh giá nhanh phần mềm Rational.

Những vấn đề đặt ra về chất lượng phần mềm và các phương pháp Trang 6 của 7
được đề xuất
ibm.com/developerWorks/vn/ developerWorks®

Đôi nét về tác giả

Aya R. Elgebeely

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.

© Copyright IBM Corporation 2013

(www.ibm.com/legal/copytrade.shtml)
Nhẫn hiệu đăng ký
(www.ibm.com/developerworks/vn/ibm/trademarks/)

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