ISTQB 4.0 공부 ) 1장. 1.1 "테스팅이란 무엇인가", 1.2 "테스팅이 왜 필요한가"를 알아보자.

정석대로라면 실라버스 4.0 버전을 꼼꼼하게 다 읽어 봐야 되지만 시간이 없을 땐 여기 있는 내용들이라도 전부 읽어보도록 하자. 5번 이상 읽어서라도 이해해서 알아둬야 한다. 

---

들어가기 전 알아둬야 하는 1.1 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해가 쉽게 되도록 공부한 설명.

베리피케이션 : 요구사항 충족 확인, 준수 여부 확인.
밸리데이션 : 이해관계자가 만족하는지 확인.

동적 테스팅 : 소프트웨어 실행. << 시스템 돌리면서 처리.
정적 테스팅 : 리뷰 + 정적 분석. << 문서, 코드 보면서 해결.

< 테스팅과 디버깅의 차이 >
테스팅 : 결함이 존재하는 지 판단. 장애를 통해 결함을 발견하는 것.
디버깅 : 결함을 제거.

확인테스팅 : 수정이 되었는지 테스트 실행.
문배 속 확인 테스팅 : 결함을 수정했는지 확인하는 테스팅. 수정 여부를 확인하기 위해 이전에 실패했던 테스트를 실행한다.
리그레션 테스팅 : 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행.
문배 속 리그레션 테스팅 : 수정으로 인해 변경되지 않은 소프트웨어 영역에 의도하지 않은 새로운 결함이 유입되지 않았는지 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트한 프로그램을 다시 테스팅.

 

1.1 테스팅이란 무엇인가?

- 올바르게 동작하지 않는 소프트웨어는 금전적, 시간적, 비즈니스 평판 손실은 물론, 심하게는 부상이나 사망에 이르기까지 다양한 문제를 일으킬 수 있다.
- 소프트웨어 테스팅은 소프트웨어 품질을 평가하고, 소프트웨어 사용 시 나타나는 장애의 위험을 줄여줄 수 있다.
- 소프트웨어 테스팅은 결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동이다.
- 흔히 테스팅이 단지 소프트웨어를 실행하고 결과를 확인하는 테스트 수행에 국한된다고 오해하는 경우가 많지만, 소프트웨어 테스팅에는 다른 활동이 포함되며, 이 활동은 소프트웨어 개발수명주기(SDLC)에 따라서 달라진다.
- 테스팅은 시스템이 주어진 요구사항을 충족하는지 확인하는 베리피케이션을 포함, 시스템이 운영환경에서 사용자 또는 기타 이해관계자가 필요한 바를 만족하는지를 확인하는 밸리데이션도 포함한다.
- 테스팅은 동적 또는 정적일 수 있다. 
- 테스팅은 기술적인 활동에 국한되지 않으며, 적절한 계획/ 관리/ 추정/ 모니터링/ 제어도 필요하다.
- 테스터는 도구를 사용하지만, 테스팅은 주로 테스터가 전문 지식을 갖추고 분석 기술을 사용해 비판적 사고와 시스템적 사고를 적용하는 지적 활동이라는 점을 기억해야 함.

 

1.1.1 테스트 목적

1. 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가.
2. 장애 유발 및 결함 식별.
3. 테스트 대상에 필요한 커버리지 보장.
4. 소프트웨어 품질 부족으로 인한 리스크 수준 완화.
5. 정의된 요구사항의 충족여부를 확인하는 베리피케이션.
6. 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션.
7. 이해관계자가 정보에 입각한 결정을 내리는 데 필요한 정보 제공.
8. 테스트 대상의 품질에 대한 자신감 획득.
9. 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션.

 

1.1.2 테스팅과 디버깅

- 테스팅과 디버깅은 별개의 활동이다.
테스팅	소프트웨어 결함으로 인한 장애를 유발하거나(동적 테스팅) 테스트 대상에 있는 결함을 직접 식별(정적 테스팅)한다.
동적 테스팅
디버깅	동적 테스팅이 장애를 유발했을 때 디버깅은 장애(결함)의 원인을 찾고, 그 원인을 분석하고 제거한다.
	일반적인 디버깅 프로세스 : 장애 재현, 분석(근본 원인 식별), 원인 해결. 이후 확인 테스팅으로 문제가 제대로 수정됐는지 확인.
