Có tốt không khi những người thử nghiệm đang cạnh tranh để xem ai mở ra nhiều lỗi hơn?

Tôi là một nhà phát triển phần mềm. Có một nhóm những người thử nghiệm theo dõi và chạy các trường hợp thử nghiệm được viết bởi nhà phân tích, nhưng cũng thực hiện thử nghiệm thăm dò. Có vẻ như những người thử nghiệm đã cạnh tranh để xem ai mở ra nhiều lỗi hơn và tôi nhận thấy rằng chất lượng báo cáo lỗi đã giảm. Thay vì kiểm tra chức năng và báo cáo các lỗi liên quan đến hoạt động của phần mềm, những người kiểm tra đã gửi các lỗi về cải tiến màn hình, khả năng sử dụng hoặc các lỗi ngu ngốc.

Điều này có tốt cho dự án không? Nếu không, làm thế nào tôi (với tư cách là nhà phát triển phần mềm), cố gắng thay đổi suy nghĩ và thái độ của đội ngũ kiểm thử viên?

Một vấn đề khác là vì thời hạn được ước tính và không thể thay đổi, vì vậy khi thời hạn gần đến, những người kiểm tra sẽ tranh giành để hoàn thành các trường hợp kiểm tra của họ và điều này sẽ làm giảm chất lượng của các bài kiểm tra. Điều này sẽ gây ra lỗi hợp pháp trong sản phẩm cuối cùng mà khách hàng nhận được.

OBS: Cuộc thi này không phải là thông lệ của công ty! Đó là một cuộc cạnh tranh giữa chỉ những người thử nghiệm do họ tổ chức, và không có bất kỳ giải thưởng nào.

Tôi không nghĩ rằng thật tốt khi họ thực hiện một cuộc thi tìm ra nhiều lỗi nhất. Mặc dù đúng là công việc của họ là tìm lỗi, nhưng công việc của họ không phải là "tìm ra nhiều lỗi nhất ". Mục tiêu của họ không phải là tìm kiếm nhiều nhất, mục tiêu của họ là giúp cải thiện chất lượng của phần mềm. Thưởng cho họ khi tìm thấy nhiều lỗi cũng giống như thưởng cho một lập trình viên vì đã viết hầu hết các dòng mã, thay vì mã chất lượng cao nhất.

Biến nó thành một trò chơi mang lại cho họ một động lực để tập trung vào việc tìm kiếm nhiều lỗi nông, thay vì tìm ra các lỗi nghiêm trọng nhất. Như bạn đã đề cập trong phần chỉnh sửa của mình, đây chính xác là những gì đang diễn ra trong tổ chức của bạn.

Người ta có thể lập luận rằng bất kỳ lỗi nào họ tìm thấy là trò chơi công bằng và tất cả các lỗi cần phải được phát hiện. Tuy nhiên, do nhóm của bạn có khả năng có nguồn lực hạn chế, bạn muốn một người kiểm tra tập trung vài giờ hoặc vài ngày vào sâu trong hệ thống của bạn để cố gắng tìm ra các lỗi thực sự lớn hoặc dành vài giờ hoặc vài ngày lướt qua ứng dụng để tìm lỗi đánh máy và nhỏ lỗi trong sự liên kết của các đối tượng trên một trang?

Nếu công ty thực sự muốn tạo ra một trò chơi từ đó, hãy cung cấp cho các nhà phát triển sức mạnh để thêm điểm vào một lỗi. "lỗi ngu ngốc" nhận được điểm tiêu cực, khó tìm thấy lỗi với các báo cáo được viết tốt sẽ nhận được nhiều điểm. Điều này sau đó chuyển động cơ từ "tìm ra nhiều nhất" sang "trở thành người giỏi nhất trong công việc của bạn". Tuy nhiên , điều này cũng không được khuyến khích, bởi vì một lập trình viên và nhà phân tích QA có thể làm việc cùng nhau để làm giả số của họ.

Điểm mấu chốt: đừng tạo ra một trò chơi tìm lỗi. Tìm cách trong tổ chức của bạn để thưởng cho công việc tốt và để nó ở đó. Gamification thưởng cho mọi người để đạt được một mục tiêu. Bạn không muốn một nhà phân tích QA có mục tiêu "tìm ra nhiều lỗi nhất", bạn muốn mục tiêu của họ là "cải thiện chất lượng của phần mềm". Hai mục tiêu đó không giống nhau.

