Là xác minh và xác nhận một phần của quá trình thử nghiệm?

Dựa trên nhiều nguồn, tôi không tin định nghĩa đơn giản mà mục đích của thử nghiệm là tìm ra càng nhiều lỗi càng tốt - chúng tôi kiểm tra để đảm bảo rằng nó hoạt động hoặc không. Ví dụ: followint là mục tiêu của mẫu thử nghiệm ISTQB:

1. Xác định rằng (sản phẩm phần mềm) đáp ứng các yêu cầu được chỉ định (tôi nghĩ tính xác thực của nó)

2. Chứng minh rằng (sản phẩm phần mềm) phù hợp với mục đích (tôi nghĩ đó là xác nhận)

3. Phát hiện khuyết tật

   Tôi đồng ý rằng kiểm tra là xác minh, xác nhận và phát hiện lỗi. Đúng không?

Tôi nghĩ rằng bạn đã nhận nó chính xác.

1. Xác minh và xác nhận là những thứ khác nhau và trên thực tế được xác định khá tốt. Mặc dù tôi không thích tài liệu này lắm nhưng ISO 9000ff rất phù hợp với QA và định nghĩa Xác minh là so sánh sản phẩm với các yêu cầu và Xác thực của nó là kiểm tra xem nó có thực sự phù hợp với nhu cầu của khách hàng / người dùng hay không và tất cả chúng ta đều biết điều này có thể khác nhau .

2. Cả hai có thể được thực hiện thông qua thử nghiệm. Xác minh sẽ dẫn đến các thử nghiệm tạo ra yêu cầu mẫu. Xác nhận dẫn đến kiểm tra được thực hiện bởi các Bài kiểm tra mà không cần tham khảo trực tiếp các yêu cầu. Tôi nghĩ rằng điều này thường được gọi là thử nghiệm thăm dò. Rõ ràng nó phải được thực hiện bởi những người có hiểu biết thực sự về nhu cầu thực sự của người dùng, vì vậy thử nghiệm alpha và beta bởi người dùng thực là những lựa chọn rõ ràng.

3. Trên cơ sở lý thuyết, tôi đoán người ta có thể tranh luận bất cứ điều gì được đề cập trong hai điều đầu tiên không phải là một lỗi và do đó, việc tìm ra các lỗi như một mục tiêu riêng biệt không có ý nghĩa gì. Nhưng tôi nghĩ có những thứ bạn không thể xác minh hoặc xác nhận. Ví dụ: bảo mật: Làm thế nào để bạn xác nhận hoặc xác minh rằng một hệ thống phần mềm an toàn trước các cuộc tấn công? Thay vào đó bạn cố gắng tìm lỗ hổng. Tìm kiếm này không xác minh hoặc xác thực bất cứ điều gì nếu không tìm thấy sự cố, nhưng nó tìm thấy lỗi nếu thành công.

Từ Wikipedia: "... Nói cách khác, xác thực đảm bảo rằng sản phẩm thực sự đáp ứng nhu cầu của người dùng và thông số kỹ thuật là chính xác ngay từ đầu , trong khi xác minh đảm bảo rằng sản phẩm đã được xây dựng theo yêu cầu và thông số kỹ thuật thiết kế Xác nhận đảm bảo rằng "bạn đã xây dựng đúng thứ". Xác minh đảm bảo rằng "bạn đã xây dựng đúng". Xác thực xác nhận rằng sản phẩm, như được cung cấp, sẽ đáp ứng mục đích sử dụng. "

Bạn không thể kiểm tra nhu cầu của người dùng và kiểm tra xem các thông số kỹ thuật có chính xác theo mã không. Vì vậy, xác nhận không được thực hiện bằng thử nghiệm.

Xác minh cho rằng các yêu cầu và thiết kế của bạn là chính xác, vì vậy bạn có thể kiểm tra nó bằng cách viết mã (thử nghiệm).

Đối với thế giới thực, kiểm tra là xác minh và xác nhận phần mềm đáp ứng yêu cầu của phần mềm (kinh doanh / chức năng / không chức năng). Mục đích của những điều này là để xác định xem phần mềm có phù hợp với mục đích hay không. Bất kỳ hành vi nào không đáp ứng các yêu cầu của ứng dụng là một khiếm khuyết - mức độ nghiêm trọng sẽ cần phải được cân nhắc trước khi xác định xem phần mềm có phù hợp với mục đích hay không.

Các lỗi nghiêm trọng thấp có lẽ không phải là điểm dừng hiển thị để chuyển phần mềm sang sử dụng loại sản xuất, Mức độ nghiêm trọng cao có thể yêu cầu sửa chữa để được sản xuất. Trong thế giới thực, tất cả các phần mềm đều có lỗi, một số là vấn đề mã hóa và một số khác là do thiếu các yêu cầu - có thể không được kiểm tra vì bạn không thể kiểm tra các yêu cầu chưa biết.

