QA để tỷ lệ dev

Question

Chúng tôi có một hệ thống Java khá phức tạp bao gồm một vài tầng sau bao gồm cơ sở dữ liệu và đầu cuối Swing độc quyền. Có các API back-end mà bên ngoài có thể đính kèm mà bắt chước front-end của chúng tôi. Có khoảng 5 silo trong tổ chức của chúng tôi chia sẻ hệ thống này. Tổng cộng có khoảng 15 nhà phát triển duy trì hệ thống này.

Có quy tắc nào về kích thước mà nhóm QA của chúng tôi nên có không?

Edit: Để thêm một chút về bối cảnh dựa trên các câu hỏi được nêu ra trong các câu trả lời như vậy, cho đến nay:

1. Chúng tôi có khoảng bốn phát hành chính một năm, và một loạt các shortcut nhỏ ở giữa.
2. Nền tảng của chúng tôi có tiền thay đổi tay, do đó, có những con số có ý nghĩa rất nhiều đối với khách hàng của chúng tôi.
3. Chúng tôi sử dụng hệ thống kiểm soát lỗi chính thức.
4. Chúng tôi không sử dụng TDD.
5. Chúng tôi sử dụng các công cụ như cruisecontrol để tích hợp liên tục.

Answer 1

Là một trưởng nhóm thử nghiệm cũ, tôi khuyên bạn nên thử nghiệm càng nhiều càng tốt. Có vẻ như rất nhiều người trong tổ chức của bạn phụ thuộc vào phần mềm của bạn. Kiểm tra sớm và kiểm tra thường xuyên.

Điều quan trọng là phải nhận ra rằng thử nghiệm là trách nhiệm của mọi người. Các nhà phát triển cần phải viết các bài kiểm tra đơn vị tốt. Các nhà phát triển UI nên được kiểm tra thủ công giao diện người dùng.

Tôi cố gắng khuyến khích phát triển thử nghiệm, theo dõi số liệu (sử dụng hệ thống theo dõi lỗi chính thức, theo dõi tỷ lệ lỗi, vv), thiết lập dịch vụ tích hợp liên tục và mã thiết kế để kiểm tra (sử dụng khung như Spring for dependency) tiêm, sử dụng mocks và sơ khai cho các dịch vụ bên ngoài, vv - Tôi rất vui được thảo luận chi tiết hơn).Chi phí sửa chữa một lỗi được đắt hơn theo cấp số nhân sau này bạn tìm thấy nó, vì vậy nó tốt nhất được tìm thấy trước khi nó được chính thức QA.

Jeff

Answer 2

Có thể phụ thuộc vào mức độ liên quan của cơ sở mã (cho dù có nhiều mô-đun tích hợp) và trải nghiệm người dùng (nếu có nhiều yếu tố hình ảnh và kiểm soát đầu vào để kiểm tra).

Nếu đó là một hệ thống khá phức tạp, bạn có thể xem xét 2-3 kỹ sư QA cho mỗi 5 nhà phát triển. Tuy nhiên, nếu các tính năng không thực sự thay đổi nhiều hoặc ít tham gia hơn, tôi sẽ nghĩ bạn có thể lấy đi chỉ với 1 QA cho mỗi 5 nhà phát triển (thậm chí có thể cho mỗi 10 nhà phát triển).

Answer 3

Không, không có quy tắc nào. Mọi tổ chức đều khác nhau, vì mọi tổ chức đều có một bộ hoàn toàn khác nhau về yêu cầu, nhu cầu, dự án, v.v. Bạn chỉ có thể tìm thấy cái gì phù hợp với tổ chức của bạn.

Answer 4

Bắt đầu với 1 QA đến 5 hoặc 6 nhà phát triển. Sau đó, bắt đầu tinh chỉnh nó tùy thuộc vào công việc bạn nghĩ QA phải làm gì hoặc không có gì để làm.

Sự thật, điều đó chỉ dựa trên kinh nghiệm của riêng tôi vì có quá nhiều yếu tố liên quan. Làm thế nào phát triển hoặc ổn định là codebase của bạn? Nó lớn bao nhiêu? Kiểm tra toàn diện cần phải như thế nào? Loại công cụ kiểm tra và phân tích nào có liên quan? Tần suất phát hành mốc là bao nhiêu? Bạn có loại quy trình phát triển nào? Thử nghiệm thủ công và thử nghiệm tự động bao nhiêu?

