Kiểm thử chất lượng

GS John Vu03/10/2024 12:00
Kiểm thử chất lượng

Trong quá khứ khi phần mềm còn nhỏ, chỉ vài trăm dòng mã, thì kiểm thử là tương đối dễ dàng. Là người phát triển phần mềm, điều tôi đã làm là phải chắc rằng thuật toán đúng và phân tích kết cấu chương trình để chắc chắn nó được biên dịch đúng.

Nếu tôi có lỗi, tôi sửa chúng rồi biên dịch lại cho nên kiểm thử không thành vấn đề. Tuy nhiên, khi kích cỡ phần mềm trở nên lớn hơn, tôi bắt đầu thấy rằng tôi bị nhiều lỗi sau khi đưa ra cho khách hàng (một lỗi là chồng bị tràn) cho nên tôi bắt đầu cẩn thận hơn về kiểm thử. Tôi bắt đầu viết các trường hợp kiểm thử để chắc chắn rằng chương trình chạy đúng và đáp ứng nhu cầu với dữ liệu vào và dữ liệu ra (kiểm thử hộp đen). Cuối cùng, nhiều chương trình tôi đã viết đã được tích hợp với các chương trình khác cho nên là một tổ chúng tôi đã phân chia công việc của mình thành các chức năng và tính năng tách bạch dựa trên phương pháp phân tích cấu trúc nhưng chúng tôi vẫn làm việc một cách độc lập, chỉ thảo luận với nhau khi cần.

Từng người vẫn làm kiểm thử riêng và chúng tôi tin tưởng rằng mọi thứ phải làm việc theo cách chúng tôi nghĩ, nhưng đến cuối cùng nó lại không làm việc tốt. Có quá nhiều lỗi trong sản phẩm cuối cùng của chúng tôi cho nên người quản lí của tôi quyết định thành lập nhóm kiểm thử bao gồm nhiều người lập trình mới tuyển, người được trao cho việc kiểm tra lại phần mềm để chắc chắn chúng làm việc được trước khi chúng được đưa ra.  Là người phát triển phần mềm, chúng tôi chỉ phải tập trung hầu hết vào thiết kế và viết mã.

Chúng tôi đã kiểm thử mã riêng của mình và không lo nghĩ nhiều về phần còn lại của phần mềm cuối cùng. Cho nên tổ của chúng tôi bao gồm hai nhóm, nhóm người phát triển và nhóm kiểm thử và quan niệm này đã được chấp nhận trong nhiều công ti phần mềm và nó vẫn là cách thức nhiều công ti vận hành ngày nay.

Bây giờ nhìn lại sao nhiều năm, ngạc nhiên lớn nhất của tôi là làm sao nhiều người vẫn tin rằng bạn có thể “kiểm thử chất lượng” trong sản phẩm phần mềm. Ngày nay phần lớn các phần mềm đều rất lớn và phức tạp, nhiều dự án của tôi có khoảng 5 tới 20 triệu dòng lệnh và không thể nào kiểm thử hết mọi thứ cho nên thay vì hội tụ vào kiểm thử, chúng tôi hội tụ vào cách tiếp cận có kỉ luật để “xây dựng trong chất lượng” khi chúng tôi làm việc.

Điều này cũng là khác biệt chính giữa đào tạo kĩ nghệ phần mềm và khoa học máy tính. Với kĩ nghệ phần mềm, bạn phải hội tụ vào qui trình tạo ra sản phẩm và “xây dựng chất lượng trong qui trình” cho nên sản phẩm cuối sẽ có chất lượng. Tất nhiên, không ai hoàn hảo cho nên bạn phải dựa vào người khác để hỗ trợ cho bạn và nhận diện sai lầm của bạn để cho bạn có thể sửa nó. Do đó, kiểm điểm phần mềm, giám định mã, lập trình cặp, suy nghĩ theo pha, và rút ra bài học được áp dụng để đảm bảo rằng chúng ta sẽ có sản phẩm chất lượng.

