Trở lại chuyện kiểm thử phần mềm

GS John Vu26/05/2025 13:00
Trở lại chuyện kiểm thử phần mềm

Một sinh viên mới tốt nghiệp, làm việc cho một công ti phần mềm gặp tôi nói: “Tôi làm việc là người kiểm thử phần mềm, tôi kiểm thử mọi thứ rất cẩn thận nhưng khách hàng của tôi vẫn tìm ra lỗi. Tôi đã làm gì sai và tôi có thể làm gì để là người kiểm thử giỏi hơn?”

Tôi bảo anh ta: “Nếu bạn đã làm hết sức mình thì có thể bạn không làm điều gì sai cả. Người kiểm thử giỏi phải biết rằng không thể nào kiểm thử được mọi thứ. Kiểm thử không loại bỏ được mọi lỗi và sự kiện là một số lỗi có thể xảy ra bởi các nhân tố khác. Có thể là yêu cầu được đưa cho bạn không đầy đủ hay chúng vẫn đang thay đổi khi bạn tiến hành kiểm thử. Khả năng kiểm thử phần mềm tuỳ thuộc vào kĩ năng của người kiểm thử trích ra thông tin đúng để xây dựng các trường hợp kiểm thử. Nếu bạn không có mọi thông tin hay nếu thông tin đó thay đổi thường xuyên thì bạn có thể không có khả năng xây dựng các trường hợp kiểm thử tốt. Cho nên đó có thể không phải là toàn bộ lỗi của bạn.

Anh ta hỏi: “Làm sao tôi có thể chắc rằng tôi KHÔNG có lỗi nào?”

Tôi bảo anh ta: “Không thể nào kiểm thử được mọi thứ cho nên biết cái gì có thể được kiểm thử là khởi đầu tốt. Tri thức kiểm thử ở bất kì điểm nào đã cho trong dự án đều được xác định bởi điều có thể được kiểm thử vào lúc đó. Nếu bạn vẫn có lỗi, thay vì tạo ra thêm trường hợp kiểm thử để đảm bảo lỗi không xuất hiện lại, bạn phải đánh giá “Tại sao” nó đã xảy ra. Thông tin nào bạn thiếu, và tại sao bạn bỏ thiếu nó? Thay vì đánh giá bao quát kiểm thử bạn có thể cần nhìn vào các kĩ thuật kiểm thử của mình. Đánh giá cái gì và làm sao bạn kiểm thử trong toàn dự án, và bạn có thể yêu cầu người khác trong dự án của bạn giúp bạn đánh giá điều bạn đang làm.

Anh ta nói với tôi: “Người quản lí của tôi bao giờ cũng phàn nàn: “Sao cậu không tìm ra lỗi này trước khi phần mềm được đưa ra?” và tôi lo lắng rằng tôi có thể không có khả năng giữ được việc của tôi.”

Tôi bảo anh ta: “Dễ dàng trách người kiểm thử về vấn đề phần mềm. Nhiều người tin rằng mục đích của kiểm thử là “loại bỏ mọi lỗi” trong phần mềm. Thực tại là kiểm thử chỉ có thể chứng minh sự tồn tại của lỗi nhưng không bao giờ chứng minh được hết lỗi. Người quản lí giỏi nên biết rằng người kiểm thử không làm việc với khách hàng để hiểu nhu cầu của họ, người kiểm thử không viết các yêu cầu, người kiểm thử không kiến trúc hệ thống, người kiểm thử không thiết kế các tính năng của hệ thống, và người kiểm thử không phát triển giải pháp cho nên trách người kiểm thử mà không biết lỗi tới từ đâu là KHÔNG công bằng.

