검증 및 검증은 시험 과정의 일부입니까?

많은 소스를 기반으로 테스트의 목표가 가능한 많은 버그를 찾는 것이라고 생각하지 않습니다. 우리는 그것이 작동하는지 또는 작동하지 않는지 테스트합니다. 예를 들어 다음은 ISTQB 양식 테스트의 목표입니다.

1. (소프트웨어 제품)이 지정된 요구 사항을 충족하는지 확인

2. (소프트웨어 제품)이 목적에 적합 함을 증명합니다 (유효하다고 생각합니다)

3. 결함 감지

   테스트는 검증, 검증 및 결함 감지라는 데 동의합니다. 그 맞습니까?

나는 당신이 정확히 맞았다 고 생각합니다.

1. 검증과 검증은 다른 것들이며 사실 꽤 잘 정의되어 있습니다. 이 문서를별로 좋아하지는 않지만 ISO 9000ff는 QA와 관련성이 높으며 검증은 제품을 요구 사항 및 검증과 제품을 비교하여 고객 / 사용자의 요구에 실제로 맞는지 확인하는 것으로 정의합니다. .

2. 둘 다 테스트를 통해 수행 할 수 있습니다. 검증은 테스트에서 생성 된 양식 요구 사항으로 이어집니다. 검증은 요구 사항을 직접 참조하지 않고 테스트에 의해 수행됩니다. 나는 이것을 탐색 적 테스트라고 종종 생각합니다. 분명히 사용자의 실제 요구를 실제로 이해하는 사람들이 수행해야하므로 실제 사용자의 알파 및 베타 테스트가 확실한 옵션입니다.

3. 이론적으로는 처음 두 가지가 버그가 아니라고 주장 할 수 있다고 생각합니다. 따라서 별도의 목표로 버그를 찾는 것이 의미가 없습니다. 그러나 실제로 확인하거나 확인할 수없는 것이 있다고 생각합니다. 예를 들어 보안 : 소프트웨어 시스템이 공격에 대해 안전한지 어떻게 확인 또는 검증합니까? 대신 취약점을 찾으십시오. 이 검색은 문제를 찾지 못하면 아무것도 확인하거나 확인하지 않지만 성공하면 버그를 찾습니다.

위키 백과에서 : "... 즉, 제품이 실제로 맞는지 검증 보장하지만 사용자의 필요 , 그 사양은 처음에 정확을 검증 제품이 요구 사항 및 설계 사양에 따라 구축 된 보장되는 동안, 유효성 검사는 "올바른 것을 만들었습니다". 확인은 "올바른 것을 만들 었는지"를 확인합니다. 유효성 검사는 제공된대로 제품이 의도 한대로 사용되는지 확인합니다. "

사용자의 요구를 테스트 할 수 없으며 코드로 사양이 올바른지 확인할 수 없습니다. 따라서 테스트를 통해 유효성 검사를 수행하지 않습니다.

검증은 요구 사항과 디자인이 정확하다고 가정하므로 코드를 작성하여 테스트 할 수 있습니다 (테스트).

실제 환경에서 테스트는 소프트웨어 요구 사항 (비즈니스 / 기능 / 비 기능)을 충족하는 소프트웨어의 검증 및 검증입니다. 이것의 목적은 소프트웨어가 목적에 적합한 지 결정하는 것입니다. 응용 프로그램의 요구 사항을 충족하지 않는 동작은 결함입니다. 소프트웨어의 목적에 맞는지 결정하기 전에 심각도를 평가해야합니다.

심각도가 낮은 결함은 프로덕션 유형 용도로 소프트웨어를 전달하는 데 방해가되지 않을 수 있습니다. 심각도가 높으면 수정이 필요합니다. 실제로 모든 소프트웨어에는 결함이 있으며 일부 소프트웨어에는 코딩 문제가 있고 다른 소프트웨어에는 요구 사항이 누락되어 있습니다. 알 수없는 요구 사항을 테스트 할 수 없기 때문에 테스트 할 수 없습니다.