Khi sinh viên tới lớp của tôi tại CMU, nhiều người có thái độ “Sao lại chú ý tới lỗi khi đằng nào chúng ta cũng có thể sửa được nó” hay “Viết mã trước, sửa lỗi sau” cho nên tôi kể cho họ một kịch bản: “Giả sử rằng bạn đang bay trong máy bay và bạn nghe phi công nói rằng anh ta gặp lỗi phần mềm trong hệ thống điều khiển và phải “khởi động lại” hệ thống. Khởi động lại hệ thống sẽ mất bao nhiêu thời gian? Chỉ mười hay hai mươi phút và điều đó có nghĩa là máy bay sẽ không có nguồn trong thời gian đó và tất nhiên sẽ rơi” và tôi hỏi: “Bạn có thực sự quan tâm tới lỗi phần mềm hay không?”

Khi cả lớp cười to, tôi nói thêm: “Tôi chắc chắn điều đó tuỳ thuộc vào quan điểm của bạn, bạn có lẽ quan tâm nếu bạn đang ở trên máy bay và không quan tâm nếu bạn đang ở trên mặt đất. Cho nên vấn đề thực là liệu lỗi có vấn đề theo nghĩa lí thuyết không nhưng liệu nó có là vấn đề cho bạn không. Để tôi cho bạn ví dụ khác, bạn là người chủ của một công ti phần mềm và bạn có hàng trăm người lập trình  làm việc cho bạn. Nếu khách hàng thấy lỗi phần mềm trong sản phẩm của bạn thì bạn phải sửa nó.

Chi phí để phát hiện, phục hồi, báo cáo, sửa chữa, phân phối lại và chi phí cài đặt lại cho mọi lỗi trung bình sẽ là quãng $ 4000 cho từng lỗi và có hàng trăm hay hàng nghìn lỗi cho sản phẩm bạn bán. Bạn có thực sự quan tâm không?  Bạn bán phần mềm đó được bao nhiêu và bạn phải chi bao nhiêu tiền để sửa lỗi? Bất kể nguyên nhân của chúng, chi phí lỗi đều rất đắt, nếu bạn phải trả chi phí này, bạn sẽ thực sự quan tâm về lỗi. Câu hỏi của tôi là, là người chủ công ti phần mềm, bạn vẫn thuê những người không quan tâm về lỗi sao?

Theo nghiên cứu của giáo sư Watt Humphrey tại Carnegie Mellon, người phát triển phần mềm có kinh nghiệm đưa vào một lỗi cứ trong mỗi 10 dòng mã. Trong khi các con số này thay đổi lớn từ người phát triển phần mềm này sang người phát triển khác, và họ đưa vào mọi thứ lỗi, thậm chí cả những lỗi được tìm thấy trong kiểm điểm hay bởi trình biên dịch, vẫn có nhiều lỗi. Tuy nhiên, nhiều người phát triển phần mềm tin rằng trình biên dịch sẽ tìm ra mọi lỗi. Không may có nhiều lỗi gõ vào mà trình biên dịch lại không tìm ra.

Chẳng hạn, trong C, gõ “=“ thay cho “= =“ có thể tạo ra phép gán thay vì phép so sánh. Mặc dầu trình biên dịch có thể tìm ra 90% lỗi nhưng còn 10% kia thì sao? Nhiều người tin rằng 10% kia có thể được thực hiện bằng kiểm thử. Tuy nhiên, nhiều chương trình sẽ chạy ngay cả khi chúng có lỗi. Thực tế, chúng có thể có nhiều lỗi và vẫn qua được nhiều kiểm thử. Ngay cả để tìm ra số phần trăm lỗi lớn trong một chương trình, chúng ta vẫn phải kiểm thử gần như tất cả các con đường và điều kiện logic. Và để tìm ra tất cả các lỗi trong ngay cả chương trình nhỏ, chúng ta sẽ phải cho chạy kiểm thử vét cạn mà có thể tốn kém và yêu cầu nhiều nỗ lực.

