Cách đánh giá chất lượng của sản phẩm phần mềm

Question

Tôi có một sản phẩm, X, mà chúng tôi phân phối cho khách hàng, C hàng tháng, bao gồm sửa lỗi, cải tiến, phát triển mới, v.v.) Mỗi ​​tháng, tôi được yêu cầu "đảm bảo" "chất lượng của sản phẩm.

Đối với điều này, chúng tôi sử dụng một số liệu thống kê thu hút từ các bài kiểm tra mà chúng ta làm, chẳng hạn như:

• mở lại tỷ lệ (số lỗi mở cửa trở lại/số lỗi sửa thử nghiệm)
• tỷ lệ lỗi mới (số mới, bao gồm hồi quy, lỗi được tìm thấy trong thử nghiệm/số lỗi sửa thử nghiệm)
• cho mỗi cải tiến mới, tỷ lệ lỗi mới (số lượng các lỗi tìm thấy cho tăng cường này/số mandays)

và các số liệu khác.

Điều đó là không thể, vì những lý do chúng tôi không đi vào, để kiểm tra mọi thứ mọi lúc.

Vì vậy, câu hỏi của tôi là:

Làm cách nào để ước tính số lượng và loại lỗi tồn tại trong phần mềm của tôi? Tôi phải tuân thủ những chiến lược thử nghiệm nào để đảm bảo rằng sản phẩm là tốt?

Tôi biết đây là một câu hỏi mở, nhưng hey, tôi cũng biết rằng không có giải pháp đơn giản nào.

Cảm ơn.

Answer 1

Tôi không nghĩ rằng bạn có thể thực sự ước tính số lượng lỗi trong ứng dụng của mình. Trừ khi bạn sử dụng một ngôn ngữ và quy trình cho phép các bằng chứng chính thức, bạn có thể không bao giờ thực sự chắc chắn. Thời gian của bạn có lẽ tốt hơn dành cho việc thiết lập các quy trình để giảm thiểu lỗi hơn là cố gắng ước tính số lượng bạn có.

Một trong những điều quan trọng nhất bạn có thể làm là có một nhóm QA tốt và theo dõi mục công việc tốt. Bạn có thể không thể thực hiện kiểm tra hồi quy toàn thời gian, nhưng nếu bạn có danh sách các thay đổi bạn đã thực hiện cho ứng dụng kể từ lần phát hành cuối cùng, thì người QA (hoặc người) của bạn có thể tập trung thử nghiệm trên các phần của ứng dụng được dự kiến ​​sẽ bị ảnh hưởng.

Một điều hữu ích khác là kiểm tra đơn vị. Càng nhiều codebase của bạn, bạn đã tự tin hơn, bạn có thể thay đổi ở một khu vực không vô tình ảnh hưởng đến một khu vực khác. Tôi đã tìm thấy điều này khá hữu ích, vì đôi khi tôi sẽ thay đổi một cái gì đó và quên rằng nó sẽ ảnh hưởng đến một phần khác của ứng dụng, và các bài kiểm tra đơn vị cho thấy vấn đề ngay lập tức. Các bài kiểm tra đơn vị được thông qua sẽ không đảm bảo rằng bạn chưa phá vỡ bất kỳ điều gì, nhưng chúng có thể giúp tăng sự tự tin mà những thay đổi bạn thực hiện đang hoạt động.

Ngoài ra, đây là một chút thừa và rõ ràng, nhưng chắc chắn rằng bạn có phần mềm theo dõi lỗi tốt. :)

Answer 2

Tôi nghĩ việc giữ cho nó đơn giản là cách tốt nhất để đi. Phân loại lỗi của bạn theo mức độ nghiêm trọng và giải quyết chúng theo thứ tự giảm mức độ nghiêm trọng.

Bằng cách này bạn có thể bàn giao bản dựng chất lượng cao nhất có thể (số lỗi còn lại đáng kể là cách tôi đánh giá chất lượng của sản phẩm, trái ngược với một số thống kê phức tạp).

Answer 3

Câu hỏi là ai yêu cầu bạn cung cấp số liệu thống kê.

Nếu đó là người phi kỹ thuật, hãy giả mạo số liệu thống kê. Bởi "giả", tôi có nghĩa là "cung cấp bất kỳ chắc chắn vô nghĩa, nhưng số thực" của các loại bạn đã đề cập.

Nếu đó là những người kỹ thuật không có nền CS, họ phải được thông báo về sự cố tạm dừng, không thể giải quyết được và đơn giản hơn việc đếm và phân loại các lỗi còn lại.

Có rất nhiều chỉ số và công cụ liên quan đến chất lượng phần mềm (độ bao phủ mã, độ phức tạp của chu trình, hướng dẫn mã hóa và các công cụ thực thi chúng, v.v.). Trong thực tế, những gì làm việc là tự động hóa càng nhiều bài kiểm tra càng tốt, có người thử nghiệm làm nhiều thử nghiệm không tự động nhất có thể, và sau đó cầu nguyện.

Answer 4