검증 및 검증에 대한 많은 정의가 있습니다. 많은 사람들이 V & V 태그를 사용하여 둘 다 단일 활동으로 그룹화합니다. 목표는 소프트웨어가 올바른 것을 만들고 올바른 것을 만드는 것입니다. 요구 사항의 준수 여부를 확인하거나 버그를 찾으려고하는지 여부는이 수준에서 필수적인 것은 아닙니다.

테스트는 다른 방법이 아닌 검증 및 검증에 대한 많은 기술 중 하나입니다. 코드 검토는 수학 증명과 함께 또 하나의 공식 검증입니다.

그럼에도 불구하고 요구 사항의 준수 여부를 확인하기위한 것이 아니라 버그를 찾기위한 목적으로 테스트를 수행해야합니다.

주요 차이점은 테스터의 마음에 있습니다. 소프트웨어가 실패했음을 나타내는 테스트 사례 (버그 찾기)를 구축하는 것보다 소프트웨어가 의도 한대로 작동하는지 (준수 확인) 테스트 사례를 구축하는 것이 훨씬 쉽습니다.

훌륭한 테스터는 안전한 방식으로 소프트웨어를 실행하는 것이 아니라 소프트웨어를 깨는 데 열정적입니다.

실제적인 관점에서 이것을 볼 수 있습니다. 테스트를 위해서는 테스트 사례를 정의해야합니다. 일반적으로 지정된 요구 사항에 따라 테스트 사례를 정의하고 "행복한 하루"사례와 "가장자리 사례"를 다루어야합니다. 특히 후자는 종종 소프트웨어를 중단하려는 의도로 정의됩니다. 일부 테스트가 실패하면 버그 / 결함이 나타납니다. 각 요구 사항에 대해 적절한 양의 테스트 사례가 있고 모든 테스트에 통과 한 경우 모든 요구 사항이 충족되었음을 완전히 증명 하지는 못했지만 그 가능성을 개선하여 일부 확인을 수행 한 것입니다.

따라서 문제의 해당 부분에서 버그를 발견하고 확인하는 것은 동일한 프로세스의 양면 일 수 있습니다.

• 테스트 실패 : 결함 발견

• 테스트 통과 : 검증 완료 (적어도 적절한 테스트를 제공하는 경우 어느 정도)

검증과 관련하여 : @Mert가 지적했듯이, 검증은 승인 테스트를 통해 수행 할 수 있지만 다른 형태의 테스트로는 수행 할 수 없습니다. 따라서 일반적으로 테스트는 일부 잠재적 사용자가 승인 테스트로 수행 한 경우에만 유효성 검사를 수행하지 않습니다.

그것은 모두 "확인"의 정의에 달려 있습니다. 예를 들어, 공식 검증 은 일반적으로 QA 팀이 수행하는 것이 아니라 개발자의 책임입니다. 그와 관련된 높은 비용 (지식 갭 및 필요한 자원)으로 인해 공식적인 검증을 수행하는 사람은 거의 없습니다.

소프트웨어 테스트는 QA와 다릅니다. 니가 맞았 어. 소프트웨어 테스트에는 전체적으로 많은 단계 (연기, 단위, 회귀, 통합, 사용자 승인 등)가 포함됩니다.

따라서 소프트웨어가 요구 사항에 따라 작동하는지 확인하는 것이 QA의 목표입니다 (품질 보증 전문가-일명 단순히 테스터라고 불림). 그러나 그것은 단지 테스트 가 아닙니다 . QA는 문제가되는 제품의 품질 검사를 수행하기위한 적절한 프로세스 세트가 마련되어 있거나 최소한 프로젝트의 설계 단계에 들어가도록합니다.

따라서 이상적으로는 QA가 소프트웨어를 깨고 결함을 찾아서 테스트하지 않고 요구 사항 세트에 대해 애플리케이션 을 검증 할 것으로 기대합니다 .