[ISTQB] PART 01. 소프트웨어 테스팅의 기초

1. 소프트웨어 테스팅이 왜 필요한가?

1.1 소프트웨어 시스템 관점에서 테스팅의 필요성

• 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용 -> 비중은 계속 증가
• 금전적인 손실 시간 낭비, 비즈닉스의 이미지 손상, 그리고 부상이나 사망에 이르기까지 다양하고 심각
• 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요

 

1.2 소프트웨어 결함

• 오류(error) : 인간의 행위, 실수 / 결함을 발생시키는 실수
  • 코드 작성, 소프트웨어나 시스템 또는 문서 작성시 결함을 만드는 오류
• 결함(defect) : 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨 / 코드 또는 작업 산물의 결점이나 버그
  • 시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호간의 연동
• 장애(failure) : 코드에 존재하는 결함의 실행 및 환경 조건(방사능, 오염등의 HW 변화)으로 인해 발생하는 눈에 확연히 띄는 문제
  • 결함 + 환경적인(방사능, 전자기장, 물리적 오염 등) 조건

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할수 있다.

 

1.3 소프트웨어 개발, 유지보수, 운영 시 테스팅의 역할

• 소프트웨어 개발 과정에서는 테스팅이 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석을 통해 정적으로 시작될 수 있으며 각각의 개발 단계에 대응하는 테스트 레벨에 따른 테스팅이 이루어짐
  • 테스트 레벨에 따른 테스팅은 소프트웨어의 품질을 높이고 소프트웨어가 고객에게 전달된 이후 결함이 발생할 가능성을 최소화
• 기존에 운영하던 소프트웨어 시스템이 유지보수 활동으로 변경 및 단종되거나 그 환경이 변했을 경우, 변경된 시스템의 대상에 대한 그리고 변경된 환경에서의 운영 테스팅이 요구됨
  • 변경으로 야기될 수 있는 결함과 그로 인해 발생 가능한 장애를 예방
• 테스팅은 계약상 요구조건들 또는 산업에 특화된 표준들을 만족시키기 위해서도 필요

 

 1.4 테스팅과 품질

• 발견된 결함이 극소수이거나 없다면 테스트 설계 및 실행이 정상적으로 진행되었다는 전제하에 소프트웨어 품질에 대한 확신을 가질 수 있음
• 올바르게 설계된 테스팅 -> 시스템의 전반적인 리스크 수준을 감소
• 테스팅이 결함을 찾아내고, 발견된 결함이 수정될 때 소프트웨어 시스템의 품질은 향상됨
• 품질 보증
  • 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보
  • 발견된 결함의 근본 원인에 대한 이해를 바탕으로 프로세스를 개선, 결함의 재발 방지를 통해 차후 시스템의 품질을 개선
• 개발 표준이나 교육 훈련, 결함 분석을 통한 품질 향상

 

1.5 테스팅, 얼마나 해야 충분한가?

적절한 테스팅 정도

• 리스크 수준을 고려
• 프로젝트 제약 사항
  • 기술적인 내용
  • 비즈니스
  • 제품
  • 프로젝트 리스크
  • 시간
  • 비용
• 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있 어 프로젝트 이해관계자들이 릴리즈 결정을 내릴 수 있도록 충분한 정보 제공

 

2. 테스팅이란 무엇인가?

• 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘
  • 정상 동작 여부 확인
  • 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인
  • 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달
• 초기 개발 산출물 -> 리뷰
• 테스트 케이스 작성 과정(결함 예방 활동)
• 다양한 테스팅 활동

 

테스팅과 디버깅

테스팅(테스터가 수행)

• SW 결함으로 인한 장애 찾기
• 동적 테스팅을 통해 장애의 발생을 보여줄 수 있음
• 테스팅은 결함 원인 식별 x
• 직접적인 예방 x 단지 결함의 존재를 찾는 것

디버깅(개발자가 수행)

• 장애의 원인을 찾고 분석하여 수정하여 결함 제거
• 디버깅은 결점의 원인이 되는 결함을 제거하는 활동

 

3. 테스팅의 일반적인 원리

1. 테스팅은 결함이 존재함을 밝히는 활동이고, 결함이 없음을 밝히는 활동이 아니다.
   • 잠재적으로 존재하는 결함을 줄임
   • 결함이 발견되지 않아도 완벽한 소프트웨어라는 뜻은 아니다.
