Lại bàn về Whitebox Testing và lí do nó không thực sự được ưa chuộng

White-box Testing, đi cùng với Black-box testing (và đôi khi cả Gray-box Testing nữa) là một trong những khái niệm hay được hỏi nhất trong tất cả các cuộc phỏng vấn đầu vào của QA/Tester. White-box Testing cũng được đánh giá là kĩ thuật test hiệu quả nhất trong tất cả các kĩ thuật testing, tuy nhiên lại nằm trong số những kĩ thuật ít được sử dụng nhất bởi QA/Tester. Tại sao lại như thế nhỉ? Chúng ta lại phải bàn về White-box Testing...

White-box Testing là một phương pháp kiểm thử phần mềm mà Tester phải biết rõ cấu trúc bên trong của phần mềm. Nó còn được gọi là Clear-box Testing, Glass-box Testing, Transparent-box Testing (Kiểm thử trong suốt - Tester nhìn thấy và hiểu thấu cơ cấu code của phần mềm) nhằm tương phản với Black-box Testing (Kiểm thử mù - Tester không thấy cũng không hiểu gì về code bên trong phần mềm). Tất cả các tên gọi này chỉ ra rằng các cơ chế bên trong có thể nhìn thấy đối với Tester. White-box Testing chủ yếu là kiểm tra code và thiết kế hạ tầng của phần mềm. White-box Testing là một phương pháp kiểm tra framework, các thành phần, cơ chế và đối tượng của một ứng dụng.

Đầu tiên, code được xác minh theo các specs ghi trong tài liệu. Khi Tester đã hoàn toàn quen thuộc với cấu trúc bên trong của code, anh ta sẽ chạy các thử nghiệm để kiểm tra xem hệ thống có đáp ứng các yêu cầu được liệt kê trong tài liệu đặc tả hay không. Các thử nghiệm này tập trung vào việc tăng cường an ninh, cải thiện luồng input và output, và cải thiện khả năng sử dụng và thiết kế hệ thống. Nó có thể phát hiện được lỗ hổng ứng dụng. Loại kiểm thử này là phương pháp tốt nhất để tìm ra lỗi trong giai đoạn đầu của vòng đời phát triển phần mềm.

Ở đây, việc tạo ra các testcase là phần quan trọng nhất. Để làm điều này, Tester cần phải có kiến thức nhất định về lập trình. Những testcase này sẽ áp dụng trên mọi dòng code, và chúng sẽ phát hiện tất cả các dị thường có thể xảy ra. Dĩ nhiên, điều quan trọng là Tester biết chính xác chương trình nên làm gì. Chỉ sau đó họ mới xác định xem một chương trình có đang đi sai hướng so với mục tiêu định định trước của nó hay không.

White-box Testing không phải là Automation Testing dù nghe định nghĩa có vẻ rất liên quan. Automation Tester thường chỉ cần biết lập trình căn bản để viết các script ngắn gọn chạy trên bề mặt của phần mềm, trong khi đó White-box Tester cần hiểu rõ cả ngôn ngữ lập trình mà phần mềm sử dụng để đọc hiểu code và thực hiện test từng phần sâu trong hệ thống.

Đây chính là vấn đề: Ai là người sẽ thực hiện White-box Testing? QA/Tester ư? Rất có khả năng, tuy nhiên không phải QA/Tester thuần túy nào cũng có khả năng đọc hiểu code. Không những là đọc hiểu được mục đích của đoạn code, người sử dụng White-box Testing còn phải hiểu không ít những tiêu chuẩn code hay những "ngữ pháp đặc trưng" của ngôn ngữ lập trình cụ thể được sử dụng trong phần mềm mình test. Với phong cách lập trình hiện đại khi mà mỗi phần mềm có thể có sự tham gia của nhiều ngôn ngữ thành phần thì việc White-box Testing toàn bộ phần mềm là gần như bất khả thi đối với QA/Tester. Tuy nhiên, như đã nói ở trên, vì khái niệm White-box Testing luôn được hỏi khi phỏng vấn đầu vào, nên QA/Tester mặc định luôn đó là việc của mình.

Thực tế thì White-box Testing vẫn luôn được sử dụng rất thường xuyên trong tất cả các dự án phần mềm, nhưng người dùng nó thì không biết đến khái niệm White-box Testing, còn người biết khái niệm thì lại rất ít khi dùng. Một thể hiện dễ thấy nhất của White-box Testing có lẽ chính là Unit Testing, một công việc thường xuyên của của Dev. Tuy nhiên, White-box Testing còn bao gồm nhiều thể rộng hơn nữa, không chỉ gói gọn trong một "unit" (1 hàm/function) mà còn test cả một "branch" (1 chuỗi các hàm để thực hiện 1 chức năng cụ thể trong specs) hoặc hẳn một "path" (gần như là một user case hoàn chỉnh). Tất cả những việc này hầu như đều do các Dev đảm nhận. Tức là, nếu Dev họ làm rất tốt White-box Testing thì QA/Tester sẽ thất nghiệp chẳng hạn. May mắn thay, Dev không có đủ thời gian cũng như kiên nhẫn để làm việc đó, còn QA/Tester thì lại không đủ kiến thức và năng lực để làm thay họ. Đó là lí do mà tới tận giờ, White-box Testing vẫn là mảnh đất ít người đặt chân tới.

Sẽ là lí tưởng nếu QA/Tester có thể làm được cả 2 kĩ thuật này, tuy nhiên việc đó không khác gì yêu cầu ai đó có thể vừa bơi như cá lại vừa bay được như chim, nói cách khác là gần như bất khả thi. Bản thân triết lý của 2 kĩ thuật này cũng tương phản nhau như chính tên của chúng: Black-box Testing yêu cầu Tester phải đứng ở viewpoint của End-User trong khi White-box Testing lại cần Tester phải có chuyên môn và tư duy của một coder dày dạn kinh nghiệm.

Về tầm quan trọng, phần lớn các tài liệu trên thế giới đều cho rằng White-box và Black-box Testing ngang ngửa nhau. Ngược lại, mình cho rằng White-box Testing có phần kém quan trọng hơn bởi phần lớn các dự án mình tham gia vẫn sống sót và deliver thành công mà chỉ thực hiện một lượng White-box Testing tối thiểu. Trong khi đó, nếu không có Black-box Testing thì sản phẩm cuối cùng dù có thể rất giống với Specs ban đầu nhưng chưa chắc đã sử dụng được, bởi toàn bộ Non-functional Testing đều nằm trong Black-box Testing, cũng như quan điểm của Black-box Tester là quan điểm của End-User.

Nói vậy không có nghĩa là phủ nhận tính hiệu quả của White-box Testing. White-box Testing là phương pháp tối ưu nhất để tìm kiếm lỗi, dị thường, lỗ hổng trong code từ những giai đoạn đầu tiên của phát triển, giúp rà soát và phát hiện những lỗi tiềm ẩn sâu trong hệ thống để tránh phát sinh ra các incident nghiêm trọng sau này. Bù lại, White-box Testing có chi phí rất lớn, từ chi phí thuê chuyên gia thực hiện đến việc tổ chức các hoạt động review code đi kèm và cũng rất tốn thời gian của Dev nữa. Mà cuối cùng thì nó vẫn không thể gạt bỏ hoàn toàn được Black-box Testing. Dưới bài toán chi phí-hiệu quả như vậy, việc hầu hết các công ty không đề cao White-box Testing cũng là điều dễ hiểu, và QA/Tester cũng không cần quá căng thẳng vì White-box Testing làm gì.