**용어 설명**
베리피케이션(verification): 요구사항 충족/준수 여부 확인
밸리데이션(validation): 운영 환경에서 사용자가 필요한 바를 만족하는지 확인
동적 테스팅: 소프트웨어를 실행
정적 테스팅: 리뷰 + 정적 분석
확인 테스팅: 수정이 되었는지 확인하는 테스트
리그레션 테스팅: 수정으로 인한 새로운 장애가 있는지 확인하는 테스트1.1 테스팅이란 무엇인가?
소프트웨어 테스팅은 결함을 식별하고, 산출물의 품질을 평가하는 일련의 활동.
이 활동은 소프트웨어 개발수명주기(SDLC)에 따라서 달라진다.
테스터는 도구를 사용하지만, 테스팅은 주로 테스터가 전문 지식을 갖추고 분석 기술을 사용해 비판적 사고와 시스템적 사고를 적용하는 지적 활동이라는 점을 기억해야 한다.
1.1.1 테스트 목적
- 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가
- 장애 유발 및 결함 식별
- 테스트 대상에 대해 요구된 커버리지 보장
- 소프트웨어 품질 부족으로 인한 리스크 수준 완화
- 정의된 요구사항의 충족여부를 확인하는 베리피케이션
- 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션
- 이해관계자가 정보에 입각한 결정을 내리는데 필요한 정보 제공
- 테스트 대상의 품질에 대한 자신감 획득
- 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션
1.1.2 테스팅과 디버깅
테스팅과 디버깅은 별개의 활동이다.
테스팅
소프트웨어 결함으로 인한 장애를 유발하거나, 테스트 대상에 있는 결함을 직접 식별한다.
디버깅
동적 테스팅이 장애를 유발했을 때, 원인을 찾고 분석하고 제거한다.
일반적인 디버깅 프로세스
- 장애 재현
- 분석(근본 원인 식별)
- 원인 해결
이후 확인 테스팅을 수행하고, 리그레션 테스팅을 추가로 수행할 수 있다.
정적 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는데 중점을 둔다.
정적 테스팅에서는 장애를 유발하지 않고 직접 결함을 식별하기 때문에 장애을 재현하고 분석할 필요는 없다.
1.2 테스팅이 왜 필요한가?
- 정해진 범위, 시간, 품질, 예산 안에서 합의된 목표를 달성하는데 도움을 준다.
- 성공에 기여하는 테스팅이 테스트팀의 활동으로 국한된 것은 아니다.
- 모든 이해관계자는 자신이 가진 테스트 기술을 활용해 프로젝트 성공에 기여할 수 있다.
- 컴포넌트, 시스템, 관련 문서를 대상으로 한 테스팅은 소프트웨어 결함을 식별하는데 도움이 된다.
1.2.1 테스팅이 성공에 기여하는 법
테스팅은 결함을 식별하는 비용 효율적인 방법이다.
디버깅을 통해 식별한 결함은 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.
테스팅은 소프트웨어 개발수명주기의 여러 단계에서 테스트 대상의 품질을 직접 평가할 수 있는 방법을 제공한다.
평가결과는 프로젝트 관리 활동에 사용되며, 소프트웨어 개발수명주기 다음 단계로 넘어가는 것이 좋을지 판단하는 결정 등에 기여하게 된다.
테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다.
테스터는 개발수명주기 전반에 걸쳐 그들이 이해하고 있는 사용자 요구사항이 반영되게 한다.
계약 또는 법적 요구사항을 충족하거나, 규제 표준 준수를 위해 테스팅이 필요할 수도 있다.
1.2.2 테스팅과 품질 보증(QA)
품질 보증(QA, Quality Assurance): 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법.
품질 제어(QC, Quality Control): 적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 제품 중심의 교정 접근법. 테스팅은 품질 제어의 주요 활동
테스트 결과는 QA와 QC에 모두 사용됨.
QA는 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용.
QC는 결함을 수정하는데 사용.
1.2.3 오류, 결함, 장애
오류: 인간의 행위, 실수
코드 작성, 소프트웨어나 시스템 or 문서 작성 시 결함을 만드는 오류
결함: 요구된 기능의 부정확한 처리. 고장이나 장애를 발생시키는 원인이 됨
결함은 장애의 원인. 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 또 빌드 파일과 같은 지원 산출물에서 나올 수 있다.
But, 모든 결함이 장애를 발생시키는 것은 X
장애: 코드에 존재하는 결함의 실행 or 환경적 조건에 의해 부정확하게 처리되는 것
결함 + 환경적인(방사, 전자기장, 물리적 오염 등) 조건
근본 원인: 문제 발생의 근본적인 이유(오류로 이어지는 상황)
근본 원인 분석(root cause analysis)을 통해 식별하며, 보통 장애가 발생하거나 결함을 식별한 경우 수행한다.
근본 원인을 처리하면 유사한 장애나 결함을 예방하거나 빈도를 줄일 수 있다.
1.3 테스팅의 원리
**용어 설명**
테스트 기법: 무엇을 테스트할지, 어떻게 테스트할지 작업을 지원.
실러버스는 블랙박스, 화이트박스, 경험기반으로 분류하고 있다.
테스트 케이스 우선순위 지정
실러버스에서는 3가지 우선순위 지정법이 나온다.
리스크 기반, 커버리지 기반, 요구사항 기반 우선순위지정
리스크 기반 테스팅: 테스트 활동을 선택하고 우선순위를 정해 관리하는 테스트 접근법.
파레토 원리: 전체 결과의 80%는 20%의 원인 때문에 생긴다는 경험적 법칙
베리피케이션: 검증
검사하여 증명하는 것. 프로세스 개념에서 검증은 "개선사항을 실제 실행하기 전"으로 이해
밸리데이션: 검정
검사하여 정하는 것. 프로세스 개념에서 검정은 "개선사항을 실행한 후"로 이해7가지 테스트 원리
1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.
2. 완벽한 테스팅은 불가능하다.
완벽하게 테스트하려고 하기보다 테스트 기법, 테스트 케이스 우선순위 지정, 리스크 기반 테스팅을 사용해 테스트 노력을 집중해야 한다.
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
결함을 조기에 식별하기 위해 정적 테스팅과 동적 테스팅 모두 최대한 이른 시점에 시작해야 한다.
4. 결함은 집중된다.
대부분의 결함은 소수의 시스템 컴포넌트에 집중되어 발생하는 경향을 보인다.(파레토 원리의 예)
예상 결함 집중 영역과 실제로 테스트나 운영 중 관측한 결합 집중 영역은 리스크 기반 테스팅에서 중요하게 고려된다.
5. 테스트 효과는 줄어든다.
같은 테스트를 계속해서 반복하면, 신규 결함 식별 효과는 점점 줄어들게 된다.
이런 현상을 극복하기 위해 기존 테스트 케이스 및 테스트 데이터의 수정과 새로운 테스트의 작성이 필요할 수 있다. 그러나 자동 리그레션 테스팅처럼 같은 테스트를 반복하는 것이 유익한 경우도 있다.
6. 테스팅은 정황에 의존적이다.
모든 상황에 적용할 수 있는 하나의 테스팅 접근법은 없다. 정황에 따라 다르게 진행해야 한다.
7. 결함-부재는 궤변이다.
정의한 모든 요구사항을 철저히 테스트하고, 발견한 모든 결함을 수정하더라도 사용자의 요구나 기대에 못 미치거나, 고객의 비즈니스 목표 달성에 도움이 되지 않고 경쟁 시스템에 비해 부족한 시스템이 만들어질 수도 있다.
따라서 베리피케이션과 함께 밸리데이션도 수행해야 한다.