Còn rất nhiều câu hỏi khác. Vì vậy, chỉ cần bắt đầu với một số tùy ý và đi từ đó.

Answer 5

Tỷ lệ QA hợp lý để dev chỉ có thể được bắt nguồn so với độ phức tạp của ứng dụng được đề cập.

Rõ ràng, một nhà phát triển có thể có thể đưa ra một ứng dụng phức tạp, trong đó chỉ có 3 QA toàn thời gian có thể kiểm tra hiệu quả do sự phức tạp của quy trình làm việc; lần lượt, có thể có 1 QA cho 3 nhà phát triển trẻ kết nối với nhau một ứng dụng báo cáo đầu vào-đầu ra tương đối đơn giản.

Vì vậy, số lượng nhân viên QA bạn cần sẽ được xác định bởi số lượng và độ phức tạp của các yêu cầu bạn có, chứ không phải số lượng nhà phát triển phần mềm bạn sử dụng.

Answer 6

Tôi không biết liệu quan điểm của anh ấy có thay đổi kể từ this article 9 năm trước hay không, nhưng Joel sẽ đề xuất 1 người QA toàn thời gian cho mỗi 2 người phát triển toàn thời gian. Tôi muốn nói, với một hệ thống không ngừng phát triển, với những cập nhật thường xuyên, tỷ lệ này khá tốt.

Sau đó, một lần nữa, nếu hệ thống của bạn không thay đổi thường xuyên, hiếm khi cập nhật, tại sao bạn có nhiều nhà phát triển để bắt đầu? Tôi đã cố gắng thuyết phục bản thân rằng tỉ lệ 1: 2 là tỷ lệ hoàn hảo trong hầu hết mọi tình huống. :)

Answer 7

2 kỹ sư kiểm tra trên 3 nhà phát triển là một khởi đầu tốt. Nếu nhiều trường hợp kiểm tra liên quan đến các công cụ không thể tự động (các công cụ cắm/rút vật lý, xác minh hình ảnh của giao diện người dùng), hãy thêm 1 người thử nghiệm trên 2 kỹ sư kiểm tra.

Answer 8

Rất nhiều tùy thuộc vào hệ thống làm gì và hậu quả của lỗi là gì? Bạn đang viết phần mềm tài chính? Hoặc mạng xã hội? Chi phí có khả năng của một thất bại lớn hơn giá trị khác nên nỗ lực QA thay đổi. Tương tự nếu đó là một sản phẩm (với nhiều cơ sở người dùng được cài đặt có thể khó vá hơn), bạn cần nó ổn định hơn nếu nó là nội bộ.

Bạn cũng cần hỏi là bạn đang mong đợi họ thực hiện kiểm tra hệ thống cơ bản hoặc khối lượng và thử nghiệm tải quá. Có vẻ như bạn đang xem xét kết hợp kiểm tra giao diện người dùng và thử nghiệm API.

Cho bạn biết điểm khởi đầu, giả sử rằng bạn đang nói một loại hệ thống "bình thường" và chúng tôi đang nói thử nghiệm hệ thống cơ bản, số liệu tôi muốn đi là 33% nỗ lực phải là nỗ lực kiểm tra . Về lý thuyết, điều này cho bạn tỷ lệ 1 đến 2 nhưng giả sử rằng các nhà phát triển của bạn là đơn vị thử nghiệm có thể kéo dài đến 1 đến 3. Chắc chắn tôi hiện đang chạy với 1 đến 4 và điều đó là không đủ (tôi sẽ sửa chữa nó ngay khi doanh nghiệp cho phép tôi).

Nhưng bạn cũng muốn xem xét mức độ trưởng thành của quy trình phát triển phần mềm và các thông số kỹ thuật của bạn như thế nào. Cũng như có số lượng người thử nghiệm phù hợp, bạn cần cung cấp cho họ thông tin phù hợp để kiểm tra - nếu họ không có điều đó thì họ sẽ không thể thực hiện công việc và được cho là lãng phí tiền bạc.

Một tùy chọn khác để ném vào đó - có vẻ như sản phẩm đã được phát triển trong một thời gian. Cũng như cốt lõi của những người thử nghiệm thường xuyên, bạn có thể muốn tăng số lượng lớn cho một thử nghiệm chính ban đầu bằng cách sử dụng các nhà thầu ngắn hạn. Nếu bạn chỉ đang mang tài nguyên thử nghiệm vào thì bạn không muốn bắt đầu với một phần lớn tồn đọng.