Tôi sẽ không đồng ý một chút với các câu trả lời khác. "Tìm lỗi" cho người kiểm tra giống như "viết mã" dành cho nhà phát triển. Số lượng thô là vô nghĩa. Công việc của người kiểm tra là tìm ra càng nhiều lỗi tồn tại mà họ có thể, chứ không phải tìm ra nhiều lỗi nhất. Nếu người kiểm tra A tìm thấy 5 trong số 10 lỗi trong thành phần chất lượng cao và người kiểm tra B tìm thấy 58 trong số 263 lỗi trong thành phần chất lượng thấp, thì người kiểm tra A là người kiểm tra tốt hơn.

Bạn muốn các nhà phát triển viết số lượng mã tối thiểu để giải quyết một vấn đề cụ thể và bạn muốn một người kiểm tra viết ra số lượng báo cáo tối thiểu mô tả chính xác hành vi bị hỏng. Cạnh tranh để tìm ra nhiều khiếm khuyết nhất cũng giống như cạnh tranh để viết nhiều dòng mã nhất. Quá dễ dàng để trượt vào chơi game hệ thống trở nên hữu ích.

Nếu bạn muốn có người kiểm tra để cạnh tranh, thì nên trực tiếp hơn dựa trên những gì họ đang làm, đó là xác nhận rằng phần mềm hoạt động như mô tả. Vì vậy, có lẽ mọi người cạnh tranh để xem ai có thể viết các trường hợp thử nghiệm được chấp nhận nhất, hoặc thậm chí tốt hơn, viết tập hợp các trường hợp thử nghiệm bao gồm nhiều mã nhất.

Thước đo tốt hơn về năng suất của nhà phát triển là số lượng nhiệm vụ hoàn thành thời gian phức tạp của nhiệm vụ. Thước đo tốt hơn về năng suất của người thử nghiệm là số lượng trường hợp thử nghiệm được thực hiện lần độ phức tạp của trường hợp thử nghiệm. Bạn muốn tối đa hóa điều đó, không tìm thấy lỗi.

Dựa trên kinh nghiệm cá nhân của tôi, đây không phải là một điều tốt. Nó hầu như luôn luôn dẫn đến các nhà phát triển nộp các lỗi trùng lặp, lố bịch hoặc hoàn toàn không hợp lệ. Thông thường bạn sẽ thấy rất nhiều trong số này xuất hiện đột ngột vào cuối tháng / quý khi những người thử nghiệm vội vàng đáp ứng hạn ngạch. Về điều duy nhất tồi tệ hơn thế này là khi bạn cũng phạt các nhà phát triển dựa trên số lỗi được tìm thấy trong mã của họ. Các nhóm thử nghiệm và phát triển của bạn đang làm việc với nhau tại thời điểm đó và một người không thể thành công mà không làm cho người khác trông tệ.

Bạn cần phải tập trung vào người dùng ở đây. Một người dùng không biết có bao nhiêu lỗi đã được gửi trong quá trình thử nghiệm, tất cả những gì họ thấy là lỗi đã vượt qua. Người dùng cuối cùng không quan tâm nếu bạn gửi 20 báo cáo lỗi hoặc 20.000, miễn là phần mềm hoạt động khi họ nhận được nó. Một số liệu tốt hơn để đánh giá người kiểm tra sẽ là số lỗi được báo cáo bởi người dùng nhưng điều đó đáng lẽ phải được kiểm tra bởi người kiểm tra.

Điều này là khó khăn hơn nhiều để theo dõi, mặc dù. Thật dễ dàng để chạy một truy vấn cơ sở dữ liệu để xem có bao nhiêu báo cáo lỗi được gửi bởi một người cụ thể, mà tôi nghi ngờ là lý do chính tại sao số liệu "lỗi nộp" được sử dụng bởi rất nhiều người.

Không có gì sai khi làm một trò chơi tìm ra lỗi. Bạn đã tìm thấy một cách để thúc đẩy mọi người. Điều này là tốt Nó cũng tiết lộ một sự thất bại trong việc truyền đạt các ưu tiên. Kết thúc cuộc thi sẽ là một sự lãng phí. Bạn cần sửa các ưu tiên.

Rất ít trò chơi thực sự có một hệ thống tính điểm đơn giản. Tại sao con bọ săn mồi?

Thay vì chấm điểm trò chơi chỉ đơn giản bằng số lỗi bạn cần để cung cấp thước đo chất lượng báo cáo lỗi. Sau đó, cuộc thi ít về số lượng lỗi. Nó sẽ giống như một cuộc thi câu cá. Mọi người sẽ tìm kiếm lỗi lớn sẽ nhận được điểm ưu tiên cao. Làm cho chất lượng của báo cáo lỗi một phần của điểm số. Yêu cầu các nhà phát triển cung cấp cho người kiểm tra phản hồi về chất lượng của báo cáo lỗi.

