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

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.

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

Adobe ra mắt ứng dụng đắc lực cho dân chụp ảnh bằng iPhone

Kỹ năng - Anh Tú - 22/06/2025 12:00
Nếu bạn yêu thích chụp ảnh bằng iPhone, ứng dụng mới của Adobe có thể nhanh chóng trở thành công cụ ưa thích của bạn.

Kim Dung giải thích vì sao Kiều Phong 1 chưởng đánh Vô Danh Thần Tăng gãy xương mà không giết nổi con hổ?

Thư giãn - Nguyệt Phạm - 22/06/2025 11:00
Sự khác biệt về thực lực của Kiều Phong được giải thích thế nào?

Nước mắt "thánh nữ" Maria Ozawa: "Người ta chỉ nhìn thấy tôi trên màn ảnh, nhưng không biết tôi là ai khi tắt máy quay"

Giải trí - Nguyễn Phượng - 22/06/2025 10:00
Trên khuôn mặt trái xoan là cái mũi dọc dừa và đôi mắt ma mị. Maria Ozawa có thể “giết chết” trái tim đàn ông chỉ bằng một ánh mắt. Nhưng phía sau máy quay, chẳng ai tin "nữ hoàng" cũng phải khóc.

Đường vào thiền - Nhờ mối phân tâm này mà bạn không nhìn thấy nỗi đau bên trong

Từ sách - Phim - FN - 22/06/2025 09:00
Hãy nhìn vào những gì bạn đang làm: bạn có tìm cách quên đi nỗi đau không? Nếu tất cả cách thức mà bạn đang sử dụng để quên đi nỗi đau đó bị tước mất, bạn sẽ càng đau khổ hơn.

Vượt lên nghịch cảnh – Chiến thắng con quỷ bên trong chính mình

Từ sách - Phim - Quìn - 22/06/2025 08:00
Trong cuốn sách "Chiến thắng con Quỷ bên trong" (Outwitting the Devil: The Secret to Freedom and Success), Napoleon Hill không chỉ vạch trần những nỗi sợ hãi vô hình mà còn chỉ ra một sự thật sâu sắc: nghịch cảnh không phải là kẻ thù, mà là người thầy vĩ đại nhất.

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