Có nhiều định nghĩa về xác minh và xác nhận. Nhiều người thậm chí sử dụng thẻ V & V để nhóm cả hai trong một hoạt động. Mục đích là để đảm bảo rằng phần mềm làm cho mọi thứ đúng và làm cho mọi thứ đúng. Cho dù đó là để kiểm tra việc tuân thủ các yêu cầu hoặc cố gắng tìm lỗi không phải là điều cần thiết ở cấp độ này.

Kiểm tra là một trong nhiều kỹ thuật để xác minh và xác nhận, không phải là cách khác. Đánh giá mã là một số khác, và xác minh chính thức, với các bằng chứng toán học khác.

Tuy nhiên, kiểm tra nên được thực hiện với mục đích tìm lỗi, không nhằm mục đích kiểm tra việc tuân thủ các yêu cầu.

Sự khác biệt chính là trong tâm trí của người thử nghiệm. Việc xây dựng một trường hợp thử nghiệm dễ dàng hơn nhiều cho thấy phần mềm hoạt động như dự định (kiểm tra sự tuân thủ), hơn là xây dựng một trường hợp thử nghiệm cho thấy phần mềm bị lỗi (tìm lỗi).

Một người thử nghiệm tuyệt vời là đam mê phá vỡ phần mềm, không phải là thực hiện nó một cách an toàn.

Hãy nhìn nhận điều này từ một quan điểm thực tế. Để thử nghiệm, bạn cần xác định các trường hợp thử nghiệm. Thông thường, bạn xác định các trường hợp kiểm tra theo các yêu cầu đã chỉ định và chúng sẽ bao gồm các trường hợp "ngày hạnh phúc" cũng như "các trường hợp cạnh" - đặc biệt là các trường hợp sau thường được xác định với mục đích phá vỡ phần mềm. Khi một số bài kiểm tra của bạn thất bại, chúng sẽ hiển thị lỗi / lỗi. Khi bạn có số lượng thử nghiệm hợp lý cho từng yêu cầu và tất cả các thử nghiệm đó đều vượt qua, bạn có thể chưa chứng minh đầy đủ rằng tất cả các yêu cầu đều được đáp ứng, nhưng bạn đã cải thiện xác suất cho điều đó, do đó đã thực hiện một số xác minh.

Vì vậy, đối với phần câu hỏi đó, việc tìm lỗi và xác minh có thể chỉ là hai mặt của cùng một quy trình:

• kiểm tra thất bại: tìm thấy lỗi

• kiểm tra vượt qua: xác minh được thực hiện (ít nhất, ở một mức độ nào đó, nếu bạn cung cấp đủ và các xét nghiệm đúng)

Liên quan đến xác nhận: như @Mert đã chỉ ra, xác nhận có thể được thực hiện bằng thử nghiệm chấp nhận, nhưng không phải bằng các hình thức thử nghiệm khác. Do đó, kiểm tra nói chung không gây ra xác nhận, chỉ khi được thực hiện dưới dạng thử nghiệm chấp nhận, bởi một số người dùng tiềm năng.

Tất cả phụ thuộc vào định nghĩa của bạn về "xác minh". Ví dụ, xác minh chính thức thường không phải là thứ được thực hiện bởi nhóm QA, mà thay vào đó là trách nhiệm của các nhà phát triển. Hầu như không ai xác minh chính thức vì chi phí cao liên quan đến nó (khoảng cách kiến ​​thức và tài nguyên cần thiết).

Kiểm thử phần mềm không giống như QA. Bạn đã đúng Kiểm thử phần mềm tổng thể bao gồm nhiều giai đoạn (khói, đơn vị, hồi quy, tích hợp, chấp nhận người dùng, v.v.) trong chính nó.

Do đó, để đảm bảo rằng phần mềm hoạt động theo các yêu cầu là mục tiêu con người của QA (chuyên gia đảm bảo chất lượng - còn được gọi đơn giản là người thử nghiệm nhiều năm trước). Tuy nhiên, nó không chỉ là thử nghiệm . QA đảm bảo rằng bộ quy trình thích hợp để thực hiện kiểm tra chất lượng sản phẩm được đề cập đã được đưa ra hoặc ít nhất là được đưa vào giai đoạn thiết kế của dự án.

Do đó, lý tưởng nhất là bạn mong muốn QA của mình xác minh ứng dụng dựa trên các yêu cầu và không chỉ thử kiểm tra nó bằng cách phá vỡ phần mềm và tìm lỗi.