테스팅이란 무엇인가? (실라버스 요약)

1.1 테스팅이란 무엇인가? 
 소프트웨어 테스팅은 소프트웨어의 품질을 평가하고, 

 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다.

 테스팅 활동에는 테스트 대상 컴포넌트나 시스템을 실행하는 것도 있다. 

 이것을 동적 테스팅이라 부른다.

 테스트 대상 컴포넌트나 시스템을 실행하지 않는 테스팅도 있다. 

 이런 테스팅을 정적 테스팅이라 부른다.

 테스팅은 요구사항, 사용자 스토리, 그 외 기타 명세의 Verification 활동을 한다. 
 또한 시스템이 운영 환경에서 사용자 또는 기타 이해관계자의 요구를 만족시키는지를 확인하는 
 Validation 또한 테스팅에 포함 된다.

1.1.1 테스팅의 일반적인 목적 
 - 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방 
 - 명시된 모든 요구사항이 충족됐는지 검증
 - 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
 - 테스트 대상의 품질 수준에 대한 자신감 획득
 - 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨의 감소
 - 이해관계자가 테스트 대상의 품질 수준을 결정하는데 필요한 충분한 정보 제공 
 - 계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인

컴포넌트 테스팅(Component Testing)
 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정하는 것일 수 있다. 
 또 다른 목적은 코드 커버리지를 높이는 것일 수도 있다. 

인수 테스팅(Acceptance Testing)
 시스템이 기대한 대로 동작하는지, 또 요구사항을 충족하는지 확인하는 것
 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것

1.1.2 테스팅과 디버깅(Testing and Debugging)
 테스팅과 디버깅은 다르다. 
 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼 수 있으며, 
 디버깅은 그런 장애의 원인을 찾고 분석해서 수정하는 개발 활동이다.
 이후 실행되는 확인 테스팅에서 결함을 제대로 수정했는지 확인한다.
 테스터가 초기 테스트와 마지막 확인 테스트를 담당하고 
 개발자가 디버깅 관련 컴포넌트 및 컴포넌트 통합 테스팅을 수행한다. 

 반면, 애자일 개발 및 기타 소프트웨어 수명주기 모델에서는 테스터가 디버깅과 컴포넌트 테스팅에 관여하기도 한다.


1.2 테스팅이 왜 필요한가? Why is Testing Necessary? 
 컴포넌트, 시스템 및 관련 문서에 대한 철저한 테스팅은 운영 중 장애 발생 가능성을 줄이는 데 도움이 된다.
 결함을 발견하고 또 발견된 결함을 수정하는 것은 컴포넌트나 시스템의 품질에 기여하는 것이다. 
 소프트웨어 테스팅이 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해 필요할 수도 있다. 


 1.2.1 성공을 위한 테스팅의 기여 (Testing's Contributions to Scucess)
  - 테스터를 요구사항 리뷰 혹은 사용자 스토리 개선에 참여시키면 해당 작업 산출물에서 결함을 발견할 수 있다.
    요구사항 결함을 식별하고 제거하면 잘못된 혹은 테스트할 수 없는 기능이 개발되는 리스크를 줄일 수 있다. 
  - 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우, 설계와 그것을 어떻게 
    테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다. 
    이렇게 이해도가 올라가면 기능 설계에 결함이 유입되는 리스크가 줄어들게 되고, 필요한 테스틀 좀 더 일찍 식별할 수 있다.
  - 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우, 코드와 그것을 어떻게 테스트해야 하는지에 대해
    서로 좀 더 깊이 있게 이해하게 된다. 이해도가 높아지면 코드와 테스트에서의 결함 발생 리스크가 줄어든다. 
  - 테스터가 릴리스 전에 소프트웨어를 확인하고 검증하면, 그러지 않았을 경우 놓쳤을 수 있는 장애를 발견하고 
    그 장애의 원인인 결함을 제거(즉, 디버깅)하는 데 도움을 줄 수 있다. 
    소프트웨어가 이해관계자의 필요와 요구사항을 충족시킬 가능성을 높일 수 있다. 

 1.2.2 품질 보증과 테스팅 (Quality Assurance and Testing)
   일반적으로 품질 보증은 적절한 품질 수준을 달성했는지 확신을 얻기 위해 
   적절한 프로세스를 준수하도록 하는 것에 초점을 두고 있다.
   프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한 경우가 많으며, 높은 작업 산출물 품질은 결함 예방에 도움 됨.
   결함의 원인을 찾아 제거하기 위한 근본원인분석(root case analysis)의 활용과 회고 회의(retrospective mettings)의 결과를
   적절히 활용해서 프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항들이다. 

   테스트 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부이다. 
   품질 보증에서는 전반적인 프로세스의 올바른 수행 여부에 관심을 가지기 때문에 올바른 테스팅의 적용에도 관심을 가진다. 
   테스팅은 품질을 높이는데 다양한 방법으로 기여한다. 


 1.2.3 오류, 결함, 장애 (Error, Defects, and failures)
  오류(error) : 실수
  대표적인 오류 발생 원인
    - 시간적인 압박
    - 사람의 실수 
    - 경험이 적거나 기술이 부족한 프로젝트 참여자
    - 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제 
    - 코드, 설계, 아키텍쳐의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도 
    - 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우 
    - 새롭고 익숙하지 않는 기술 

   결함(Defects)
    필요한 가능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점. 
    결함의 예는 부정확한 구문이나 부정확한 데이터 정의 등이다.
    실행 중에 결함이 발생할 경우, 컴포넌트나 시스템의 장애를 야기시킬 수 있다. 

    단 한줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다.
    제품 소유자가 이자 계산법을 잘못 이해해 작성한 애매모호한 사용자 스토리를 기반으로 코드가 잘못 작성 되었다. 
    대부분의 결함이 이자 계산식에 존재하며 해당 결함들의 근본 원인 역시 비슷한 오해로 인한 것이라며, 
    차후 유사한 결함의 발생 가능성을 낮추기 위해 제품 소유자에게 이자 계산에 대한 교육을 제공할 수 있다. 

    위의 내용에서 '잘못된 이자 지급' 은 장애이며, 
    코드에 포함된 '잘못된 계산식'은 결함 
    그것의 원인이 되는 최초 결함은 사용자 스토리의 모호성이다. 
    최초 결함의 근본 원인은 제품 소유자의 지식 부족이었으며, 
    그 결과로 제품 소유자가 '사용자 스토리를 작성할 때' 오류를 범했다고 볼 수 있다. 


   장애(Failures)
    장애는 코드 결함뿐만 아니라 환경 조건으로 인해 발생할 수도 있다. 
    ex. 방사능, 전자기장, 환경오염 등은 펌웨어 결함의 원인이 되거나 하드웨어 상태를 변화시킴으로써 영향을 줄 수 있다. 

    테스트 결과가 기대한 것과 다르다고 무조건 장애가 있다고 볼 수는 없다. 
    테스트 실행 방식의 오류나 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우, 
    또는 그 외 다양한 이유로 거짓양성(false positive)이 발생할 수 있다. 
    비슷한 오류나 결함이 거짓음성(false negative)의 원인이 되는 반대의 경우도 발생할 수 있다. 
    * 거짓 음성 : 테스트가 발견했어야 할 결함을 발견하지 못하는 경우
    * 거짓 양성 : 결함으로 보고됐지만 실제 결함이 아닌 경우를 말한다.