Tôi thường tự hỏi tại sao người quản lí không hỏi, “Sao phần mềm này được thiết kế kém thế?” hay “Sao một chức năng được lập kế hoạch tồi thế?” Sao chúng ta không hỏi “Người lập trình đã làm giả định gì mà dẫn tới việc xen vấn đề vào trong mã?” và “Chúng ta có thể làm gì để ngăn cản lỗi tái xuất trong tương lai?” Tại sao người quản lí cấp cao không hỏi người quản lí dự án về tại sao họ dồn gánh nặng ‘chất lượng’ và thành công của sản phẩm phần mềm lên CHỈ MỖI người kiểm thử.

Tôi tin có hai lí do tại sao người kiểm thử bị trách móc về lỗi phần mầm. Thứ nhất, mọi người giả định sai lầm mục tiêu của kiểm thử CHỈ để tìm ra lỗi. Thứ hai, người kiểm thử đảm nhiệm về những điều họ KHÔNG kiểm soát được bởi vì niềm tin của cấp quản lí là người càng ít kinh nghiệm hay mới tốt nghiệp nên làm việc như người kiểm thử. Chúng ta biết rằng không thể nào kiểm thử được mọi thứ, và nếu người kiểm thử không có kinh nghiệm, không nhận được đào tạo thích hợp thì tiềm năng bỏ sót lỗi sẽ tăng lên đáng kể.

Theo ý kiến tôi, mục tiêu của kiểm thử phần mềm là cung cấp “Thông tin về thuộc tính và năng lực của phần mềm đang được kiểm thử” cho người có trách nhiệm ra quyết định kinh doanh trọng yếu. Bởi vì thông tin này sẽ cho phép họ hiểu rủi ro tiềm năng trong mối quan hệ với mong đợi của họ về phần mềm trước khi đưa ra. Nếu số lỗi mà cao, họ có thể ra lệnh kiểm thử nhiều hơn hay cho phép nhiều thời gian hơn để kiểm thử nhằm giảm cơ hội có lỗi sau khi đưa ra cho khách hàng.

Lỗi phần mềm cung cấp cho người ra quyết định và các thành viên khác trong tổ những thông tin về phần mềm cho nên người quản lí dự án có thể ra lệnh “phân tích căn nguyên” hay có nhiều kiểm điểm và giám định phần mềm hơn để nhận diện CHỖ lỗi xuất hiện và sửa nó để cho nó sẽ KHÔNG xảy ra nữa. Điều quan trọng là “Xây dựng chất lượng trong phần mềm” thay vì “Kiểm thử vì chất lượng” bởi vì kiểm thử sẽ không bao giờ chứng minh việc hết lỗi, không có điều như không lỗi vì điều đó chỉ tồn tại trong lí thuyết. Vấn đề chính là người quản lí dự án không cho thời gian thích hợp cho các hoạt động khác cho nên họ không có thời gian để làm việc tốt. Việc được thực hiện kém sẽ tạo ra lỗi và vấn đề rồi họ trách móc người kiểm thử phần mềm.

Để cải tiến phần mềm và đạt tới sự hài lòng của khách hàng, chúng ta phải nhìn vào toàn bộ qui trình của phát triển phần mềm từ đầu tới cuối để nhận diện vấn đề xảy ra từ đâu. Chúng ta không thể chỉ nhìn vào chỗ cuối rồi trách móc người kiểm thử.

English version

Testing software

A student who graduated last year and now working for a software company came to see me. He said: “I work as software tester, I test everything very carefully but my customer still finds defects. What did I do wrong and what could I do to be a better tester?”

I told him: “If you have done your best then maybe you did not do anything wrong. A good tester should know that it is impossible to test everything. Testing does not remove all defects and the fact is some of these defects may happen because of other factors. It is possible that the requirements given to you may be incomplete or they are still changing when you conduct your test. The ability to test software depends on the skills of the testers to extract the right information to build test cases. If you do not have all the information or if that information changes often then you may not be able to build good test cases. So it may not be your entire fault.

He asked: “How can I make sure that I do NOT have any defects?”