2. 완벽한 테스팅은 불가능하다.
   • 한 프로그램 내에 내부 조건이 많음
   • 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
   • 이벤트 발생시 발생 순서에 대한 조합도 무수히 많음
   • 리스크에 따라 테스트 강도 높게 수행 -> 완벽히 하는 것보다는 우선순위를 만들어서 하자.
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
   • 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근
   • 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출
4. 결함은 집중된다.
   • 대대수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임
   • 결함의 집중은 운영상의 장애를 초래
   • 결함이 집중되는 부분을 리스트 분석을 통해 리스크를 완화하자.
5. 살충제 패러독스에 유의하라
   • 같은 테스트를 반복 실행하면 해당 테스트로는 결함을 발견할 수 없다.
   • 살충제를 계속 사용하다보면 면역이 생기듯이.
   • 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선
6. 테스팅은 정황(context)에 의존적이다.
   • 테스트는 정황에 따라 달라진다.
   • 테스팅은 도메인의 특성이나 범위, 법적규제등 다양한 상황에 맞게 한다.
7. 오류 부재는 궤변이다.
   • 테스터가 모든 가능한 결함을 발견하길 기대하지만, 불가능하다.
   • 많은 결함을 발견하고 수정했다고 해서 좋은 시스템은 아니다.
   • 개발된 소프트웨어가 사용자 요구수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음

 

4. 테스트 프로세스의 기초

테스팅을 효율적이고 효과적으로 실행하기 위해서는 테스트 계획, 테스트 케이스 설계, 테스트 수행 준비, 테스트 진행 상태 확인 및 평가 활동을 선행해야 함

 

테스트 프로세스 주요 활동

• 계획과 제어
• 분석과 설계
• 구현과 실행
• 완료 조건의 평가와 리포팅
• 테스트 마감 활동

 

테스트 프로세스

• 테스팅 관련 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성 요소를 엮어주는 역할
• 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크)을 제공

 

4.1 테스트 계획과 제어(통제)

테스트 계획 수립

• 테스트 목표와 임무를 달성하기 위해 이를 면밀히 확인하고 필요한 활동을 정의하는 것

주요 작업 내용

• 테스트 범위와 테스트를 위한 리스크에 대한 결정, 테스팅의 목적에 대한 식별
• 테스트 정책의 실현과 테스트 전략의 구현
• 테스트 접근 방법에 대한 결정
• 테스트에 필요한 리소스의 결정
• 테스트 분석과 설계 작업의 일정관리
• 테스트 구현, 실행 및 평가의 일정관리
• 테스트 완료 조건의 결정

 

테스트 제어

• 계획 대비 실제 진행 상황을 비교하는 지속적인 활동
• 테스팅을 제거하기 위해 프로젝트 내내 테스팅 활동을 모니터링
• 테스트 계획은 테스팅의 제어와 모니터링 활동으로 부터 받는 피드백 반영

주요 작업 내용

• 테스트 결과에 대한 측정과 분석
• 테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화
• 테스트 계획과의 차이를 교정하는 활동
• 테스팅의 진행과 변경에 대한 의사 결정 활동

 

4.2 테스트 분석과 설계

테스트 분석과 설계

• 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동

주요 작업 내용

• 테스트 베이시스 리뷰
• 테스트 대상 아이템 또는 제품, 명세, 동작과 구조의 분석을 통해 테스트 상황을 식별하고 우선순위 선정
• 테스트 케이스 설계와 우선순위 선정
• 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완
• 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별
• 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구의 식별

 

4.3 테스트 구현과 실행

테스트 구현과 실행

• 가장 효율적이고 효과적으로 테스트를 실행하기 위하여 테스트 케이스를 조합
• 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화
• 테스트 실행에 필요한 테스트 환경이 구축되어 있어야 함

주요 작업 내용

• 테스트 케이스의 개발, 구현과 우선순위 선정
• 자동화 테스트 스크립트 작성
• 테스트 하네스 준비
• 효율적인 테스트 실행을 위해 테스트 수트 생성
• 테스트 환경의 올바른 구축 여부 확인
• 계획된 순서에 의거하여 수동 또는 테스트 실행 도구로 준비된 테스트 프로시저를 수행
• 테스트 수행 결과를 기록해 두고, 테스트 중인 소프트웨어, 테스트 도구, 테스트웨어의 식별과 버전을 기록
• 예상 결과와 실제 결과를 비교
• 예상 결과와 실제 결과간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고
• 불일치의 원인을 알아내기 위해서 실제 결과나 현상을 분석
• 각각의 불일치를 조치한 결과를 확인하기 위해 테스트 활동을 반복

 

테스트 실행 중 발견할 수 있는 결함

