7가지 주요 ISTQB 테스트 원칙 | #3 소프트웨어 테스트의 첫 번째 단계

정확하고 정확한 소프트웨어 테스트를 수행하는 것은 수많은 원칙을 따릅니다. 국제 소프트웨어 테스팅 자격 위원회(International Software Testing Qualifications Board)는 오늘 논의할 7가지 기본 자격을 구분합니다. 궁금하신가요? 주요 ISTQB 테스트 원칙에 대한 기사를 읽으십시오!

ISTQB 테스트 원칙 – 목차:

1. 테스트는 결함을 보여주지만 결함이 없음을 증명할 수는 없습니다.
2. 철저한 테스트 불가능
3. 조기 테스트로 시간과 비용 절약
4. 오작동 눈덩이 효과
5. 농약의 역설
6. 컨텍스트에 따라 다릅니다
7. 완벽한 소프트웨어 광고는 금물
8. 요약

테스트는 결함을 보여주지만 결함이 없음을 증명할 수는 없습니다.

테스트는 실수를 발견할 확률을 높이고, 이는 다시 실수를 고칠 기회를 용이하게 합니다. 그러나 대다수가 발견되어 수정되더라도 소프트웨어에 모든 결함이 없다고 완전히 보장할 수는 없습니다. 완벽한 소프트웨어를 만들 수 없기 때문에 많은 사람들 이 설계상 프로세스를 부정적인 것으로 간주합니다. 긍정적인 결과를 얻을 수 없고 항상 프로그램에서 "더러움"을 찾을 수 있기 때문입니다.

철저한 테스트 불가능

위의 경험 법칙에 따르면 소프트웨어의 모든 오작동을 감지하는 것은 무의미합니다. 그러나 이는 단순한 쇼트 프로그램에는 적용되지 않습니다. 이것은 차례로 일부 프로그램을 완전히 테스트하기 위해 모든 입력 및 전제 조건 조합을 볼 수 있는 기회가 있음을 나타냅니다. 정교한 소프트웨어를 평가할 때 최고의 AI라도 수동 테스터는 고사하고 필요한 모든 측정을 실행할 수는 없습니다. 자동화된 평가자는 앱을 보다 효율적이고 정확하게 실행하지만 여전히 완벽한 성능을 보장할 수는 없습니다. 그렇게 하려면 우선 순위 지정, 위험 분석, 다른 테스트 기술 찾기 및 실행과 같은 추가 작업을 시작해야 합니다.

조기 테스트로 시간과 비용 절약

많은 전문가들은 이 원칙을 "좌회전"이라고 부릅니다. 결함을 빨리 발견할수록 더 쉽게 수정할 수 있으므로 정적 및 동적 테스트를 가능한 한 빨리 시작해야 합니다. 간단히 말해서:

• 정적 테스트 – 코드를 실행하지 않고 제품을 평가합니다.
• 동적 테스팅 – 모듈이나 시스템이 실행되는 동안 코드 평가

구현의 첫 번째 단계에서 결함을 감지하면 추가 진단이 용이합니다. 그러나 소프트웨어의 두 영역이 상호 작용할 때 오류가 있는 영역을 정확히 찾아낼 수 없기 때문에 결함을 수정하는 것이 번거롭습니다. 이러한 경우 처리하는 데 추가 시간, 노력 및 인력이 필요합니다. 전반적으로 균열이 증식하는 것을 방지할 수 있는 것은 표면 장애물에 대한 신속한 대응입니다.

오작동 눈덩이 효과

대부분의 글리치는 가장 중요한 모듈에 클러스터링되는 경향이 있으므로 심층 조사를 통해 대부분을 밝혀내고 충분히 제거합니다. 이러한 그룹은 향후 조치 수행을 계획하고 수립하기 위해 위험 분석을 실행하는 주요 초점이 됩니다. 대부분의 결함은 사용자가 선택한 경로를 따른 후에 나타나지만 이러한 경우 지식만으로는 모듈이 완벽하지 않습니다.

파레토 법칙 은 결과의 80%는 20%의 원인에서 비롯된다는 것입니다. 즉, 80%의 버그가 20%의 모듈에 존재합니다. 모듈에서 수많은 오작동이 발생하면 계속 파헤쳐야 합니다.

농약의 역설

동일한 테스트를 반복적으로 실행하는 것은 처음부터 잘못 설계되었을 수 있고 결코 효과적이지 않을 수 있기 때문에 실패할 수 있습니다. 소프트웨어에서 새로운 결함을 찾을 가능성을 높이려면 테스트를 수정하고 업그레이드 해야 합니다.

완전히 새로운 진단 시스템을 만드는 것 역시 효과가 없습니다. 이전 조합을 따르면 동일한 수준에서 평가 프로세스가 중지될 수 있습니다. 해충을 방제하는 농약도 일정량 사용하면 효과가 떨어지기 때문에 이 원리를 '농약의 역설' 이라고 합니다.

컨텍스트에 따라 다릅니다

테스트를 실행하는 방법은 검사 대상에 따라 다릅니다. 따라서 회계 프로그램, 비디오 게임 또는 소셜 네트워킹 응용 프로그램을 테스트하는 것은 상당히 다양합니다. 또한 상황에 따라 다릅니다. 예를 들어 사용자의 매력도, 사용 용이성, 시각적 계층 등 앱의 실용성에 중점을 둔 분석은 수행과 같은 프로그램의 기능적 속성을 목표로 한 평가와 다릅니다. 정확한 계산.

완벽한 소프트웨어 광고는 금물

다양한 유형의 진단 도구를 적용한다고 해서 스팟온 앱이 보장되는 것은 아닙니다. 자신의 앱을 잘못된 것으로 주장하고 광고하는 많은 사람들이 있지만 아마도 그들이 주장하는 마케팅 노력 때문일 것입니다. 여러 수동 및 자동 테스트를 실행하여 가능한 한 많은 오류를 발견하고 수정할 가능성을 높일 수 있지만 여전히 완벽한 성능을 보장할 수는 없습니다. 어떤 경우에는 프로그램이 모든 사용자의 기대를 충족시키지 못할 수 있습니다.

ISTQB 테스트 원칙 – 요약

이것은 기본적인 수준에서 ISTQB 가 소프트웨어 테스터가 따라야 하는 7가지 ISTQB 테스팅 원칙을 제시하는 방법입니다. 첫째, 전체 소프트웨어 진단이 불가능함을 나타내므로 무엇보다도 테스트를 수정하고 주요 모듈에서 철저한 검색을 수행하는 것이 중요합니다. 이러한 조치는 대부분의 결함에 대한 검색 및 제거를 향상시켜 향후 실패 가능성을 줄입니다.

소프트웨어 테스팅이란? 이제 답을 알았습니다! Python 및 Javascript에 대한 다른 시리즈를 확인하십시오!

콘텐츠가 마음에 들면 Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest에서 바쁜 꿀벌 커뮤니티에 가입하세요.

저자: 로버트 휘트니

IT 부서를 지도하는 JavaScript 전문가이자 강사입니다. 그의 주요 목표는 코딩하는 동안 다른 사람들에게 효과적으로 협력하는 방법을 가르쳐 팀 생산성을 높이는 것입니다.

모든 게시물 보기

소프트웨어 테스트의 첫 번째 단계:

1. 소프트웨어 테스팅이란?
2. 소프트웨어 오류에 대한 1가지 큰 진실
3. 7가지 주요 ISTQB 테스트 원칙
4. STLC의 6단계
5. 테스트 대 디버깅
6. 소프트웨어 테스트 프로세스의 검증 및 검증