I told him:” It is impossible to test everything so knowing what could possibly be tested is a good start. Testing knowledge at any given point in a project is determined by what could be tested at that time. If you still have defect, instead of create more test case to ensure the defect doesn’t occur again, you must evaluate “Why” it happened. What information were you missing, and why were you missing it? Instead of evaluating the test coverage you may need to look at your testing techniques. Evaluate what and how you are testing throughout the project, and you may ask others in your project to help you evaluate what you are doing.

He told me: “My manager always complained: “Why didn’t you find this defect before it was released?” and I am worry that I may not be able to keep my job”.

I told him: “It is easy to blame tester for software problem. Many people believe that the purpose of testing is to “remove all defects” in software. The reality is testing can only prove the existing of defects but never prove the absence of defects. A good manager should know that testers do not work with customer to understand their needs, testers do not write requirements, testers do not architect the system, testers do not design the system’s features, and testers do not develop the solution so blaming the tester without knowing where the defects come from is NOT fair. I often wonder why manager do not ask, “Why is this software designed so poorly”, or “why a function is so poorly planned?” Why don’t we ask “what assumptions did the programmer make that lead to injecting problems into the code”, and “what can we do to prevent recurrent errors in the future?” Why senior manager do not ask project managers on why they put the burden of ‘quality’ and the success of a software product SOLELY on testers.

I believe there are two reasons why testers are blamed for software defect. First, people mistakenly assume the objective of testing is ONLY to find and fix defects. Second, testers are held accountable for things they have NO control over because of management belief that lesser experienced or newly graduates should work as testers. We know that it is impossible to test everything, and if the tester is inexperienced, do not receive adequate training then the potential to miss defects will increases significantly.

In my opinion, the objective of software testing is to provide “Information about the attributes and capabilities of the software under test” to people responsible for making critical business decisions. Because these information will allow them to understand the potential risks in relation to their expectations of the software prior to release. If the defect number is high, they may order more tests or allow more time for testing to reduce the chance of having defects after release to customer. Software defects provide the decision makers and other team members with information about the software so project manager may order “root cause analysis” or more software reviews and inspections to identify WHERE the defect come from and fix it so it will NOT happen again; It is important to “Build quality into software” instead of “Testing for quality” because testing will never prove the absence of defects, there is no such thing as zero defects as it only exist in theories. The major problem is project managers do not give adequate time for other activities so they do not have time to do good jobs. Poorly done jobs will create defects and problems then they blame on software testers.

To improve software and achieve customer satisfaction, we have to look at the entire process of software development from the beginning to the end to identify where problems happen. We can not only look at the end then blame testers.

 


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

Nghề phần mềm

Nhiều sinh viên đã hỏi tôi họ có thể làm gì sau khi làm việc như người phát triển phần mềm trong nhiều năm. Có nhiều con đường nghề nghiệp mà người phát triển có kinh nghiệm có thể lựa chọn. Sau đây là một số con đường:

Làm việc theo tổ và làm việc theo nhóm

Có khác biệt giữa “Làm việc theo tổ” và “Làm việc theo nhóm”.

Làm việc theo tổ

Trong cuộc họp, nhiều cựu sinh viên tới gặp tôi kể về việc “Làm việc theo tổ”. Họ bảo tôi rằng họ đã làm việc trong tổ xây dựng phần mềm nhưng khi tôi hỏi thêm các câu hỏi, dường như là họ đã làm việc “trong nhóm” mà KHÔNG “trong tổ”.

Hệ thống giáo dục

Có ba kiểu hệ thồng giáo dục tồn tại ngày nay, giáo dục truyền thống, giáo dục thời đại công nghiệp, và giáo dục thời đại thông tin.

Phát triển nghề nghiệp

Mọi năm, tôi đều nhận được nhiều emails từ các sinh viên đã tốt nghiệp hỏi lời khuyên về nghề nghiệp của họ.

Xin việc

