Là kiểm thử phần mềm thực sự được thực hiện trên các dự án chuyên nghiệp?

Tôi đã tham gia vào nhiều dự án ở một số công ty vì tôi đã là nhà phát triển trong một thời gian dài và tôi là một nhà thầu.

Tôi ước tính rằng ít hơn 20% các dự án được thử nghiệm một cách có phương pháp. Với thử nghiệm có phương pháp, tôi có nghĩa là bất kỳ thử nghiệm nào ngoài quảng cáo không có kế hoạch thử nghiệm.

Tôi cũng ước tính rằng ít hơn 10% dự án được kiểm tra kỹ lưỡng về phương pháp trong đó họ có người kiểm tra chuyên dụng như một phần của nhóm, tài liệu kế hoạch kiểm tra, nơi các nhà phát triển viết bài kiểm tra tự động và sau đó họ cũng theo dõi phạm vi kiểm tra và đo lường kết quả.

Hai câu hỏi

1. Ước tính tỷ lệ phần trăm của bạn về vấn đề này là gì?
2. Kinh nghiệm chuyên môn của bạn về kiểm thử phần mềm là gì?

Ghi chú bổ sung

Vì câu hỏi kiểm tra phương pháp có thể nhận được câu trả lời khá thiên vị (mọi người thích khoe khoang về việc vượt trội so với người khác), tôi khuyến khích các nhà phát triển khác (những người không tiếp xúc với thử nghiệm có phương pháp) cũng cung cấp câu trả lời của họ, bởi vì nếu không thì sẽ giống như thử nghiệm được thực hiện ở mọi nơi ... ngoại trừ tại công ty của bạn.

Mô hình mà tôi đã thấy với thử nghiệm trong sự nghiệp của mình cho thấy sự tương ứng mạnh mẽ với nguy cơ thất bại trong một dự án. Các dự án lớn có nhiều khả năng được thử nghiệm hơn các dự án nhỏ, các ứng dụng quan trọng có khả năng được thử nghiệm nhiều hơn một trang web tiếp thị, trong các hệ thống nội bộ ít có khả năng được thử nghiệm hơn các ứng dụng công khai.

Điều đó nói rằng vẫn có những dự án đã được thử nghiệm quá mức và những dự án chưa được thử nghiệm đủ, nhưng đây là những dự án thiểu số.

Tất cả mọi thứ chúng tôi sản xuất được kiểm tra hoàn toàn. Nếu nhóm QA nội bộ của chúng tôi bị quá tải, chúng tôi có một nhóm ở nước ngoài kiểm tra các dự án. Họ không giỏi như nhóm nội bộ của chúng tôi nhưng đó là một chủ đề khác.

Ba công ty tôi đã làm việc trong 15 năm qua đều có các bài kiểm tra đơn vị được chạy tự động.

Tại hai trong số những công ty đó, tôi đã cố gắng giới thiệu họ.

Trong 9 năm qua, về cơ bản tôi chỉ đáp ứng các bài kiểm tra chấp nhận / hồi quy. Chỉ có một vài bài kiểm tra đơn vị.

Vâng.

Số lượng thử nghiệm tỷ lệ thuận với độ tin cậy cần thiết của ứng dụng, cũng như sự trưởng thành của văn hóa lập trình viên.

Các trang web khá thường xuyên đi bộ lỗ hổng (liên kết bị hỏng là một khiếm khuyết).

Trò chơi video thường có lỗi.

Windows (cuối cùng) là khá đáng tin cậy.

Bộ định tuyến rất đáng tin cậy

Giám sát bệnh viện "không phá vỡ"

Lưu ý rằng chi phí tài chính của sự thất bại cũng tương quan với độ tin cậy.

Trong 10 năm tôi chưa bao giờ làm việc trong một dự án với thử nghiệm mã chính thức.

Trong công việc hiện tại của tôi, chúng tôi chỉ có thử nghiệm chức năng.

Vấn đề là không ai trong ban quản lý thậm chí biết về kiểm tra mã. Bộ phận kiểm tra thậm chí không biết về kiểm tra mã, họ chỉ tuân theo thông số kỹ thuật cấp cao và xác minh nếu chúng tôi tuân thủ theo quan điểm hành vi / chức năng.

Chúng tôi không có một nhà lãnh đạo phần mềm đủ điều kiện buộc chúng tôi phải viết mã tốt. Kết quả là mã spaghetti, rất nhiều hồi quy, lịch trình bị bỏ lỡ và vv ...