Ngày nay hầu hết những người phát triển phần mềm dành nhiều thời gian cố gắng làm cho phần mềm của họ làm việc rồi dành nhiều thời gian hơn để chữa lỗi và các vấn đề được báo cáo. Đây là vấn đề chính cho doanh nghiệp nhưng nhiều người quản lí phần mềm không được huấn luyện để giải quyết điều này. Họ chỉ hội tụ vào lịch biểu, cách chuyển giao bên trong ngày tháng nào đó nhưng không biết nhiều về kinh doanh tài chính. Tất nhiên người quản lí cấp cao biết nhưng họ quá bận quản lí công ti và không chú ý tới dự án cho nên những người cuối cùng thực sự quan tâm là khách hàng. Tất nhiên khách hàng có chọn lựa và khi họ không thoả mãn với chất lượng, họ làm kinh doanh với ai đó khác.

Tôi cũng thấy rằng hầu hết những người phát triển phần mềm không được đào tạo trong việc nhận diện và sửa lỗi an ninh. Lỗi an ninh là bất kì lỗi thiết kế nào cho phép các hắc khách, kẻ phạm tội, hay kẻ khủng bố thu được quyền truy nhập hay dùng hệ thống phần mềm. Vì nhiều trong số các lỗi này không gây ra vấn đề chức năng, hay lỗi khi chạy, chúng sẽ qua mọi kiểm thử chức năng nhưng phần mềm vẫn có những mong manh an ninh tiềm năng mà có thể tạo ra vấn đề trong tương lai.

Quan điểm của tôi là để đảm bảo chất lượng, chúng ta phải xây dựng chất lượng trong cách chúng ta làm việc và rằng lỗi là vấn đề nghiêm chỉnh yêu cầu sự chú ý lớn từ mọi người. Cách tốt nhất để ngăn cản lỗi là đào tạo tốt hơn và đào tạo nên bắt đầu sớm nhất có thể được trong mọi đại học và nên được nhấn mạnh trong mọi lớp tính toán.

English version

Testing quality

In the past when software was small, only few hundred lines of code then testing was relatively easy. As a software developer, what I did was to make sure that the algorithms were right and analyzed the program construction to make sure that it compiled correctly. If I had errors, I fixed them then re-compiled so testing was not an issue. However, as software size getting larger, I began to see that I had several defects after released to the customer (One was overflow stack) so I started to be more careful about testing. I began to write test cases to make sure that the program ran correctly and meet the requirements with input data and output data (Black-box testing). Eventually, many programs that I wrote have to be integrated with other programs so as a team we divided our works into separate functions and features based on structure analysis method but we were still working independently, only discussed with each other when needed. Each person did its own tests and we were confident that everything should work the way we think but in the end it did not worked well. There were so many defects in our final product so my managers decided to form a testing group consisted of many newly hired programmers who were given the job of checking softwares to make sure they worked before they were released.  As software developers, we only have to focus mostly on design and code. We tested our own code and not worried much about the rest of the final software. So our team consisted of two groups, developer group and testing group and this concept had been adopted in many software companies and it still is the way many companies operate today.

Now looking back for so many years my biggest surprise is how many people still believe that you can “test quality” into a software product. Today most software are very large and complex, many of my projects have about 5 to 20 million lines of code and it is impossible to test everything so instead of focus on testing, we focus on a disciplined approach to “build in quality” as we work. This is also a major difference between software engineering and computer science training. With software engineering, you must focusing on the process that creates the product and “build quality into the process” so the final product will have quality. Of course, nobody is perfect so you must rely on others to support you and identify your mistakes so you can fix it. Therefore, software reviews, code inspections, pair-programming, phase reflection, and lesson learned are applied to ensure that we will have quality product.

