1.1 Why is testing necessary

Keyword

* bug, defect, error, failure, fault, mistake, quality, risk

* 버그, 결함, 에러, 장애, 결점, 실수, 품질, 리스크

1.1.1 Software system context

- 별 이야기는 없음. 그냥 '들어가기 앞서' 같은 문구 정도로 생각하면 될듯... S/W system은 다양한 부분에서 사용되고 있다는 내용이고 이런 S/W system을 사용하다 보면 제대로 종작 안하는 경우가 있는데 이럴때는 금전적 손실, 시간낭비, 비즈니스 이미지 손상, 부상이나 사망이 되는다는 내용임.

Software that does not work correctly can lead to many problems, including loss of money, time or business reputation, and could even cause injury or death.

1.1.2 Causes of software defects

- S/W 결함이 생기는 원인에 대한 설명이다. 여기에서는 용어에 집중을 해야 할 듯...

1) 개발자는 (human) 문서나 코드 작성을 할 때 결함 (bug, defect)을 만드는 오류 (error, mistake)를 하게 된다.

2) 이 결함(defect)이 포함된 코드를 실행 하면 System은 장애(failure)의 원인이 된다.

3) S/W의 장애 (failure)는 발생 하지만 system은 정상 동작 할 수도 있다.

4) 결함(defect)의 원인 : [환경의 요인은 그냥 ... 안볼래...]

- time pressure, complex code, complexity of infrastructure, changed technologies, system interactions.

1.1.3 Role of testing in software development, maintenance and operations

- S/W 개발, 유지보수, 운영에서의 Testing의 역할을 적음 (Testing이 아니라 QA나 Tester로 가야 하는 거 아닌가 모르겠음...)

1.1.4 Testing and quality

- 품질은 측정이 가능하다는 설명 (이해하는데 오래 걸림 ;;;) 올바른 테스팅을 통해 system의 risk가 감소하고 이는 품질이 증가 된다는 것임.

- 품질 항샹을 위해서는 이전 경험과 정보를 기반으로 테스팅을 하면 품질이 개선된다는 말임. (왜냐하면 이전 경험으로 프로세스를 개선하여 테스트를 하면 결함의 재발을 방지 한다는 이론임)>> 즉, 요말들은 Quality Assurance  이다 하는 거...

Testing should be integrated as one of the quality assurance activities (i.e. alongside development standards, training and defect analysis).

1.1.5 How much testing is enough?

- 얼만큼 테스트를 해야 적절한가를 알기 위해서는 Risk 수준을 고려한다.

- 다음 단계로 release나 고객에게 delivery 하기 전에 release 결정을 Project 관련자들 (PM이나 PL)이 충분히 할 수 있는 정보를 제공 해야 한다.

---

그냥 테스팅이 뭔지 대충 간만 보는 chapter였음