Chúng tôi là một công ty nước ngoài cỡ vừa ở Nam Á. Tuy nhiên, chúng tôi luôn thực hiện các dự án tại Hoa Kỳ và trực tiếp làm việc với các yêu cầu được gửi từ công ty Hoa Kỳ.

Chúng tôi áp dụng thử nghiệm phương pháp trên mọi ứng dụng chúng tôi xây dựng. Có lẽ, chất lượng thử nghiệm không đạt tiêu chuẩn, nhưng chúng tôi sử dụng chúng.

Nhiều như người theo chủ nghĩa thuần túy trong tôi không muốn chấp nhận rằng phải có một số quản lý rủi ro được đưa ra trong quyết định về việc bạn kiểm tra nghiêm ngặt như thế nào hoặc liệu bạn có thực hiện kiểm tra chính thức hay không. Đối với các ứng dụng nội bộ, mà tôi nghi ngờ là một phần lớn các dự án lập trình, chi phí phát hành lỗi sau đó nhanh chóng vá nó sau khi nhận thấy đôi khi có thể vượt quá chi phí của một nhóm thử nghiệm đầy đủ. Tất nhiên nó phụ thuộc vào ứng dụng và chi phí thất bại tiềm năng.

Điều đó nói rằng, tôi không nghĩ rằng lập kế hoạch quản lý rủi ro là lý do cho việc thiếu thử nghiệm chính thức. Tôi nghĩ rằng đó là kết quả của việc các nhà quản lý phi kỹ thuật không hiểu được giá trị mà nó cung cấp và chỉ nhìn thấy chi phí.

Mẫu của tôi rất nhỏ để suy ra tỷ lệ phần trăm từ, nhưng dù sao đi nữa.

Một trong số đó là một công ty chip + phần mềm không chuyên, đã thực hiện thử nghiệm cuồng tín. Kiểm tra tự động 24/7 trên hàng chục cài đặt, mỗi lần kiểm tra hàng chục đơn vị. Các nhóm phần mềm chuyên phát triển phần mềm thử nghiệm. Đội phần cứng dành riêng để xây dựng giàn thử nghiệm. Kiểm tra khả năng tương thích chống lại hàng chục đối thủ cạnh tranh. Heck, họ thậm chí đã mua một cài đặt thử nghiệm chip trị giá hàng triệu đô la để phát triển và gỡ lỗi một số thử nghiệm mà các fab chạy khi các chip rời khỏi xưởng đúc.

Một số khác là một ngân hàng. Đây là một môi trường hoàn toàn khác: không phát hành sản phẩm, nhưng rất nhiều phần mềm nội bộ để tiếp tục chạy liên tục. Những người này đã thử nghiệm cr * p trong mỗi thay đổi mà họ đã thực hiện. Họ đã phân tách rất nghiêm ngặt các môi trường DEV / QA / PROD, kiểm tra hồi quy tự động, kiểm tra QA bắt buộc được ký bởi người dùng cuối trước khi phát hành vào sản xuất, v.v.

Vì vậy, yeah, mọi người làm thử nghiệm phương pháp. Nhưng như bạn có thể nói tôi chưa bao giờ làm việc tại một nơi vận chuyển phần mềm GUI điển hình của bạn cho người dùng máy tính thông thường.

Tôi hiện đang viết firmware nhúng cho một công ty khởi nghiệp nhỏ chế tạo các thiết bị y tế không dây. Chúng tôi được yêu cầu thực hiện kiểm tra nghiêm ngặt và có một bộ phận chất lượng hoàn toàn riêng biệt do một người báo cáo trực tiếp cho CEO. Tôi chưa bao giờ có mã của mình được kiểm tra kỹ lưỡng trước đó bởi những người thử nghiệm riêng biệt (lần duy nhất so sánh, là khi tôi làm việc trên các hệ thống truyền hình vệ tinh khoảng 15 năm trước.)

Kết quả kiểm tra của chúng tôi đã được đệ trình lên FDA (cho đến nay chúng tôi đã nhận được hai thông tin rõ ràng của FDA - mỗi lần gửi dài khoảng 500 trang). Cả phương pháp phát triển và thử nghiệm của chúng tôi đều phải kiểm toán định kỳ.

Vì vậy, không chỉ các công ty lớn thực hiện nhiều thử nghiệm chính thức.

