Kiểm thử phần mềm/3
Một sinh viên mới tốt nghiệp năm ngoái và nay làm việc cho một công ti phần mềm tới gặp tôi. Anh ta 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ử.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