When students come to my class at CMU, many have an attitude of “Why cares about defect when we can fix it anyway” or “Code first, fix defects later” so I tell them a scenario: “Assume that you are flying in an airplane and you hear the pilot said that he has software defect in the control system and must “reboot” the system. How long will it take to reboot the system? Only ten or twenty minutes and that mean the airplane will have no power during that time and of course will crash” and I ask: “Do you really care about software defect or not?” As the class laughing aloud, I add: “I am sure it depends on your point of view, you probably care if you are on the plane and do not care if you are on the ground. So the real issue is whether defect matter in a theoretical sense but whether it matter to you. Let me give you another example, you are the owner of a software company and you have hundred software developers working for you. If customer finds software defects in your product then you have to fix it. The cost of discovery, recovery, reporting, repairing, redistribution, and reinstallation costs for every defect would average about $ 4000 each and there are hundreds or thousands defects for every product that you sell. Do you really care?  How much do you sell the software for and how much you have to spend on fixing defects? Regardless of their causes, defect costs are very expensive, if you had to pay this cost, you would really care about defects. My question is, as the owner of a software company, do you still hiring people that do not care about defects?

According to the research of Professor Watt Humphrey at Carnegie Mellon, experienced software developers inject one defect in about every 10 lines of code. While these numbers vary widely from one software developer to others, and they include all the defects, even those found in reviewing or by the compiler, there are still lots of defects. However, many software developers believe that the compiler will find all defects. Unfortunately there are many typing error mistakes that are not found by the compiler. For example, in C, typing “=“instead of “= =“can cause an assignment instead of a comparison. Although compiler can find about 90% defects but what’s about the other 10%? Many people believe that the other 10% could be done by testing. However, many programs will run even when they have defects. In fact, they can have a lot of defects and still pass many tests. To find even a large percentage of the defects in a program, we would have to test almost all the logical paths and conditions. And to find all of the defects in even small programs, we would have to run an exhaustive test that could be expensive and require a lot of efforts.

Today most software developers spend a lot of time trying to get their software to work then spend more time fixing defects and reported problems. This is a major issue for the business but many software managers are not trained to deal with this. They only focus on the schedule, how to deliver within certain date but do not know much about the financial business. Of course senior managers know but they are too busy running company and not pay attention at project so the ultimate people who really care are customers. Of course the customers have choices and when they are not happy with the quality, they do business with somebody else.

I also found that most software developers are not trained in identify and fixing security defects. A security defect is any design error that allows hackers, criminals, or terrorists to obtain unauthorized access or use of a software system. Since many of these defects do not cause functional problems, or runtime errors they will pass all of their functional tests but the software has potential security vulnerabilities that could create problems in the future.

My view is to ensure quality, we must build quality into the way we work and that defects are serious issue that require significant attention from everybody. The best way to prevent defects is better training and training should start as early as possible in every university and should be emphasized in all computing classes.

 


Gửi bình luận
(0) Bình luận
1

Phía tối của công nghệ

Đã có nhiều bài viết về thành công của công nghiệp khoán ngoài CNTT ở Ấn Độ, phần lớn trong số đó đều từ quan điểm kinh tế như $ 85 tỉ đô la xuất khẩu trong năm 2008 và nhiều triệu việc làm công nghệ cao được tạo ra.

Hội cựu sinh viên CMU

Trong cuộc họp cựu sinh viên CMU hàng năm năm nay, (9/8/2009), đã có cuộc tụ họp của một số người hàng đầu trong công nghiệp phần mềm và đây là báo cáo:

Kỹ sư phần mềm chuyên nghiệp

Trong nhiều năm, ô tô Mĩ đã là tốt nhất trên thế giới nhưng cái gì đó đã thay đổi trong những năm 1970 khi cấp quản lí quyết định rằng chất lượng không quan trọng bằng số lượng.