• 기획 시 유입된 결함
  • 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 기타 결함
• 설계 시 유입된 결함
  • 설계의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 인터페이스 결함, 기타 결함
• 코딩 시 유입된 결함
  • 코드의 표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함
• 테스트 부족으로 유입된 결함
• 마무리 부족
• 팀간 의사소통 부족
• 코딩 실수

 

결함 심각도

• 치명적 결함(Critical) : 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠김, 데이터 손실 또는 변조
• 주요 결함(Major) : 기능 상실, 잘못된 기능, 주요 기능 오작동
• 일반 결함(Average) : 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스
• 사소한 결함(Minor) : 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스
• 개선 사항(Enhancement) : 에러는 아니지만 개선이 필요한 사항

* 결함 심각도가 가장 높다 해서 가장 먼저 수정해야하는 것은 아님

 

결함 우선순위

• 즉시 해결
• 주의 요망
• 대기
• 낮은 순위

 

4.4 테스트 완료 조건과 리포팅

완료 조건 평가

• 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가하는 활동

주요 작업 내용

• 테스트 실행 결과가 테스트 계획에 명시된 완료 조건을 만족하는지 확인
• 추가적인 테스트가 필요한지, 아니면 명세된 테스트 완료 조건을 변경 해야 하는지에 대한 평가 수행
• 이해관계자에게 배포할 테스트 요약 보고서 작성

 

리포팅

• 진행보고와 릴리즈 조언 및 최종보고 형태로 이루어지며 테스팅을 수행하면서 수집한 결함 및 테스트 진행 관련 데이터를 가공하여 메트릭으로 수치화하고 관련 정보를 표현하는 작업

주요 작업 내용

• 발견된 결함과 미해결 결함의 추이 및 우선순위
• 테스트 진척도
• 리스크 및 메트릭으로 실증된 조언
• 테스트 환경의 가용성
• 테스트 머버리지, 결함 발견 효과성/효율성, 품질 평가 결과, 결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수, 요구사항 별 테스트 일 수, 해결되지 않은 결함과 그 영향, 오랫동안 수정되지 않은 결함 분석 등

 

4.5 테스트 마감 활동

테스트 마감

• 완료된 테스트 활동에서 데이터를 수집하여, 테스트에서 발견된 사실 및 수치적 데이터와 함께 테스팅 경험과 테스트웨어를 종합하고 축적하는 활동
• 테스팅이 얼마나 체계적으로 수행되었는지 평가하고 향후 테스팅을 개선하기 위해 모범 사례를 모델로 테스트 프로세스를 심사(평가)
• 테스트 마감 활동은 소프트웨어 시스템이 출시되어 프로젝트가 완료되었을 때, 계획된 모든 마일스톤이 달성되었을 때, 유지보수 활동 중 추가 개발되거나 업데이트 된 부분이 출시 완료되었을 때 발생

주요 작업 내용

• 테스트 결과 마감
• 테스트웨어, 테스트 환경, 테스트 기반 설비를 차후에 사용할 것을 대비하여 마감하고 보관
• 테스트웨어를 유지보수 조직에 이관
• 테스트 프로세스 심사(평가) 및 개선 사항 제안
• 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈 분석

 

5. 테스팅의 심리학

독립성 확보

• 일정 수준의 독립성 확보는 소프트웨어 개발자가 자신이 작성한 소프트웨어에 대한 편향된 애착을 줄이는 것과 동시에 결함과 장애를 찾아내는데 보다 효율적이고 효과적

테스팅의 독립성

• 1단계 : 테스트 대상 소프트웨어의 개발자가 설계한 테스트
• 2단계 : (개발팀 내의) 다른 인원이 설계한 테스트
• 3단계 : 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가가 설계한 테스트
• 4단계 : 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적인 조직에 의한 인증, 아웃소싱)

 

테스트 동안 결함 식별 과정은 테스트 대상 제품이나 작성자에 대한 비판으로 해될 소지가 있음

• 이를 해소하기 위해 시스템에서 결함을 찾아내는 능력은 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발 팀 동료와의 원활한 소통, 결함을 유추해 내는 경험을 필요로 함

검증된 의사소통 방법

• 다툼보다는 협력으로 시작. 즉, 더 나은 품질의 시스템을 개발하고자 하는 공통적인 목표를 모든 사람에게 주지시킴
• 소프트웨어를 개발한 "사람"에 대한 비평을 배제, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력
• 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력
• 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인

 

---

 

📚 참고 문헌 : 개발자도 알아야할 소프트웨어 테스팅 실무