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