1.1 - Why is tesing necessary (테스팅이 왜 필요한가)

Terms

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

1.1.1 Software systems context

Software systems are an increasing part of life, from business applications (e.g banking) to consumer products (e.g cars). Most people have had an experience with software that did not work as expected. Software that does not work correctly can lead to many problems, including loss of money, time of business reputation, and could even cause injury or death.

1.1.2 Cause of software defects

A human being can make an error (mistake), which produces a defeat (fault, bug) in the code, in software or a system, or in a document. If a defect in code in executed, the system will fail to do what it should do (or do something, it shouldn't), causing a failures. Defects in software, system or documents many result in failure, but not all defects do so. 

Defeats occur because human beings are fallible and because there is time pressure, complex code, complexity of infrastructure, changed technologies, and/or many system interaction.

Failures can be caused by environmental conditions as well: radiation, magnetism, electronic fields, and pollution can cause faults in firmware or influence the execution of software by changing hardware conditions. 

1.1.3 Role of testing in software development, maintenance and operations

Rigorous testing of system and documentation can help to reduce the risk of problem occurring during operation and contribute to the quality of the software system, if defects found are corrected before the system is released for operational use. 

Software testing may also be required to meet contractual or legal requirements, or industry-specific-standards.

1.1.4 Testing and quality

With the help of testing, it is possible to measure the quality of software in terms of defects found, for both functional and non-functional software requirements and characteristics (e.g. reliability, usability, efficiency,  maintainability and portability). For more information on non-functional testing see Character 2; for more information on software characteristics see "Software Engineering - Software Product Quality" (ISO 9126)

Testing can give confidence in the quality of the software if it finds few or no defects. A properly designed test that passes reduces the overall level of risk in a system. When testing does find defects, the quality of the software system increases when those defects are fixed.

Lessons should be learned from previous projects. By understanding the root cause of defects found in other projects, processes can be improved, which in turn should prevent those defects from reoccurring and, as a consequence, improve the quality of future system. This is an aspect of quality assurance. 

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

1.1.5 How much testing is enough? (K2)

Deciding how much testing is enough should take account of the level of risk, including technical and business product and project constraints such as time and budget. (Risk is discussed further in Chapter 5.) 

Testing should provide sufficient information to stakeholders to make informed decisions about the release of the software or system being tested, for next development step or handover to customers.

용어

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

1.1.1 소프트웨어 시스템 정황

소프트웨어 시스템은 비지니스 애플리케이션(예, 은행)에서 소비자 제품 (예, 자동차)까지 많은 부분까지 생활의 많은 부분에서 사용되고 있다. 대부분의 사람들은 소프트웨어가 기대한 대로 제대로 동작하지 않는 경험을 갖고 있다.  소프트웨어가 제대로 동작하지 않으면, 다양한 문제점들이 발생한다. 금전 또는 시간, 비지니스 이미지의 손실 그리고, 부상이나 사망에까지 이른다.

1.1.2 소프트웨어 결함의 원인

개발자는 소프트웨어 또는 시스템의 코드 또는 문서를 작성할 때,  중 제품의 결함을 만드는 에러(실수)를 할 수 있다.

결함이 내제된 코드가 실행되면, 시스템은 제대로 동작하지 않는다. (또는 동작하지 않아야 하지만 동작한다.) 소프트웨어, 시스템 또는 문서의 결함은 장애의 원인이 되지만, 모든 결함이 장애가 되는 것은 아니다.

결함은 인간이 실수를 범하기 쉽기 때문과 시간 압박, 복잡한 코드, 인프라의 복잡성, 기술의 변화, 그리고 시스템들의 상호작용에 등의 의해서 발생된다.

장애는 환경 조건, 방사, 자기, 전자기장, 물리적 오염 등에서도 야기될 수 있으며, 펌웨어 또는 하드웨어 조건을 변경시켜 소프트웨어에 영향을 줄 수 있다. 

1.1.3 소프트 웨어 개발, 유지보수 운영에서 테스팅의 역활

시스템이나 문서의 엄격한 테스팅은 운영에서 발생될 수 있는 위험한 문제를 줄이고, 소프트웨어 시스템의 품질에 기여할 수 있다. 만약에 발견된 결함이 시스템의 배포 이전에 수정된다면 말이다.

소프트웨어 테스팅은 또한 계약 충족, 법적 요구사항과 산업별 표준을 만족시키기 위해 필요하다. 

1.1.4 테스팅과 품질

테스팅의 도움으로 기능적 및 비기능적 소프트웨어 요구사항과 특성(예 신뢰성, 사용성 효율성, 유지보수성, 이식성)의 발견된 결함으로 소프트웨어 품질을 측정할 수 있다. 소프트웨어 품질 특성에 대한 상세 정보는 비기능 테스팅 챕터2 "Software Engineering - Software Product Quality"(ISO 9126)에 기술되어 있다.

테스팅으로 발견된 결함이 몇개가 없거나 없을 경우 소프트웨어 품질에 대해 확신을 가질 수 있다. 올바르게 설계된 테스트는 전체적으로 시스템의 위험이 감소하게 된다. 테스팅으로 결함이 발견되고, 결함이 수정될 때, 소프트웨어 품질이 증가하게 된다.

이전 프로젝트로부터 배워야 한다. 다른 프로젝트로부터 발견 된 결함의 원인을 이해 함으로 써 프로세스가 개선될 수 있다. 이는 결함이 재발생되는 것을 예방할 수 있고, 결과적으로 차후 시스템의 품질을 개선할 수 있다. 이것은 품질 보증의 모습이다.

테스팅은 품질 보증 활동 하나로 통합되어야 한다. (개발 표준, 훈련, 결함 분석과 함께)

1.1.5 테스팅은 얼마나 해야 충분한가?

테스팅이 얼마나 해야 충분한지 결정하는 것은 위험 수준과 기술적 사업적 제품 그리고 프로젝트의 제약과 시간 예산을 포함해서 고려해야 한다. (리스크는 챕터 5에서 자세히 다루어진다.)

테스팅은 테스트된 소프트웨어나 시스템의 다음 개발 단계로의 배포 결정 또는 고객에게 이양하는 결정을 내릴 수 있도록 이해관계자들에게 충분한 정보를 제공해야 한다.