Xây dựng kỹ năng trong ngành công nghiệp Công nghệ thông tin Ấn Độ

Báo cáo NASSCOM-McKinsey năm 2008 chỉ ra rằng, mỗi năm các đại học Ấn Độ cho tốt nghiệp hơn ba triệu sinh viên với quá nửa là kĩ sư và khoa học máy tính, chỉ một số phần trăm rất nhỏ mới được công nghiệp sử dụng trực tiếp.

Qui trình SCRUM

Agile là qui trình phát triển phần mềm “hướng theo tổ” được thiết kế cho dự án nhỏ nơi yêu cầu không ổn định và liên tục thay đổi.

Thay đổi quy trình

Bạn tôi, người quản lí một công ti lớn bảo tôi rằng anh ấy đã đem một sản phẩm phần mềm mới ra cải tiến về năng suất và hiệu quả nhưng anh ấy gặp thời gian khó khăn khi để nó làm việc trong công ti của anh ấy.

Một lời khuyên khác cho sinh viên

Tôi đã nhận được nhiều email từ các sinh viên hỏi về lời khuyên trong cuộc khủng hoảng tài chính này. Nhiều người thực sự lo sợ cho tương lai của mình và không biết phải làm gì.

Việc nóng cho sinh viên

Cuộc khủng hoảng tài chính hiện thời đã tạo ra “nhận biết thực tế” trong các sinh viên về cơ hội việc làm.

Xu hướng mới nổi lên

Thế giới công nghệ đang thay đổi rất nhanh chóng, kể cả các kĩ năng kĩ thuật và sự linh động được yêu cầu để hỗ trợ cho các thay đổi này.

Tôi đọc người đọc mỗi ngày - Làm báo chân chính là cần đối thoại với người đọc mỗi ngày

Từ sách - Phim - Đan Thanh - 21/06/2025 14:00
"Tôi đọc người đọc mỗi ngày" là một câu chuyện nghề nghiệp, tinh lọc từ sổ tay biên tập của nhà báo Huỳnh Sơn Phước, sau 40 năm hành nghề tại báo Tuổi Trẻ.

Hàng chục nghìn webcam kết nối Internet đang vô tình 'phản chủ'

Kỹ năng - Anh Tú - 21/06/2025 13:00
Theo một nghiên cứu mới từ công ty an ninh mạng Bitsight, hơn 40.000 webcam trên toàn thế giới đang ở trong tình trạng có thể truy cập công khai qua Internet – thường là mà chủ nhân không hề hay biết.

Xem "Sex Education", tôi bẽ bàng nhận ra lý do con luôn quý bạn hơn quý mẹ

Điện ảnh - Mỹ Hạnh - 21/06/2025 12:00
Tôi cố hết sức để gần gũi, tâm sự với con. Nhưng đáp lại, con chỉ thích đi chơi với bạn.

Kiếm hiệp Kim Dung: Cao thủ duy nhất chết vì võ công do chính mình tạo ra

Thư giãn - Quốc Tiệp - 21/06/2025 11:00
Nhậm Ngã Hành là một nhân vật nổi bật trong tiểu thuyết Tiếu ngạo giang hồ của cố nhà văn Kim Dung, đã để lại dấu ấn sâu đậm trong lòng độc giả.

Gemini phát triển tính năng tóm tắt nội dung PDF trong Google Drive

Kỹ năng - Anh Tú - 21/06/2025 10:00
Google đang mở rộng khả năng của Gemini bằng cách sử dụng trợ lý AI này để tóm tắt nội dung PDF trong Google Drive. Đặc biệt là lần này, tính năng không chỉ đơn thuần dừng ở việc tạo bản tóm tắt.

Xuất hiện ‘người chuột chũi’ dưới lòng thành phố làm rúng động cõi mạng

