Nhìn nhận đúng đắn về Testing

Vai trò của bạn trong dự án là gì? Bạn là một PM? PTL? developer? hay là một tester? Từ vị trí của mình, bạn nghĩ công việc kiểm thử (testing) trong dự án nhằm mục đích gì?
Tôi đã làm việc với khá nhiều người, ở nhiều vị trí trong dự án. Dường như, họ không có một định nghĩa rõ ràng về công việc của Test team. Nhớ lại về những dự án mình đã làm việc, những bạn tester mà tôi đã có cơ hội chỉ bảo, hướng dẫn đến với nghề, chưa bao giờ tôi nói với họ một định nghĩa cụ thể nào đó về công việc mà họ đang và sẽ làm. Đâu đó trong quá trình thực hành và trưởng thành với nghề, họ có thể nhận thức được mình đang làm gì, và vô hình chung hình thành một khái niệm nhất định cho bản thân mình về công việc testing trong dự án.
Hãy giúp tôi, tự đặt cho mình câu hỏi: Testing là gì?
Tất nhiên, tôi không thể biết câu trả lời của bạn (trừ khi bạn sẵn lòng hồi đáp lại cho tôi). Thường thì sẽ có một vài quan điểm, nhưng việc nhận thức sai vấn đề có thể ảnh hưởng đến hiệu quả và mục đích công việc của bạn rất nhiều. Vì sao ư? Tôi sẽ chỉ cho bạn thấy.
Một trong số những nguyên nhân quan trọng của chất lượng test kém là thực tế, các kỹ sư phần mềm thường bắt đầu với một định nghĩa sai lầm. Họ có thể cho rằng:
Testing là quá trình chứng minh rằng lỗi không xuất hiện trong chương trình.
hoặc
Mục đích của testing là chỉ ra rằng chương trình đã thực hiện những chức năng dự định một cách chính xác.
hoặc
Testing là quá trình thiết lập sự tin cậy rằng một chương trình đã làm những gì mà nó phải làm.
Có gì sai không? Ừm, có vẻ không sai nhỉ! Nhưng thực ra, những định nghĩa này hoàn toàn ngược.
Khi bạn kiểm thử một chương trình, bạn cần thêm các giá trị cho công việc của mình. Thêm giá trị cho quá trình kiểm thử có nghĩa là làm tăng chất lượng hoặc độ tin cậy của chương trình. Tăng độ tin cậy của chương trình chính là tìm và loại bỏ lỗi.
Do đó, đừng test một chương trình chỉ để cho thấy chương trình đó có làm việc hay không, thay vào đó, bạn nên bắt đầu bằng một giả định, rằng chương trình đó có lỗi (tất nhiên rồi, đây thậm chí có thể gọi là thực tế ấy chứ) và do đó, testing là quá trình tìm ra lỗi nhiều nhất có thể.
Khi đó, một định nghĩa hợp lý sẽ là: Testing là một quá trình thực hiện một chương trình với mục đích tìm ra lỗi.
Nếu so sánh với các định nghĩa như trên đã đề cập, có vẻ như đây là một sự chơi chữ tinh tế, nhưng thực chất, nó tạo nên một sự khác biệt quan trọng trong công việc của bạn.
Đứng về khía cạnh tâm lý, con người thường có xu hướng tập trung vào vào một muc tiêu nào đó. Nếu mục tiêu của chúng ta là chứng mình rằng “lỗi không xuất hiện trong chương trình”, chúng ta sẽ vô thức hướng tới mục tiêu này. Chúng ta sẽ có xu hướng chọn ra những test data có khả năng thấp gây ra lỗi chương trình. Nhưng nếu mục tiêu là để “tìm ra lỗi”, chúng ta sẽ sử dụng những test data có khả năng cao hơn giúp tìm ra lỗi. Như vậy, với mục tiêu thứ hai, testing đã mang lại nhiều giá trị hơn mục tiêu đầu tiên.
Vấn đề thứ hai với định nghĩa như là “Testing là quá trình chứng minh rằng lỗi không xuất hiện trong chương trình” là điều không thể đối với hầu hết các chương trình, kể cả với những chương trình nhỏ.
Một lần nữa, các nghiên cứu tâm lý đã chỉ ra rằng, con người thường làm việc kém đi khi họ được yêu cầu thực hiện một công việc mà theo họ là không thể làm được. Ví dụ, nếu bạn được yêu cầu giải đố ô chữ trên tờ New York Times trong 15 phút (ô chữ của New York Times rất nổi tiếng và được ưa chuộng, thông thường là ô chữ 15×15, các số vào Chủ nhật là ô chữ 21×21), chúng ta sẽ hầu như không thu được kết quả gì sau 10 phút vì hầu hết chúng ta sẽ bỏ cuộc khi cho rằng việc này là không thể. Tuy nhiên, nếu bạn được yêu cầu làm việc này trong 4 giờ, có thể chúng ta sẽ có kết quả nhất định sau 10 phút. Định nghĩa về testing như một quá trình “tìm ra lỗi” có trong chương trình khiến nó trở thành một nhiệm vụ có-thể-thực-hiện-được, do đó vượt qua khỏi vấn đề về tâm lý.
Vấn đề thứ ba với định nghĩa kiểu: “Mục đích của testing là chỉ ra rằng chương trình đã làm những gì nó phải làm” là thực tế, một chương trình làm đúng những gì yêu cầu vẫn có thể có lỗi. Nhưng lỗi cũng xuất hiện khi chương trình không làm đúng như mong muốn. Hoặc khi chương trình làm những việc không được yêu cầu, lỗi cũng có thể tồn tại. Chúng ta sẽ nhìn nhận sâu sắc hơn về lớp lỗi nếu chúng ta xem xét việc kiểm thử chương trình là một quá trình tìm lỗi hơn là một quá trình chứng minh rằng một chương trình sẽ làm đúng những điều mà nó được yêu cầu.
Tóm lại, kiểm thử chương trình nên được nhìn nhận một cách thích hợp là quá trình tìm ra những lỗi tiềm tàng (mà mình giả định là tồn tại) trong một chương trình. Đương nhiên, bạn cũng muốn sử dụng kiểm thử chương trình để thiết lập mức độ tin cậy cho việc chương trình sẽ làm đúng những việc mà nó phải làm và không làm những việc mà nó không nên thực hiện, nhưng mục đích này chỉ đạt được tốt nhất sau khi đã được kiểm tra kỹ càng để tìm ra lỗi.

No comments:

Post a Comment

The Ultimate XP Project

  (Bài chia sẻ của tác giả  Ryo Amano ) Trong  bài viết  số này, tôi muốn viết về dự án phát triển phần mềm có áp dụng nguyên tắc phát triển...