Mọi năm các công ti phần mềm đều nhận hàng nghìn đơn xin việc làm.

Công nghiệp phần mềm cần gì

Chúng tôi thảo luận với một nhóm quản lí cấp cao của các công ti phần mềm Trung Quốc khi họ thăm Carnegie Mellon về công nghiệp phần mềm ở Trung Quốc và họ bảo rằng rất khó tìm được người đúng với kĩ năng đúng bởi vì đào tạo đại học là KHÔNG nhất quán.

Người quản lý có kinh nghiệm

Một dự án điển hình thường yêu cầu các thành viên tổ có những kĩ năng kĩ thuật chuyên môn nhưng với người quản lí có kinh nghiệm, một mình kĩ năng kĩ thuật là KHÔNG đủ.

Chiến tranh máy tính

Theo một số nghiên cứu, chiến tranh tiếp đây trong thế kỉ 21 có thể không phải là làm chiến tranh theo qui mô đầy đủ với bom nguyên tử mà là “Chiến tranh máy tính” nơi các nước tấn công lẫn nhau bằng “vi rút và sâu máy tính” hay “Tấn công xi be.”

Nơi vết thương ánh sáng rọi vào - Hành trình viết lại cuộc đời bằng yêu thương

Không phải ngẫu nhiên mà tình yêu thương luôn được đặt ở vị trí trung tâm của mọi giá trị sống, vượt qua mọi thời đại và nền văn hóa. Bởi trong thế giới nhiều bất an này, yêu thương không chỉ giúp con người tồn tại, mà còn là thứ duy nhất có thể cứu rỗi họ.

Xem "Sex Education" tôi rút ra bài học để thay đổi cậu con trai hư hỏng

Điện ảnh - Mỹ Hạnh - 18/07/2025 13:00
Tại sao tôi lại không xem bộ phim "Sex Education" sớm hơn. Như vậy thì gia đình đã không phải trải qua những ngày tháng mệt mỏi.

Hành trình giông bão của người mẹ đơn thân nuôi con bại não thành Thạc sĩ Harvard

Truyền cảm hứng - Ứng Hà Chi - 18/07/2025 12:00
Từ cậu bé bại não, cậu bé ấy trở thành Thạc sĩ Harvard nhờ nghị lực và tình yêu bền bỉ của mẹ.

Trước khi có internet và Wi-Fi, những đứa trẻ của thập niên 1980 download game bằng cách nghe Radio

Kỹ năng - Nguyễn Hải - 18/07/2025 11:00
Đây cũng là hình thức đầu tiên của việc truyền dữ liệu không dây đến cho mọi người khi chưa có internet và Wifi.

Vũ trụ "thối não": Coi mấy thứ dị dạng này bảo sao học kém, phụ huynh EQ cao không nói câu này

Suy ngẫm - S.A - CFB - 18/07/2025 10:00
Thái độ của cha mẹ quyết định rất nhiều đến tính cách của con cái.

Nơi vết thương ánh sáng rọi vào - Hành trình viết lại cuộc đời bằng yêu thương

Từ sách - Phim - Đoàn Huy - 18/07/2025 09:00
Không phải ngẫu nhiên mà tình yêu thương luôn được đặt ở vị trí trung tâm của mọi giá trị sống, vượt qua mọi thời đại và nền văn hóa. Bởi trong thế giới nhiều bất an này, yêu thương không chỉ giúp con người tồn tại, mà còn là thứ duy nhất có thể cứu rỗi họ.

Đơn giản mà nói - Cái bẫy của sự phức tạp trong marketing hiện đại

Từ sách - Phim - Quìn - 18/07/2025 08:00
Trong cuốn sách "Đơn giản mà nói" (Simply Put), tác giả Ben Guttmann đưa ra một quan điểm tưởng chừng đơn giản nhưng vô cùng quan trọng: giữa thế giới quá tải thông tin, thương hiệu nào càng rõ ràng, dễ hiểu, thương hiệu đó có cơ hội tồn tại.

