#SQA 1. 테스트, 테스팅 기본 개념

SQA를 하다보면 품질 향상을 위해 하는 활동 중에 테스트 라는 활동이 있다

개인적이 견해로는 테스터 라는 말은 정말 시간 내에 테스트"만" 하는 단순 테스트 직무에 한정이 되더라도

그들을 결국 품질 향상을 위한 활동을 하고 있으므로 "Test Engineer" 라는 표현이 맞다고 생각한다.

 

테스트의 목적은 결함 검출, 품질 평가, 프로세스 개선으로 크게 보여진다.

 

1. 결함 검출과 제품 품질 개선 
2. 품질 평가와 의사 결정 지원
3. 개발 프로세스 개선 지원

 

소프트웨어를 개발할 때 동작 기준을 정의하는 "소프트웨어 요구사항" 이라는 것이 있다

여기에서 말하는 장애, 결함, 오류의 개념을 먼저 짚고 지나가야 한다

 

1. 장애(Failure) :  소프트웨어가 요구사항과 다르게 동작

• - 노트북에 동영상이 저장된 USB가 삽입되었을때, 저장된 동영상이 자동으로 재생된다. 라는 요구사항이 충족되지 않는현상이 장애 이다

2. 결함(Defect): 소프트웨어 내 장애를 유발할 수 있는 문제

• - 장애를 발생시키는 것은 부정확한 구현때문이거나 필요한 기능이 포함되지 않았기 때문일 수도 있다. 결함때문에 장애가 발생되지만, 결함이 있다고 장애가 반드시 발생되는 것은 아니다

3. 오류(Error): 결함이 생기게한 개발자의 행위

• - 요구사항을 오해하여 발생되는 실수나 오타 등이 있다

 

우리가 흔히 말하는 테스트 결과의 Fail 유형을 알아보았다면 조금 더 세부적으로 결함의 유형을 알아야 한다.

 

테스트를 하면서 결함을 효과적이고 효율적으로 검출하기 위해서는 대상 소프트웨어에 어떤 결함이 존재할 수 있는지 알아야한다.

결함의 유형은 크게 누락, 부정확한 구현, 비관련 이라는 세가지 유형으로 분류된다.

 

1. 누락(Omission): 요구명세에 명시된 요구사항이 시스템의 구현에 반영되지 않은 결함을 말함

• 요구명세에 'A'가 출력되어야 하나 출력되는 결과가 없는 경우
• 기능적인 것 뿐만 아니라 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락도 포함된다

2. 부정확한 구현(Incorrect): 요구 명세에 명시된 요구사항이 소프트웨어에 부정확하게 반영된 결함

• 요구명세에는 'A'가 출력되어야 하나 실제로 'A-a'가 출력되는 경우
• 기능적인 것 뿐만 아니라 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 부정확한 구현도 포함이다.

3. 비관련 결함(Extraneous): 요구 명세와 관련이 없는 결함

• 소스 코드에서 어떤 부분이 요구 명세에 언급된 기능·품질 등과 무관한 경우
• 당장 직접적인 장애를 유발하지 않을 수 있으나 불필요한 분석·테스트·관리의 노력을 유발하고 다른 결함을 초래하는 원인이 될 수 있다

 

하지만 결함의 발생이 모두 소스코드에서만 발생되는 것은 아니다.

 

전체 소프트웨어 주요 개발 단계별 결함 발생 비율을 보면 전체 결함의 35%가 코딩단계, 20%가 요구분석 단계, 25%가 설계단계에서 발생된다.

 

결함이 발생되었을 때 해당 단계에서 적절하게 검출하여 제거하지 않으면 이후 단계를 거쳐 소스 코드에 영향을 미쳐 결국엔 장애를 유발하게 된다.

 

그러므로 결함 해결에 소요되는 비용을 최소화하기 위해 각 개발 단계의 결과물을 테스트하여 해당 산출물에 존재하는 결함을 최대한 빨리 검출하고 제거해야 한다.

 

테스트와 관련된 용어로 디버깅(Debugging)이 있는데 종종 혼동하여 사용하는 경우가 있다.

 

테스트, 디버깅, 재테스트는 테스트 활동 중에 밀접한 관계를 맺는 용어들이다.

 

1. 테스팅

• 소프트웨어의 실제 동작과 요구사항과의 차이를 확인한다.
• 테스팅의 결과는 검출한 테스트 케이스와 테스트 환경이다.

2. 디버깅

• 테스팅을 통해 확인한 결함의 위치와 이를 제거하는 목적의 활동이다.

3. 재테스트(Re-test)

• 개발자가 디버깅 활동으로 코드를 수정하고 나면 결함이 제대로 제거되었는지 확인하기 위해 결함을 검출한 테스트 케이스를 이용하여 테스트를 다시 수행한다.

 

이러한 테스트 활동을 완벽하게 수행하는 것은 비현실적이다.

하나의 화면 혹은 하나의 소프트웨어에는 무수히 많은 기능들이 있어 결함을 검출하려면 많은 수의 테스트 케이스가 필요하고 테스트 데이터가 충분하지 않아 확인되지 않는 결함이 존재할 수 있다.

 

따라서, 테스트는 결함이 있음은 보여줄 수 있지만 결함이 없음은 보여줄 수 없다.

 

우리는 주어진 인력과 시간을 바탕으로 최대한 효과적이고 효율적으로 테스트를 수행해야 하고,

소프트웨어를 실행하는 방식으로 수행되는 동적 테스트에는 수없이 많은 경우의 수가 있으므로 효과적이고 효율적인 테스트 활동을 위해 끊임없이 개선해 나가야 한다.

 

• 동적 테스트에는 '동등 분할', '경계값 분석', '조합 테스트' 등 다양한 방법이 존재한다
• 위험기반 테스트 방법을 적용할 때는 위험 분석을 바탕으로 테스트할 범위를 선정하고 전략을 수립하여 한정된 비용과 일정 내에 테스트 효과를 최대화 할 수 있다

 

테스트 활동을 개선하는 과정에서 우리는 테스트 라는 용어의 개념이 어떻게 진화 되었는지 알아야 한다

*겔퍼린(Gelperin) 과 헤첼(Hetzel) 설명

 

레벨1 : 테스트와 디버깅에 뚜렷한 차이가 없는 레벨이다. 우연히 발견된 결함을 수정하는 디버깅에 중점을 둔다

레벨2 : 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다. 

레벨3 : 프로그램에 결함이 존재함을 보여주기 위해 테스트를 수행한다

레벨4 : 소프트웨어 개발 전 단계에서 발생하는 결함을 발견하는 개념이다. 개발 초기 단계부터 지속적인 리뷰등을 통해 평가하는 작업을 수행해야 한다

레벨5 : 아예 결함이 발생하지 않도록 사전에 방지하는 것이 목적이다. 테스트 케이스를 미리 설계하고 코딩을 나중에 하는 방식으로 시스템을 개발한다.