Khi nào nên dừng phát triển và QA bắt đầu?

Chúng tôi viết một đặc tả chức năng hoàn chỉnh cho nhóm phát triển của chúng tôi gồm hai. Chúng tôi không có người kiểm tra chuyên nghiệp tuy nhiên chúng tôi đã soạn thảo với sự giúp đỡ của nhân viên bộ phận trợ giúp có sẵn để thực hiện 'Kiểm tra QA'.

Chúng tôi đã có vấn đề trong quá khứ khi các khối chức năng hoàn chỉnh không hoạt động hoặc mã được phân phối đơn giản là không theo thông số kỹ thuật.

Câu hỏi của tôi là: ở giai đoạn nào các nhà phát triển nên ngừng viết mã cho nhóm QA? Có quá nhiều để yêu cầu các nhà phát triển xem xét mã của họ so với thông số kỹ thuật trước khi bàn giao cho nhóm QA không?

Không nên!

Rất khó để làm tất cả các công việc, dừng lại, và sau đó sửa chữa tất cả các vấn đề. Khi bạn đi khắc phục sự cố bạn tìm thấy trong quá trình QA, bạn có thể biết rằng sẽ tốt hơn nếu làm điều gì đó khác đi.

Thay vì nghĩ về mọi thứ như một quá trình bước khóa, hãy cố gắng làm cho nó theo chu kỳ hơn. Mã một số chức năng và kiểm tra nó. Mã thêm một số và kiểm tra nó (và những thứ cũ vẫn hoạt động). Quá trình lỏng hơn này làm giảm bớt con tàu cứng cố gắng tải trước mọi thứ. Bạn vẫn có thể có khái niệm đóng băng mã (chỉ sửa lỗi) khi bạn đến gần thời hạn, nhưng vấn đề là phải kiểm tra sớm và thường xuyên.

Chà, nếu toàn bộ các phần của mã đang được bàn giao cho QA ở trạng thái không hoạt động, có lẽ bạn nên xem xét thêm một số loại thử nghiệm đơn vị / tích hợp vào quy trình của mình. Đừng lạm dụng người QA của bạn bằng cách khiến họ phát hiện ra rằng bạn không thể đơn vị hoặc tích hợp kiểm tra mã của bạn.

Đó là một dòng tốt, bởi vì nếu mã được phân phối theo thông số kỹ thuật thì với tôi điều đó có nghĩa là không có lỗi (và không cần QA!). Thực tế là mã thường không được gửi đến spec là lý do tại sao chúng tôi làm QA ngay từ đầu.

Nhưng tôi thực sự không nghĩ đó là những gì bạn đang nói. Ý bạn là nhóm phát triển có vẻ hơi lười biếng với mã hóa của họ và có những điều rõ ràng lớn dường như không hoạt động. Đặt ra trước khi kiểm tra đơn vị cần phải có mặt cho từng tính năng A, B và C (trong thông số kỹ thuật) và sau đó kiểm tra mã và kiểm tra độc lập (bởi một nhóm nạc hoặc người quản lý) sẽ giúp giảm bớt loại vấn đề này .

Tôi sẽ lập luận rằng ít nhất, các nhà phát triển nên thử nghiệm "con đường hạnh phúc". Rằng nếu họ nhập dữ liệu dự kiến ​​thì nó sẽ làm những gì thông số kỹ thuật cần làm. Các nhà phát triển không làm điều đó nhiều nên được đặt câu hỏi.

Tôi cũng thất vọng nếu một nhà phát triển đã không kiểm tra các trường hợp cạnh rõ ràng: một chuỗi quá dài cho cơ sở dữ liệu, văn bản rõ ràng không hợp lệ, nếu bạn nhập các chữ cái nên có một số, v.v. Nếu điều đó xảy ra thường xuyên, một lần nữa sẽ được hỏi .

Tuy nhiên, giả sử nó không được đề cập cụ thể trong thông số kỹ thuật, nếu nhà phát triển giới hạn tên chỉ là chữ in hoa và chữ thường, nhưng quên rằng một số tên có dấu nháy đơn hoặc cho phép ngày 29 tháng 2 năm 2011 - điều đó dễ hiểu hơn một chút . Trừ khi hết lần này đến lần khác.

Nhóm QA nên chọn các trường hợp cực đoan. Tôi thích QA là người kiểm tra khỉ: chỉ cần nhập rác ngẫu nhiên, xem liệu họ có thể phá vỡ ứng dụng theo cách đó không.

Trong phát triển web, QA nên thử các trình duyệt khác nhau và cố gắng tìm các plugin có thể ảnh hưởng đến mã. Họ nên tắt Javascript và CSS và xem những gì họ có thể thoát khỏi sau đó. Đó là một cách nghĩ. Nếu bạn mong đợi các nhà phát triển làm điều đó, bạn sẽ chi quá nhiều tiền cho nó.

Nếu chức năng được phân phối không hoạt động, thì vấn đề không nằm ở giữa phát triển và QA, mà là giữa phát triển và chủ sở hữu sản phẩm.

Chủ sở hữu và nhà phát triển sản phẩm nên là một phần của cùng một nhóm và nên làm việc cùng nhau để xác định những gì cần làm để xem xét một tính năng "được thực hiện" và để đảm bảo rằng mã đáp ứng nhu cầu đó.

Khi mã được phân phối, kiểm tra phải là một hình thức đơn thuần, bởi vì chủ sở hữu sản phẩm nên đã làm việc với các nhà phát triển trên đường đi để đảm bảo rằng tất cả các trường hợp sử dụng đều được bảo hiểm.

(Nếu bạn có người kiểm tra chuyên nghiệp, họ nên là một phần của nhóm và nên tham gia ở mọi giai đoạn.)

Chúng tôi có một quy trình sàng lọc cho các dự án nơi chúng tôi yêu cầu các nhà phát triển đưa ra hướng dẫn / bản demo mã của họ trước khi đưa vào QA. Chúng tôi không chỉ bao gồm những người kiểm tra QA, mà cả chủ doanh nghiệp về mã, dịch vụ khách hàng và tiếp thị / thiết kế. Điều này có xu hướng tập trung vào các nhà phát triển về ít nhất là các trường hợp sử dụng dễ dàng và đôi khi cuộc thảo luận kết quả giữa các nhóm khác nhau dẫn đến thay đổi thông số kỹ thuật và sự chậm trễ trong việc tham gia QA. Khi có thể, chúng tôi liên quan đến QA sớm hơn nhiều trong quy trình, giúp sửa lỗi trong khi mã vẫn ấm - nhưng chúng tôi vẫn thực hiện hướng dẫn trước khi QA "chính thức" bắt đầu.

Đôi khi tôi đã nói rằng mã không nên được gửi đến QA nếu bạn buồn nếu nó bị chuyển nhầm sang sản xuất thay vì QA. Mã có rối loạn chức năng chính không thuộc về QA (trừ trường hợp cụ thể)