[ISTQB] 1장 - 테스팅의 기초(180분)

1.1 테스팅이란 무엇인가?

• 소프트웨어 테스팅은 결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동이다.
• 소프트웨어 테스팅은 테스트 수행 뿐만 아니라 다른 활동들이 포함되며, 이 활동은 소프트웨어 개발수명주기(SDLC)에 따라서 달라진다.
• 주어진 요구사항을 충족하는지 확인(verification)하는 활동 뿐만 아니라 사용자 또는 기타 이해관계자가 필요한 바를 만족하는지를 확인하는 검증(validation)도 포함된다.
• 기술적인 활동에 국한되지 않으며, 적절한 계획/관리/추정/모니터링/제어도 필요하다.

1.1.1 테스트 목적

• 일반적인 테스트 목적
  • 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가
  • 장애 유발 및 결함 식별
  • 테스트 대상에 필요한 커버리지 보장
  • 소프트웨어 품질 부족으로 인한 리스크 수준 완화
  • 정의된 요구사항의 충족 여부를 확인하는 베리피케이션
  • 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션
  • 이해관계자가 정보에 입각한 결정을 내리는데 필요한 정보 제공
  • 테스트 대상의 품질에 대한 자신감 획득
  • 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션

1.1.2. 테스팅과 디버깅

• 테스팅과 디버깅은 별개의 활동이다.
•  테스팅
  • 소프트웨어 결함으로 인한 장애를 유발하거나 테스트 대상에 있는 결함을 직접 식별한다.

• 디버깅
  • 장애(결함)의 원인을 찾고, 그 원인을 분석하고 제거한다.
  • 일반적인 디버깅 프로세스 : 장애 재현 -> 분석(근본 원인 식별) -> 원인 해결
• 확인 테스팅(confirmation testing)
  • 문제가 제대로 수정됐는지 확인한다.
  • 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직하다.
• 리그레션 테스팅(regression testing)
  • 수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하는 테스팅 방법
• 정적 테스팅
  • 정적 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는 데 중점을 둔다.
  • 장애를 유발하지 않고 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요가 없다.

1.2 테스팅이 왜 필요한가?

• 품질 제어 활동의 일환으로 테스팅은 정해진 범위, 시간, 품질, 예산 내에서 합의된 목표를 달성하는 데 도움을 준다.

1.2.1 성공을 위한 테스팅의 기여도

• 테스팅은 결함을 식별하는 비용 효율적인 방법이다.
• 식별한 결함은(테스팅 활동이 아닌 디버깅을 통해) 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.
• 소프트웨어 개발수명주기(SDLC)의 여러 단계에서 테스트 대상의 품질을 직접 평가하는 방법을 제공한다.
• 테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다.
• 계약 또는 법적 요구사항을 충족하거나 규제 표준 준수를 위해 테스팅이 필요할 수 있다.

1.2.2. 테스팅과 품질 보증(QA)

• 품질 보증(QA, Quality Assurance)과 테스팅은 다르다. 테스팅은 품질 제어(QC, Quality Control) 활동에 속한다.
• 품질 제어(QC)
  • 적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 제품 중심의 교정 접근법이다.
• 품질 보증(QA)
  • 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법이다.
• 테스트 결과는 품질 보증과 품질 제어 모두에 사용된다.
• 품질 제어는 결함을 수정하는 데 사용하며, 품질 보증은 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용한다.

1.2.3. 오류, 결함, 장애, 근본 원인

•  오류
  • 사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등 다양한 이유로, 또 단순히 피로하거나 충분한 훈련이 부족해서 오류를 범할 수 있다.
•  결함
  • 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물에서 나올 수 있다.
• 장애
  • 장애의 원인이 오류와 결함만 있는 것은 아니다.
• 근본 원인
  • 문제 발생의 근본적인 이유(예 : 오류로 이어지는 상황)를 말한다.
  • 근본 원인을 처리하면 유사한 장애나 결함을 예방하거나 그 빈도를 줄일 수 있다.

1.3 테스팅의 원리

1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.
2. 완벽한 테스팅은 불가능하다.
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
4. 결함은 집중된다. (소수의 시스템 컴포넌트에 집중되어 발생)
5. 테스트 효과는 줄어든다. (같은 테스트를 계속해서 반복하면)
6. 테스팅은 정황에 의존적이다. (모든 상황에 적용할 수 있는 테스팅 방법은 없다.)
7. 결함-부재는 궤변이다. (결함이 없다고 해서 완벽한 소프트웨어라고 할 수 없다.)

1.4 테스트 활동, 테스트웨어, 테스트 역할