Nghề phần mềm

Blog GS John VU - GS John Vu - 17/07/2025 13:00
Nhiều sinh viên đã hỏi tôi họ có thể làm gì sau khi làm việc như người phát triển phần mềm trong nhiều năm. Có nhiều con đường nghề nghiệp mà người phát triển có kinh nghiệm có thể lựa chọn. Sau đây là một số con đường:

Xem "Sex Education", tôi nghỉ chơi với bạn thân nhờ nhận ra tình bạn độc hại

Điện ảnh - Ứng Hà Chi - 17/07/2025 12:00
Nhờ bộ phim, tôi nhận ra bấy lâu nay mình luôn là "cái bóng" của bạn thân, chưa thực sự sống là chính mình.

Những người lương cao chia sẻ: Thiếu kỹ năng mềm này sẽ kìm hãm bạn khỏi sự thăng tiến

Kỹ năng - Diệp Anh - 17/07/2025 11:00
Bạn có tham vọng thăng tiến lên vị trí lãnh đạo cấp cao hay muốn tăng lương tới mức hấp dẫn? Khả năng phán đoán chính là kỹ năng mềm quan trọng nhất quyết định thành công của bạn.

Tâm lý học: Đây là trạng thái năng lượng tiêu cực khiến cuộc đời tụt dốc không phanh

Suy ngẫm - Ứng Hà Chi - 17/07/2025 10:00
Những người hay bồn chồn lo lắng thường dễ dàng bị đánh bại bởi chính mình.

Nơi vết thương ánh sáng rọi vào - Điểm ACE: Chỉ số ám ảnh hay chìa khóa để chữa lành sang chấn tuổi thơ?

Từ sách - Phim - TĐ - 17/07/2025 09:00
Bài viết được trích lược từ cuốn "Nơi vết thương ánh sáng rọi vào" (What My Bones Know: A Memoir of Healing from Complex Trauma) - Hành trình chữa lành sang chấn phức tạp của tác giả Stephane Foo.

'Khai mở cảm xúc' và 'Khai mở hạnh phúc' - 5 gợi ý giúp bạn đưa ra quyết định đúng với chính mình

Từ sách - Phim - Quìn - 17/07/2025 08:00
Chúng ta đang sống trong một thời đại có quá nhiều lựa chọn, và chính điều đó khiến không ít người rơi vào cảm giác mất phương hướng. Một câu hỏi tưởng chừng đơn giản “Mình nên chọn điều gì?”, lại trở thành nỗi trăn trở thường trực.

Xem Sex Education, mặt tôi đỏ như gấc, cứ ngỡ đang xem chuyện nhà mình

Điện ảnh - Thanh Hương - 16/07/2025 13:00
Tôi đã nhận ra những bài học cực đắt giá trong việc nuôi dạy con cái.

Hướng dẫn dùng ChatGPT tạo ảnh căn cước

Kỹ năng - Quang Huy - DT - 16/07/2025 12:00
Bạn muốn chụp một bức ảnh căn cước trong trang phục văn phòng lịch sự để sử dụng khi nộp hồ sơ trực tuyến hoặc cho một mục đích nào đó? Bài viết sau sẽ giúp bạn tạo ra hình ảnh như vậy bằng ChatGPT.

"Logo sống" đọc sách trên cao hút du khách: Công việc kỳ lạ, lương cao ngất ngưởng không ngờ

Thư giãn - Phạm Trang - 16/07/2025 11:00
Chỉ cần ngồi yên trên chiếc ghế cao cả mét, đọc sách giữa dòng người qua lại, chàng trai trẻ ở khu du lịch Vũ Nữ Châu đang khiến dân mạng Trung Quốc phát sốt với mức lương hơn 10.000 nhân dân tệ mỗi tháng, kèm theo bao ăn ở.
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
Thứ 6, 18/07/2025