Bao lâu là một đoạn chuỗi? Cuối cùng những gì làm cho một sản phẩm chất lượng? Bugs cho một số dấu hiệu có, nhưng nhiều yếu tố khác có liên quan, đơn vị kiểm tra bảo hiểm là một yếu tố quan trọng trong IMO. Nhưng trong kinh nghiệm của tôi yếu tố chính ảnh hưởng đến việc liệu một sản phẩm có thể được coi là chất lượng hay không, là sự hiểu biết tốt về vấn đề đang được giải quyết. Thường thì điều xảy ra là, 'vấn đề' mà ​​sản phẩm có nghĩa là giải quyết không được hiểu chính xác và các nhà phát triển cuối cùng phát minh ra giải pháp cho vấn đề họ có thịt trong đầu họ, chứ không phải vấn đề thực, do đó 'lỗi' được tạo ra .Tôi là một người đề xuất mạnh mẽ về việc phát triển lặp lại Agile, theo cách đó sản phẩm liên tục truy cập vào 'vấn đề' và sản phẩm không đi xa đến mục tiêu của nó.

Answer 5

Hầu hết các phương pháp nhanh nhẹn giải quyết tình huống khó xử này khá rõ ràng. Bạn không thể kiểm tra mọi thứ. Bạn không thể kiểm tra nó vô số lần trước khi bạn phát hành. Vì vậy, các thủ tục là dựa vào rủi ro và khả năng của lỗi. Cả rủi ro và khả năng đều là giá trị số. Sản phẩm của cả hai cung cấp cho bạn một số RPN. Nếu số nhỏ hơn 15 bạn gửi bản beta. Nếu bạn có thể giảm xuống dưới 10, bạn gửi sản phẩm và đẩy lỗi được sửa trong bản phát hành sau này.

Cách tính rủi ro?

Nếu nó một vụ tai nạn sau đó nó 5 Nếu nó một vụ tai nạn nhưng bạn có thể cung cấp một công việc xung quanh sau đó của nó một số ít hơn 5. Nếu lỗi này làm giảm các chức năng sau đó nó 4

Làm thế nào để tính toán khả năng?

có thể giúp bạn tái tạo nó mỗi khi bạn chạy, nó một 5. Nếu việc xung quanh cung cấp vẫn làm cho nó sụp đổ sau đó chưa đầy 5

Vâng, tôi tò mò muốn biết liệu có ai khác sử dụng kế hoạch này và háo hức muốn biết về sức mạnh của họ về điều này.

Answer 6

Các câu hỏi tôi nghe được, làm cách nào để ước tính lỗi trong phần mềm của tôi? và tôi sử dụng những kỹ thuật nào để đảm bảo chất lượng tốt?

Thay vì trải qua một khóa học đầy đủ, dưới đây là một vài cách tiếp cận.

Làm cách nào để ước tính lỗi trong phần mềm của tôi?

Bắt đầu với lịch sử, bạn biết số lượng bạn đã tìm thấy trong khi thử nghiệm (hy vọng) và bạn biết có bao nhiêu người được tìm thấy sau sự kiện. Bạn có thể sử dụng nó để ước tính mức độ hiệu quả của việc tìm lỗi (DDR - Defect Detection Rate là một tên cho điều này).Nếu bạn có thể chỉ ra rằng trong một khoảng thời gian nhất định, DDR của bạn nhất quán (hoặc cải thiện), bạn có thể cung cấp một số thông tin chi tiết về bản phát hành bằng cách đoán số lỗi phát hành sau khi sản phẩm được phát hành.

Tôi sử dụng các kỹ thuật nào để đảm bảo chất lượng tốt?

Nguyên nhân phân tích về lỗi của bạn sẽ chỉ cho bạn với các thành phần cụ thể mà là lỗi, các nhà phát triển cụ thể mà tạo ra mã lỗi, thực tế là thiếu yêu cầu đầy đủ kết quả trong việc thực hiện không phù hợp với mong đợi, vv

cuộc họp Dự án xét để nhanh chóng xác định điều gì là tốt, vì vậy những điều đó có thể được lặp đi lặp lại và những gì là xấu và tìm cách để không làm những điều đó một lần nữa.

Hy vọng rằng những thứ này sẽ mang lại cho bạn một khởi đầu tốt. Chúc may mắn!

Answer 7

Dường như sự đồng thuận là sự nhấn mạnh nên được đặt vào thử nghiệm đơn vị. Theo dõi lỗi là một chỉ báo tốt về chất lượng sản phẩm, nhưng chỉ là acurate như nhóm thử nghiệm của bạn. Nếu bạn sử dụng thử nghiệm đơn vị, nó sẽ cung cấp cho bạn số liệu đo lường mã có thể đo lường và cung cấp kiểm tra hồi quy để bạn có thể yên tâm rằng bạn đã không làm bất cứ điều gì kể từ tháng trước.

Công ty của tôi dựa vào thử nghiệm mức hệ thống/tích hợp. Tôi thấy rất nhiều khuyết tật được giới thiệu bởi vì có một thiếu kiểm tra hồi quy. Tôi nghĩ rằng "lỗi", nơi mà các nhà phát triển thực hiện các yêu cầu lệch khỏi tầm nhìn của người dùng là một vấn đề riêng biệt như Dan và rptony được giải quyết là tốt nhất bởi các phương pháp Agile.