• 테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다.
• 테스트 프로세스에 포함할 테스트 활동과 그러한 활동의 구현 방법과 수행 시기는 보통 해당하는 상황의 테스트 계획을 할 때 결정한다.

1.4.1 테스트 활동과 업무

• 테스트 계획
  • 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 것이다.
• 테스트 모니터링과 제어
  • 테스트 모니터링은 지속적으로 모든 테스트 활동을 점거하고, 실제 진행 상황을 계획과 비교하는 활동이다.
  • 테스트 제어는 테스트 목적을 달성하는 데 필요한 조치를 하는 활동이다.
• 테스트 분석
  • 테스트 분석은 측정할 수 잇는 커버리지 조건으로 “무엇을 테스트할 것인가?”라는 질문에 대한 답을 제공한다.
• 테스트 설계
  • 테스트 컨디션을 테스트 케이스와 기타 소프트웨어로 구체화하는 작업을 포함한다.
• 테스트 구현
  • 테스트 실행에 필요한 테스트웨어(예 : 테스트 데이터)를 만들거나 획득하는 작업을 포함한다.
• 테스트 실행
  • 테스트 실행 일정에 따라 테스트를 수행하는 것을 포함한다.
• 테스트 완료
  • 일반적으로 프로젝트 마일스톤에서 수행하며, 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.

1.4.2. 정황에 따른 테스트 프로세스

• 테스팅 수행 방식은 다음과 같은 여러 정황 요소에 따라 달라진다.
  • 이해관계자(필요, 기대, 요구사항, 협력, 의지 등)
  • 팀원(기술, 지식, 경험 수준, 가용성, 훈련 필요성 등)
  • 비즈니스 도메인(테스트 대상의 중요도, 식별된 리스크, 시장 요구사항, 구체적인 법적 규제 등)
  • 기술적 요인(소프트웨어 유형, 제품 아키텍처, 사용된 기술 등)
  • 프로젝트 제약 조건(범위, 시간, 예산, 자원 등)
  • 조직전 요인(조직 구조, 기존 정책, 적용한 실천법 등)
  • 소프트웨어 개발수명주기(SDLC)(공학적 실천법, 개발 방법론 등)
  • 도구(가용성, 사용성, 규정 준수 등)

1.4.3. 테스트웨어

• 테스트웨어는 1.4.1에서 설명한 테스트 활동의 결과물로 만들어진다.

1.4.4. 테스트 베이시스와 테스트웨어 간의 추적성

• 효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 개별 요소와 관련된 테스트웨어, 테스트 결과, 식별한 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.
• 좋은 추적성은 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 하고, 테스트 감사를 용이하게 하며, IT 운영 및 관리 기준을 충족하는 데 도움이 된다.

1.4.5. 테스팅에서의 역할

• 테스트 관리 역할
  • 테스트 프로세스, 테스트팀 그리고 테스트 활동 리더십에 대한 전반적인 책임을 지는 것이다.
• 테스팅 역할
  • 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다.
  • 테스팅 역할은 주로 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동에 초점을 둔다.

1.5 테스팅의 필수 기술 및 모범 사례

• 우수한 테스터는 팀플레이, 즉 협업에 능한 사람이어야 하며, 다양한 수준의 독립성으로 테스팅을 수행할 수 있어야 한다.

1.5.1 테스팅에 보편적으로 필요한 기술

• 테스터에게 요구되는 보편적인 기술
  • 테스팅 지식
  • 철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근
  • 우수한 의사소통 기술, 경청하는 자세, 팀플레이
  • 분석적 사고, 비판적 사고, 창의성(테스팅 효과를 높이기 위해)
  • 기술 지식(테스팅 효과를 높이기 위해, 예: 적절한 테스트 도구 사용)
  • 도메인 지식(최종 사용자/비즈니스 대표자를 이해하고 그들과의 소통을 위해)

1.5.2. 전체 팀 접근법(Whole team approach)

• 필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다.
• 예시
  • 비즈니스 담당 자와 협력해 적절한 인수 테스트를 작성
  • 개발자와 협력해 테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다.
  • 테스터는 테스팅 지식을 다른 팀원과 공유하게 되며, 제품 개발에 영향을 주게 된다.

1.5.3. 테스팅의 독립성

• 일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로테스터가 결함을 더 효과적으로 식별할 수 있도록 한다.
• 대부분의 프로젝트는 여러 수준의 독립성으로 테스팅을 수행하는 것이 가장 좋다.
• 독립적인 테스팅의 주요 이점
  • 배경, 기술적 관점, 편향이 다르기 때문에 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다.
• 독립적인 테스팅의 단점
  • 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며, 개발팀과 적대적인 관계로 이어질 수 있다.