Cân bằng trò chơi tinh chỉnh không phải là một nhiệm vụ đơn giản, vì vậy hãy chuẩn bị dành thời gian để làm điều này đúng. Nó nên truyền đạt mục tiêu của bạn một cách rõ ràng và nó sẽ rất vui. Nó cũng sẽ là thứ bạn có thể điều chỉnh khi nhu cầu kinh doanh thay đổi.

Tìm lỗi là công việc của họ. Miễn là họ không làm cho mọi thứ trở nên kém hiệu quả hơn (ví dụ, bằng cách mở một lỗi phát ra 10 lỗi chính tả thay vì một vài lỗi trong số đó), điều này khuyến khích họ làm chính xác những gì họ đang làm, vì vậy Tôi không thể thấy nhiều nhược điểm.

Đây là bản mở rộng về câu trả lời của @ CandiedOrange .

Để bắt đầu chuyển sự chú ý sang các mục tiêu hữu ích hơn, hãy xem xét một cái gì đó rất không chính thức và không chính thức. Ví dụ: các nhà phát triển có thể mua một số mã thông báo và danh hiệu nhỏ.

Mỗi ngày có ít nhất một lỗi đáng kể được báo cáo, hãy để lại mã thông báo "Lỗi trong ngày" trên bàn của người kiểm tra. Mỗi tuần một lần, hãy tổ chức một buổi lễ với đám rước các nhà phát triển cung cấp mã thông báo hoặc cúp "Bug of the Week" lớn hơn và tốt hơn. Làm cho việc trao cúp "Lỗi của tháng" trở nên kịch tính hơn, có lẽ là với bánh. Mỗi mã thông báo hoặc danh hiệu phải được kèm theo một trích dẫn cho biết lý do tại sao các nhà phát triển nghĩ rằng đó là một điều tốt mà lỗi được tìm thấy trong thử nghiệm. Các bản sao của các trích dẫn nên được đặt ở đâu đó nơi người kiểm tra có thể đọc tất cả.

Hy vọng là những người thử nghiệm sẽ chuyển sự chú ý của họ từ việc tìm ra nhiều lỗi nhất sang thu thập các danh hiệu và mã thông báo nhất. Chiến lược tốt nhất của họ để làm điều đó là đọc các trích dẫn và suy nghĩ về cách tiếp cận để kiểm tra có khả năng đưa ra các lỗi mà các nhà phát triển sẽ coi là quan trọng.

Đơn giản chỉ cần bỏ qua các báo cáo lỗi không quan trọng. Vì tất cả sẽ rất không chính thức và không chính thức, nó có thể bị tắt hoặc thay đổi bất cứ lúc nào.

Điều này có tốt cho dự án không?

Không . Chính bạn đã chỉ ra rằng bạn đã quan sát thấy rằng nó dẫn đến các báo cáo chất lượng thấp không nhắm mục tiêu vào chức năng được yêu cầu và người kiểm tra kết thúc, để giải quyết vấn đề, tranh giành để hoàn thành công việc mà họ thực sự "cho là "Để được làm.

Nếu không, làm thế nào tôi (với tư cách là nhà phát triển phần mềm), cố gắng thay đổi suy nghĩ và thái độ của đội ngũ kiểm thử viên?

Đưa ra vấn đề với Quản lý dự án của bạn. Họ nên coi đây là một phần của công việc. Nếu PM của bạn không sẵn lòng hoặc không có khả năng đối phó với nó, bạn sẽ bị mắc kẹt trong việc phát triển các chiến lược đối phó của riêng mình. (đó sẽ là một câu hỏi khác nhau)

Tôi nghĩ nó sẽ như thế nào (hoặc nó đã như thế nào) nếu nó tiếp tục như thế này, bạn sẽ không nhất thiết phải có chất lượng thấp hơn. Al mặc dù tôi nghĩ rằng nó sẽ làm giảm tỷ lệ số lượng chất lượng. Nó phụ thuộc nếu điều này là một điều xấu hay không. Nó phụ thuộc nếu

báo cáo lỗi về cải tiến màn hình, khả năng sử dụng hoặc lỗi ngu ngốc.

là điều bạn thực sự không muốn. Nếu điều này rõ ràng với những người thử nghiệm, tôi sẽ chỉ bảo họ đừng làm những điều bạn không muốn báo cáo mà hãy rõ ràng về nó. Làm điều đó khi một trong những báo cáo đó xuất hiện trở lại.

Lý do họ có một cuộc thi có lẽ là để vui chơi trong khi làm việc, vì vậy họ có thể không có ý định làm việc xấu (nếu điều này được coi là xấu).