Nếu chạy một dự án sử dụng BDD với độ bao phủ 100% các câu chuyện của người dùng với các thử nghiệm chấp nhận tự động, vai trò của người kiểm tra / người đảm bảo chất lượng sẽ là gì?
Tôi đoán tôi đang tưởng tượng rằng các nhà phát triển sẽ viết các bài kiểm tra chấp nhận kết hợp với chủ sở hữu sản phẩm, cho tôi biết nếu đó có vẻ như là một giả định ngu ngốc.
Câu trả lời:
Có thể tôi đã quá lỗi thời, nhưng ngay cả những kỹ thuật phát triển hoặc xử lý hiện đại nhất cũng không thể thay thế một đôi mắt khác, đôi mắt mới, trước khi phát hành sản phẩm cho khách hàng của bạn.
Ngay cả khi sản phẩm của bạn chỉ đơn giản là API cho nhà phát triển khác, bạn có thể sử dụng QA để suy nghĩ với tư cách là người dùng API, cung cấp các kịch bản kiểm tra / sử dụng mà bạn hoặc khách hàng của bạn không nghĩ trước.
Nếu sản phẩm của bạn nặng nề dựa trên giao diện người dùng, chắc chắn bạn muốn một người khác (không phải bạn hoặc ai đó trong nhóm của bạn) tìm đến kết quả cuối cùng trước khi gửi cho khách hàng.
Giống như bất kỳ từ thông dụng nào khác trong ngành của chúng tôi, BDD - thậm chí với độ bao phủ 100% - không phải là viên đạn bạc .
Bảo hiểm 100% không giống như 100% được thử nghiệm.
Tôi thấy một người QA trong dự án ATDD là người sẽ giúp viết các bài kiểm tra và thực hiện các loại thử nghiệm khác vẫn còn tồn tại. Tức là kiểm tra giao diện người dùng, kiểm tra phá hủy và kiểm tra tải / căng thẳng.
Nhưng tôi chưa bao giờ thực hiện một dự án ATDD.
Công việc của QA là phá vỡ ứng dụng, công việc của nhà phát triển là không phá vỡ nó. Vì vậy, họ viết bài kiểm tra của họ từ một quan điểm khác nhau. Chẳng hạn, các nhà phát triển viết các bài kiểm tra để xem liệu hành vi dự kiến có xảy ra hay không, QA viết các bài kiểm tra để xem điều gì xảy ra khi người dùng làm điều gì đó mà nhà phát triển sẽ không bao giờ nghĩ người dùng sẽ làm. Hơn nữa, các nhà phát triển thường hiểu sai các yêu cầu và các bài kiểm tra QA sẽ nắm bắt khi cách giải thích của họ khác với ý nghĩa của nhà phát triển và sau đó kết hợp với các bên liên quan của dự án để xác định đó là cách giải thích chính xác. Các thử nghiệm được viết bởi các nhà phát triển đã viết mã thường có điểm mù lớn vì nhà phát triển có điểm mù lớn. Ví dụ, nó có thể kiểm tra những gì xảy ra 97% thời gian nhưng không phải là trường hợp cạnh.
Ở một chủ nhân trước đây, vai trò của QA là không kiểm tra sản phẩm nhưng để đảm bảo các nhà phát triển về cơ bản đã làm những gì họ nói họ sẽ làm liên quan đến các thử nghiệm chấp nhận được xác định trước đó được xác định bởi QA.
Mặt khác, chủ sở hữu sản phẩm hoàn toàn không liên quan gì đến việc thử nghiệm. Đối phó với thử nghiệm ở mọi cấp độ IMHO không phải là vai trò của chủ sở hữu sản phẩm.
Đến một lúc nào đó bạn phải có niềm tin vào nhân viên của mình; kiểm tra và cân bằng là tốt nhưng bạn không cần phải đưa ra giải pháp trong chu kỳ phát triển mà thực tế là chỉ giải quyết một tập hợp nhỏ về đạo đức làm việc của nhân viên.
Trong một thế giới hoàn hảo, tôi thấy sự hợp tác với dev và QA chính thức hóa bằng cách viết các bài kiểm tra chấp nhận theo cách thức chung. QA sẽ mang lại một khía cạnh khác cho bảng cũng như nhóm phát triển. QA nên đặt tay vào chiếc bánh ở giai đoạn trứng của sản phẩm và tiếp tục tham gia trong toàn bộ chu trình. Mặt khác, chủ sở hữu sản phẩm nên tham gia QA để hiểu về tình trạng hiện tại của sản phẩm, rủi ro, v.v ... và tập trung vào sản phẩm một cách toàn diện; không phải là những sắc thái cụ thể tạo nên sản phẩm.
Từ kinh nghiệm của tôi: Chúng tôi đã sử dụng thử nghiệm Đơn vị để bao phủ hơn 90% mã. Ngoài ra còn có các bài kiểm tra tích hợp và xây dựng hàng giờ. xét nghiệm jBehave cho BDD.
Vai trò QA: - chấp nhận các câu chuyện của người dùng để thử nghiệm - viết mã phía sau các bước - thử nghiệm thăm dò bằng cách sử dụng trình cắm RestClient cho IDEA (do đó chúng tôi đã tìm thấy một số lỗi lớn)
Một phần của BDD đang áp dụng phương pháp 3 Amigos nơi các bên liên quan hợp tác để đưa ra các tiêu chí chấp nhận. QA / Dev có thể viết mã bước để thực hiện các kịch bản dưới dạng thử nghiệm chấp nhận. Đâu là giá trị của QA để thực hiện thủ công các thử nghiệm chấp nhận tương tự mà công cụ BDD sẽ tự động thực hiện? Giá trị gia tăng của QA là để xác nhận các thử nghiệm chấp nhận đó và thực hiện thử nghiệm thăm dò thủ công bên ngoài các thử nghiệm chấp nhận theo kịch bản. Sao chép thường sẽ mang lại kết quả tương tự.
Các nhà phát triển không viết lại các yêu cầu và thông số kỹ thuật, QA không viết lại mã ứng dụng ... QA có thể không phải thực hiện các thử nghiệm theo kịch bản giống nhau mà các nhà phát triển thực hiện như các thử nghiệm chấp nhận. Đã đến lúc Devs phải đội một vài chiếc mũ QA!