Người kiểm tra có phải xem mã nguồn không?

Làm thế nào cần thiết cho người kiểm tra để thực hiện kiểm tra hộp trắng ngoài kiểm tra hộp đen? Là một nhà phát triển, tôi thấy giá trị khi có một người có tư duy QA đi qua mã của tôi và tìm kiếm các điểm yếu, nhưng cũng có vẻ như nếu một người thử nghiệm phi kỹ thuật đủ kỹ lưỡng và có phương pháp, họ có thể bao quát ứng dụng tốt.

Thử nghiệm hộp trắng có thể cho thấy các trường hợp thử nghiệm quan trọng sẽ không rõ ràng khi chỉ nhìn vào ứng dụng từ góc độ của người dùng, nhưng thử nghiệm hộp đen độc quyền có thể mất ít thời gian hơn và làm tăng đáng kể số người có khả năng thực hiện công việc . Ngoài ra, nhà phát triển nên thực hiện một số lượng thử nghiệm hộp trắng không cần thiết trước khi đến với người thử nghiệm, phải không?

Kiểm thử hộp trắng và kiểm tra hộp đen là hai kỹ năng khác nhau - một người có kỹ năng ở người này không nhất thiết phải có kỹ năng khác.

Rất nhiều điều QA làm sẽ là kiểm tra hộp đen - đảm bảo rằng hệ thống hoạt động "như quảng cáo" và về vấn đề này, họ không cần biết hệ thống hoạt động như thế nào để làm tốt công việc. Trong thực tế kiến ​​thức về mã có thể dẫn họ vào cùng một cái bẫy bắt nhà phát triển bất đắc dĩ thực hiện thử nghiệm của riêng họ. Tốt hơn hết là họ không có định kiến ​​về cách nhà phát triển nghĩ rằng hệ thống được cho là hoạt động.

Điều đó không có nghĩa là không nên thử nghiệm hộp trắng - đó là (một phần) thử nghiệm đơn vị nhà phát triển là gì. Một bộ tốt các bài kiểm tra đơn vị nên được kiểm tra đầu vào hợp lệ, đầu vào không hợp lệ và đầu vào trường hợp cạnh. Tuy nhiên, tôi không nghĩ rằng QA luôn cần thiết phải làm điều này - nếu không vì lý do nào khác ngoài đó thực sự là trách nhiệm của nhà phát triển.

Tuy nhiên, như SnOfus chỉ ra trong nhận xét của mình, việc kiểm tra hộp trắng tốt có thể cực kỳ hữu ích.

Tôi đã có may mắn trong nhóm của mình với các đánh giá mã thử nghiệm. Người kiểm thử có xu hướng xem mã giống như cách họ nhìn vào các ứng dụng - họ tự hỏi, "theo cách nào thì mã này không hoạt động" và thường tìm thấy các vấn đề mà các lập trình viên không tìm thấy trong quá trình xem xét mã.

Để trả lời lâu hơn, tôi đã viết bài báo này .

Chắc chắn rồi

Giống như tôi đã nói khi trả lời @ChrisF: QA có mặt để đảm bảo rằng mã sản xuất hoạt động luôn . Không đầy đủ, điều đó có nghĩa là biết được nền tảng nào được mong đợi, trạng thái của máy được triển khai sẽ là gì, yêu cầu về hiệu năng là như thế nào và chắc chắn rằng mọi dòng sẽ thành công.

IME, một nhóm QA tốt sẽ viết, đọc và xem lại nhiều mã hơn nhóm dev.

Nếu các nhóm tính năng của bạn và các nhóm sửa lỗi (chính) không có nhà phát triển QA trong đó làm việc để thiết kế API, quy trình làm việc, bảo mật và tất cả các khía cạnh khác của tính năng / sửa lỗi, thì bạn thực sự đang bỏ lỡ một thế mạnh bộ phận QA của bạn có thể mang đến sản phẩm của bạn trong khi nó đang được phát triển .

Nó không cần thiết chút nào. Thay vào đó sau đó có một người có tư duy QA đi qua mã của bạn, tôi khuyên bạn nên có một nhà phát triển duyệt mã của bạn. Ngoài ra, nếu bạn đang viết bài kiểm tra đơn vị khi bạn phát triển mã của mình, việc một người có tư duy QA đi qua mã của bạn không phải là cách sử dụng tốt nhất thời gian của QA.

Người QA không nên tập trung vào CÁCH mã được viết, nhưng mã đó làm gì.

Người QA nên tập trung không kiểm tra chức năng và tận dụng các yêu cầu để thực hiện các kiểm tra đó. Cuối cùng, các bài kiểm tra đơn vị và một trình kiểm tra chức năng QA thực hiện kiểm tra hộp đen sẽ là cách sử dụng tốt nhất mọi thời gian của mọi người.