Lưu ý - trong hơn 25 năm lập trình / tư vấn hợp đồng, tôi cũng đã làm việc cho nhiều công ty hầu như không có thử nghiệm chính thức. Hầu hết trong số họ không còn ở xung quanh nữa.

Hầu như mọi công ty tôi đã được thử nghiệm có phương pháp. Công ty hiện tại của tôi có một số bài kiểm tra kiểu đơn vị cơ bản và điều đó là không đủ. Chúng tôi đã có một số vấn đề chất lượng do điều này. Tôi đặc biệt khuyên bạn nên thử nghiệm kỹ lưỡng độc lập trên bất kỳ dự án nào sẽ được sử dụng bởi bất kỳ ai ngoài chính bạn. Số tiền bỏ ra sẽ rất xứng đáng. Các ứng dụng không hoạt động không được sử dụng. Điều đó đi cho đối mặt nội bộ cũng như đối mặt với bên ngoài.

Trong hai mươi năm gần đây trong sự nghiệp của tôi thông qua tám công ty, tôi chưa bao giờ làm việc trong một dự án không thử nghiệm. Số lượng thử nghiệm khác nhau ở mỗi công ty, nhưng mỗi dự án phát triển chuyên nghiệp mà tôi từng làm đã thực hiện thử nghiệm chính thức. Điều này áp dụng như nhau cho cả các công ty vừa và nhỏ (trong đó "nhỏ" có nghĩa là dưới 10 nhân viên và "cỡ trung bình" có nghĩa là vài nghìn nhân viên trở xuống).

Một số công ty không có nhiều thử nghiệm tự động, một số công ty không có nhiều thử nghiệm thủ công, nhưng họ có ít nhất cái này hoặc cái kia.

Nó phụ thuộc vào nhu cầu của khách hàng. Trong một tình huống hợp đồng có thể có các bài kiểm tra chấp nhận. Trong nhà thường là một slapjob với ít thử nghiệm. Các công cụ tiêu dùng thường được bao phủ cao trong chức năng thường xuyên nhưng thô ráp xung quanh các cạnh.

Câu trả lời ngắn gọn: Có

Câu trả lời dài:

1. Tôi không có ước tính tốt cho danh mục đầu tiên (có thể là khoảng cách từ 0, nhưng bao nhiêu?), Nhưng kinh nghiệm của tôi thực sự chứng thực với ước tính thứ hai của bạn. Thật khó để đưa ra tỷ lệ phần trăm có ý nghĩa vì số lượng và loại thử nghiệm phụ thuộc vào loại ứng dụng được phát triển, khung thời gian có sẵn cũng như kỹ năng của các nhà phát triển và cách thức chạy dự án. Trong thực tế, rào cản quan trọng nhất đối với các nhà phát triển sẽ là thử nghiệm chấp nhận vì đó là một cột mốc quan trọng cho mục đích thanh toán. Nhưng đó cũng là lúc điều bất ngờ có thể xảy ra (nhiều yêu cầu hơn) và các nhà phát triển có thể bị áp lực phải giao và nhận bằng bất kỳ thử nghiệm adhoc nào có thể và kịp thời (ở giai đoạn này), trên hết thời gian cần thiết để khắc phục sự cố và khắc phục những điều bất ngờ

2. Tôi đã trải qua một loạt các dự án với sự kết hợp khác nhau của các yếu tố được đề cập ở trên:

   • không có bài kiểm tra đơn vị chính thức, chỉ có bài kiểm tra tích hợp và chủ yếu là bài kiểm tra adhoc

   • rất chính thức, từ kiểm tra đơn vị đến các kế hoạch kiểm tra chi tiết liên quan đến tài nguyên QA chuyên dụng, kiểm tra tự động (được thực hiện bởi những người kiểm tra với bộ công cụ của riêng họ) và báo cáo bảo hiểm mã. Nhưng những điều này không phải lúc nào cũng có ý nghĩa đối với các nhà phát triển cũng như đối với các nhà quản lý

Ở cấp độ cá nhân, tôi tìm cách duy trì sự hiểu biết về các lựa chọn của mình khi viết các bài kiểm tra phù hợp với công nghệ tôi đang xử lý và thực hiện chúng theo ý của tôi. Về cơ bản, những điều thực sự có ý nghĩa và có lợi cho công việc của tôi, và không quá nhiều số.