확인 테스팅은 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직하다. 수정사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하기 위해 리그레션 테스팅을 추가로 할 수 있다.
정적 테스팅
디버깅	정적 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는데 중점을 둔다. 장애를 유발하지 않고 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요가 없다.

 
 

---

들어가기 전 알아둬야 하는 1.2 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해가 쉽게 되도록 공부한 설명.

품질 보증(QA) : 프로세스 중심의 예방 접근법. 개발 및 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용.
품질 제어(QC) : 제품 중심의 교정 접근법. 결함을 수정하는 데 사용. 테스팅은 품질 제어의 주요 활동.
오류 : 인간의 행위, 실수.
결함 : 고장이나 장애의 원인. 결함은 제품에 있어.
장애 : 결함의 실행. 이벤트와 관련.

 

1.2 테스팅이 왜 필요한가?

- 품질 제어 활동의 일환으로 테스팅은 정해진 범위, 시간, 품질, 예산 내에서 합의된 목표를 달성하는 데 도움을 줌.
- 성공에 기여하는 테스팅이 테스트팀의 활동으로 국한된 것은 아니다.
- 모든 이해관계자는 자신이 가진 테스트 기술을 사용해 프로젝트 성공에 기여할 수 있다. 
- 컴포넌트, 시스템, 관련 문서를 대상으로 한 테스팅은 소프트웨어 결함을 식별하는데 도움이 된다.

 

1.2.1 성공을 위한 테스팅의 기여도

- 테스팅은 결함을 식별하는 비용 효율적인 방법이다.
- 디버깅을 통해 식별한 결함은 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.
- 테스팅은 소프트웨어 개발수명주기(SDLC)의 여러 단계에서 테스트 대상의 품질을 직접 평가하는 방법을 제공한다. 이런 평가 결과는 대규모 프로젝트 관리 활동에서 릴리스 여부의 판단과 같은, 소프트웨어 개발수명주기(SDLC) 다음 단계로의 이동 여부 결정에 기여하게 된다.
- 테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다.
- 테스터는 개발수명주기 전반에 걸쳐 그들이 이해하고 있는 사용자 요구사항을 고려한다.
- 계약 또는 법적 요구사항을 충족하거나 규제 표준 준수를 위해 테스팅이 필요할 수 있다.

 

1.2.2 테스팅과 품질 보증(QA)

품질 보증과 테스팅은 다르다. 테스팅은 품질 제어(QC)활동에 속한다.
품질 제어(QC)	적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 제품 중심의 교정 접근법.
	테스팅은 품질 제어의 주요 활동. 정형 기법(모델 확인 및 정확성의 증명), 시뮬레이션, 프로토타이핑도 품질 제어에 속한다.
품질 보증(QA)	프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법. 좋은 프로세스 준수 >> 좋은 제품 만들어진다는 가정 기반.
	품질 보증은 개발 및 테스팅 프로세스 모두에 적용되며, 프로젝트에 참여하는 모두의 책임이다.
테스트 결과는 품질 보증과 품질 제어 모두에 사용된다. 품질 제어는 결함을 수정하는 데 사용하며, 품질 보증은 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용한다.

 

1.2.3 오류, 결함, 장애, 근본 원인

- 사람은 오류(실수)를 저지르며, 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다.
- 사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등 다양한 이유로, 또 단순히 피로하거나 충분한 훈련이 부족해서 오류를 범할 수 있다.

- 결함은 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물에서 나올수 있다.

- 장애의 원인이 오류와 결함만 있는 것은 아니다. 환경 조건으로 발생하는 것도 있다.

- 근본 원인은 문제 발생의 근본적인 이유(예 : 오류로 이어지는 상황)을 말한다. 근본 원인 분석을 통해 식별하며, 근본 원인 분석은 보통 장애가 발생하거나 결함을 식별한 경우 수행한다.
- 근본 원인을 처리(가령 제거)하면 유사한 장애나 결함을 예방하거나 빈도를 줄일 수 있다.