Phong cách sống - Anh Dũng - 21/06/2025 09:00
Câu chuyện về người phụ nữ xuất hiện tại miêng cống thoát nước đã lan truyền khắp mạng xã hội thời gian qua. Đằng sau những hình ảnh không ngờ ấy lại là thực trạng đáng buồn của cả một cộng đồng dân cư.

Giáo dục đích thực của 'Hạnh phúc tuổi trẻ'

Từ sách - Phim - Hồ lam - 21/06/2025 08:00
Theo triết gia J. Krishnamurti, việc so sánh bản thân với người khác, với con người mình nên là, với ai đó may mắn hơn sẽ làm giảm giá trị, sai lệch quan điểm, bản sắc của mỗi cá nhân.

Chân dung kẻ "sống lỗi"

Suy ngẫm - S.A - 20/06/2025 13:00
Bạn luôn cảm thấy người khác làm sai với mình, nhưng đã bao giờ tự thấy mình đối xử với bản thân cũng không ra gì chưa?

Xem "Sex Education", tôi xấu hổ nhận ra chính mình đang đẩy con trai ra khỏi nhà

Điện ảnh - Mỹ Hạnh - 20/06/2025 12:00
Tôi luôn nghĩ rằng mọi thứ mình làm là vì tốt cho con. Bởi tôi quá yêu con mà thôi.

ChatGPT nâng cấp giọng nói, tạo cảm giác như trò chuyện với người thực

Kỹ năng - Anh Tú - 20/06/2025 11:00
OpenAI đã cải tiến chế độ giọng nói của ChatGPT, nhằm giúp người dùng có cảm giác như đang nói chuyện với một người thật.

Dịch vụ cho thuê "người lắng nghe không phán xét" nở rộ ở TP.HCM, Hà Nội

Phong cách sống - S.A - 20/06/2025 10:00
Người cung cấp dịch vụ chỉ nghe - không đưa ra phán xét, không tư vấn tâm lý. Người tìm đến chỉ cần trút sạch tâm sự, không sợ ai bàn tán chuyện của mình. Thế là 2 bên đều vui.

TP.HCM đóng Cổng Dịch vụ công

Kỹ năng - Q.Huy - 20/06/2025 09:28
Trung tâm Chuyển đổi số TPHCM vừa thông tin chính thức về việc đóng Cổng Dịch vụ công thành phố. Kể từ 21h ngày 18/6, Cổng Dịch vụ công trực tuyến TPHCM được đóng để hợp nhất với Cổng Dịch vụ công quốc gia từ ngày 19/6.

Cuộc đời rực rỡ của Gillian Lynne: Từ cô bé bị trường từ chối dạy trở thành vũ công huyền thoại

Truyền cảm hứng - Tiểu Ngạn - 20/06/2025 09:00
Gillian Lynne là minh chứng sống cho câu nói "Không gì là không thể" và câu chuyện cuộc đời bà đã thành nguồn cảm hứng cho nhiều bậc cha mẹ trong hành trình dạy dỗ con cái.

Bạn đang chăm sóc bản thân thật sự hay... tiêu tiền cho bớt mệt?

Từ sách - Phim - Quìn - 20/06/2025 08:00
"Chăm sóc bản thân" đang dần trở thành một lối sống thời thượng – với spa, shopping, và những trải nghiệm sang chảnh. Nhưng liệu tất cả những điều đó có thực sự giúp bạn chữa lành? Hay chỉ là cách để tạm thời làm dịu đi sự mệt mỏi từ bên trong?

OpenAI nâng cấp một loạt công cụ cho ChatGPT phục vụ doanh nghiệp

Kỹ năng - Anh Tú - 19/06/2025 13:00
Với nỗ lực ngày càng tập trung vào nhóm người dùng doanh nghiệp, OpenAI vừa công bố hàng loạt nâng cấp mới cho ChatGPT.
HẠT GIỐNG TÂM HỒN
2019 Bản quyền thuộc về hatgiongtamhon.com.vn. Phát triển bởi ONECMS
Chủ nhật, 22/06/2025