ISTQB_CTFL 핵심 정리

서론

   ISTQB 시험에 나오는 핵심 개념만 간추려서 정리를 해보았다. 핵심만 간추렸기에 개념 이해 부분은 이전 블로그나 복습을 하고 정리하는 것을 추천한다. 매번 실라버스가 업데이트되기에 홈페이지에서 현 버전의 실라버스와 문제 풀이를 푸는 것을 추천한다.

---

1단원

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

• 품질(QA, Quality Assurance)은 컴포넌트, 시스템, 프로세스가 명시된 요구사항은 물론 사용자와 고객의 필요와 기대를 충족시키는 정도이다.
  • 품질 보증과 테스팅은 다르다. 테스팅은 품질 제어(QC, Quality Control) 활동에 속한다.
  • 품질 제어은 제품 중심의 교정 접근법이다.
  • 테스팅은 품질 제어의 주요 활동이며, 정형 기법이다.
  • 품질 보증은 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법이다.
  • 품질 보증은 개발 및 테스팅 프로세스 모두에 적용되며, 프로젝트에 참여하는 모두의 책임이다.
  • 테스트 결과는 품질 보증과 품질 제어 모두에 사용된다.
  • 품질 제어는 결함을 수정하는 데 사용하며, 품질 보증은 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용한다.
• 오류(Error): 잘못 된결과를 낳는 인간의 행위, 실수와 동의어
• 결함(Degects, Bugs): 요구된 기능을 적절히 처리하지 못하는 것, 즉 장애를 방생시키는 요인이다. 일반적으로 버그, 결함, 결점은 동의어로 사용된다.
  • 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물 (supporting artifact)에서 나올 수 있다.
  • 개발 수명 주기 초기부터 결함 잡기 위해 정적 기법을 주로 사용한다.
  • 장애의 원인이 오류와 결함만 있는 것은 아니다.
• 장애(Failure): 코드에 존재하는 결함의 실행
  • 오류로 결함이 발생하고 결국 장애로 이어진다.
• 종료 조건: 현상황을 고려하여 미리 정해둔 기준을 모두 달성할 때 테스트가 종료하는 시점이다.
• 디버깅(Debug)은 테스팅과 다르다. 개발 영역
  • 테스팅은 소프트웨어 결함으로 인한 장애를 유발하거나(동적 테스 팅) 테스트 대상에 있는 결함을 직접 식별한다.(정적 테스팅)
  • 정적 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는 데 중점을 둔다.

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

• 테스팅은 결함을 식별하는 비용 효율적인 방법이다.
• 식별한 결함은(테스팅 활동이 아닌 디버깅을 통해) 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.
• 효과적인 테스트
  • 계획됐거나 원했던 테스트 결과 산출
  • 효과적인 테스터는 테스팅 노력으로부터 어떤 결과를 도출할 것인지 결정한다.
• 효율적인 테스트
  • 계획된 테스트를 생산적으로 수행한다.
  • 효율적 테스터는 가용한 리소스(시간, 자금, 인력)를 적절하고 현명하게 배치한다.
• 테스팅 활동은 결함 발견 및 예방과 대상 시스템의 품질을 향상시키고 개발 프로세스와 테스팅 프로세스를 개선하기 위한 정보를 제공한다.

테스팅이란?

• 테스팅은 결함이 존재함을 밝히는 활동이지만 결함이 없다는 것을 증명할 수는 없다.
• 확인 테스팅은 결함을 수정했는지 확인하는 테스팅이다. 수정 여부를 확인하기 위해 이전에 싶어했던 테스트를 실행한다.
• 리그레션 테스팅은 수정으로 인해 변경되지 않은 소프트웨어 영역에 의도하지 않은 새로운 결함이 유입되지 않았는지 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트한 프로그램을 다시 테스팅하는 것이다.
• 업데이트하지 않은 동일한 테스트를 반복해서 수행하면 더 이상 새로운 버그를 찾아내지 못할 수 있으므로 테스트케이스를 업데이트하고 보완하는 것은 유지보수 테스팅에서 매우 중요하다.

테스팅의 목적

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

테스팅의 일곱 가지 원리

• 테스팅은 결함이 존재함을 밝히는 활동이다. > 완벽
• 완벽한 테스팅은 불가능하다:모든 가능성을 테스팅하는 것은 아주 간단한 소프트웨어를 제외하고는 불가능하다.
• 개발 초기에 테스팅을 시작하라(조기 테스팅): 테스팅은 개발 초기에 시작해야 하며 결함은 주로 적은 수의 모듈에서 대다수 발견된다.
• 결함 집중: 출시 전 테스팅 기간 동안 적은 수의 모듈에서 대다수의 결함이 발견되거나 대다수의 운영상의 장애가 나타난다.
• 살충제 패러독스: 동일한 테스트를 반복 실행하면 더 이상 새로운 결함을 찾기 어렵다.
  • 자동 리그레션 테스팅처럼 같 은 테스트를 반복하는 것이 유익한 결과로 이어지는 경우도 있다.
• 테스팅은 정황에 의존한다: 테스팅은 정황에 의존적이므로 테스트 대상에 따라 다른 테스팅이 필요하다.
• 오류-부재의 궤변: 소프트웨어 베리피케이션이 시스템의 성공을 보장할 것이라고 기대하는 것은 잘못된 생각이다. 개발한 시스템이 사용자의 필요와 기대에 부응하지 못하고 쓸모없다면 결함을 찾는 활동도 의미 없다. 베리피케이션과 함께 벨리데 이션도 수행해야 한다.

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

• 테스트 계획(Test planning): 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 것이다.
• 테스트 모니터링과 제어(Test monitoring and control): 테스트 모니터링은 지속적으로 모든 테스트 활동 을 점검하고, 실제 진행 상황을 계획과 비교하는 활동이다.
• 테스트 분석(Test analysis): 테스트 베이시스를 분석해 테스트 가능한 기능을 식별하고, 관련된 테스트 컨디션을 정의하고, 우선순위를 정하는 활동이 포함되며, 이와 관련된 리스크와 리스크 수준도 같이 고려된다.
  • 테스트 베이시스와 테스트 대상을 평가해 결함을 식별하고, 테스트 용이성을 평가한다.
  • 커버리지 조건으로 “무엇을 테스트할 것인가?”
• 테스트 설계(Test design): 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(테스트 차터)로 구체화하는 작업을 포함한다.
  • 이 활동은 테스트 케이스 입력값을 구체화하는 데 도움이 되는 커버리지 항목의 식별을 포함하는 경우가 많다.
  • 테스트 설계는 “어떻게 테스트할 것인가?”
• 테스트 구현(Test implementation): 테스트 실행에 필요한 테스트웨어(테스트 데이터)를 만들거나 획득하는 작업을 포함한다.
  • 테스트 케이스는 테스트 절차(test procedure)로 묶을 수 있으며, 테스트 스위트(test suite)로 조합하는 경우도 많다.
  • 테스트 준비 도구가 지원하는 테스트 활동이다.
• 테스트 실행(Test execution): 테스트 실행 일정에 따라 테스트를 수행하는 것을 포함한다.
  • 실제 테스트 결과를 기대 결과와 비교한다.
  • 이상 현상을 분석해 가능한 원인을 파악한다.
• 테스트 완료(Test completion): 일반적으로 프로젝트 마일스톤(예: 릴리스, 반복 주기 완료, 테스트 레벨 완료)에서 수행하며, 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.
  • 테스트 환경은 합의된 상태로 종료하게 된다.
  • 테스트 활동을 분석해 향후 반복 주기, 릴리스, 프로젝트를 위한 교훈과 개선 사 항을 파악한다. 테스트 완료 보고서를 작성해 이해관계자에게 전달한다.
• 테스팅 수행 방식은 다음과 같은 여러 정황 요소에 따라 달라진다.
  • 이해관계자, 팀원, 비즈니스 도메인, 기술적 요인, 프로젝트 제약 조건, 조직적 요인, 소프트웨어 개발수명주기, 도구

테스팅에서의 역할

• 테스트 관리 역할
  • 전반적인 책임
  • 주요 관심 영역은 테스트 계획, 테스트 모니터링과 제어, 테스트 완료 활동이다.
• 테스팅 역할
  • 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다.
  • 은 주로 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동에 초점을 둔다.
• 시기에 따라 역할을 수행하는 사람이 달라질 수 있다.

테스트웨어

• 테스트웨어는 테스트 활동의 결과물로 만들어진다.
• 적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.
  • 테스트 계획 작업 산출물
    • 테스트 계획, 테스트 일정, 리스크 관리 대장(risk register), 시작 및 완료 조건.
    • 리스크 관리 대장은 리스크 발생 가능성, 리스크 영향, 리스크 완화 정보가 들어있는 리스크 목록이다.
    • 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건은 종종 테스트 계획서에 들어간다.
  • 테스트 모니터링과 제어 작업 산출물
    • 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보
  • 테스트 분석 작업 산출물
    • (우선순위가 지정된) 테스트 컨디션, (바로 수정하지 않았다면) 테스트 베이시스의 결함에 관한 결함 보고서
  • 테스트 설계 작업 산출물
    • (우선순위가 지정된) 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항
  • 테스트 구현 작업 산출물
    • 테스트 절차, 자동 테스트 스크립트, 테스트 스위 트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소.
  • 테스트 실행 작업 산출물
    • 테스트 로그, 결함 보고서
  • 테스트 완료 작업 산출물
    • 테스트 완료 보고서, 향후 프로젝트 또 는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서

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

• 추적성(traceability): 요구사항과 이와 연관된 테스트에서와 같이 문서나 소프트웨어에서 연관된 항목을 식별하는 능력
  • 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.
• 사용자 요구사항과 테스트 실행 결과 간의 추적성은 비즈니스 목표 대비 프로젝트 진행을 측정하는 수단을 제공한다.
• 효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 개별 요소와 관련된 테스트웨어, 테스트 결과, 식별한 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.
• 정확한 추적성
  • 커버리지 평가를 지원하며, 측정 가능한 커버리지 기준이 테스트 베이시스에 정의되어 있을 때 매우 유용하다.
  • 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 하고, 테스트 감사를 용이하게 하며, IT 운영 및 관리 기준을 충족하는 데 도움이 된다.
  • 테스트 진행 상황 및 완료 보고서에 테스트 베이시스 개별 요소의 상태를 명시하여 보고서를 더 쉽게 이해할 수 있게 한다.
  • 이해관계자에게 테스팅의 기술적 측면을 이해하기 쉬운 방식으로 전달하는 데 도움이 되기도 한다.

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

• 테스팅에 보편적으로 필요한 기술
  • 테스팅 지식, 도메인 지식, 기술 지식 등
• 전체 팀 접근법
  • 전체 팀 접근법에서는 필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다. 같은 공간을 사용하는 것(co-location)은 의사소통과 상호작용을 용이하게 하므로 팀원들은 작업 공간을 공유한다.
  • 팀 환경에서 효과적으로 일하고, 팀 목표에 긍정적으로 기여하는 능 력이다.
• 테스팅의 독립성
  • 일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다.
  • 외부 조직 > 팀 내 조직 > 개발자
•  독립적인 테스팅의 주요 이점
  • 배경, 기술적 관점, 편향이 다르기 때문에 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다는 점이다.
  • 독립적인 테스터는 시스템 명세를 작성하고 구현하는 과정에서 이해관계자의 가정을 검증하고, 그것에 대한 이의를 제기하거나 반증할 수 있다.
• 독립적인 테스팅의 단점
  • 독립적인 테스터는 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며, 개발 팀과 적대적인 관계로 이어질 수 있다.
  • 개발자가 품질에 대한 책임감을 잃을 수도 있다.
  • 독립적인 테스터가 병목으로 인식되거나, 출시 지연의 원인으로 비난 받을 수도 있다.

테스팅의 심리학

• 테스트 독립성은 테스팅이 개발로부터 얼마나 독립적인지를 나타낸다.
  • 아웃소스드 테스트 > 인소스트 테스트
  • 외부 독립적 테스터 > 특정 분야를 전문으로 하는 독립적 테스트 전문가 > 다른 소속의 독립적 테스터 > 조직 내 독립적 테스트팀 > 개발 조직 내 독립적 테스터 > 개발자
  • 독립성이 높은 테스트 단점 보완: 정보의 고립이 발생하지 않도록 개발 정보의 적절한 제공이 필요
• 다툼보다 협력을, '사람;에 대해 비평 없이 중립적, 이해, 친분 및 의사소통 개선

---

2단원

소프트웨어 개발 모델

• 수명주기
  • 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
  • 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.
  • 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
  • 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물의 초안이 나오는 즉시 리뷰에 참여한다.
  • 모델 선택 요소
    • 테스트 활동 범위 및 시기, 테스트 문서 상세화 수준, 테스트 기법 및 테스트 접근법 선택, 테스트 자동화 범위, 테스터의 역할과 책임
• 반복적 개발
  • 반복 주기마다 동작하는 프로토타입이나 제품 증분이 만들어진다고 가 정한다.
  • 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있음을 의미한다.
  • 증분을 자주 전달하려면 빠른 피드백과 광범위한 리그레션 테스팅이 필요하다.
  • 단위 테스트 프레임워크 도구를 이용해 개발 자가 테스트 주도 개발을 하는 것이 중요
  • 요구사항이 변경됐을 때 빠르게 반영할 수 있는 모델은 반복/점증 모델
  • ex) 에자일 개발 모델, 래셔널 통합 프로세스, 래피드 애플리케이션 개발, 프로토타이핑
• V모델(순차적 개발 모델)
  • 요구사항 > 분석 > 설계 > 구현 > 단위 테스팅 > 통합 테스팅 > 시스템 테스팅 > 인수 테스팅
  • 테스트 레벨은 주체도 다르고 테스트 목적도 다르며 독립적인 테스트 수명 주기를 가진다.
  • 테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여한다.
  • 실행 가능한 코드는 보통 개발 후반에 생성되므로, 동적 테스팅은 소프트웨어 개발수명주기(SDLC) 초기에 수행하기 어려운 경우가 많다.
• 베리케이션은 명세된 요구사항이 충족됐는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것이다.(ISO 9000)
• 컴포넌트 테스팅은 소프트웨어 단위 자체만을 테스팅하는 것
• 모듈간 연계성을 고려해 테스트하는 것은 통합 테스팅

소프트웨어 개발 주도를 위한 테스팅

• 테스트 주도 개발(TDD)
  • (광범위한 소프트웨어 설계 대신) 테스트 케이스를 통해 코딩 주도
  • 테스트를 먼저 작성하고, 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링 (refactoring)
• 인수 테스트 주도 개발(ATDD)
  • 시스템 설계 프로세스 중 인수 조건에서 테스트 도출
  • 테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성
• 행위 주도 개발(BDD)
  • 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현
  • 일반적으로 Given/When/Then 형태를 사용 이후 테스트 케이스는 자동으로 실행 가능한 테스트로 변환
• 향후 적용/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지 가능하다.

데브옵스(DevOps)와 테스팅

• 데브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하도록 시너지 창출을 목표로 하는 조직 차원의 접근법이다.
• 개발과 운영이 가진 생각의 차이를 줄임과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 조직문화의 변화가 필요하다.
• 이점
  • 코드 품질, 그리고 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.
  • 지속적 통합은 개발자가 컴포넌트 테스트 및 정적분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트-레프트 테스팅 접근법을 장려한다.
  • 안정적인 테스트 환경 구축을 촉진하는 지속적 통합(CI)/지속적 배포(CD)와 같은 자동화 프로세 스를 장려한다.
  • 비기능 품질 특성(성능, 신뢰성)의 가시성을 높여준다.
  • 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.
  • 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.
• 단점
  • 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.
  • 지속적 통합/지속적 배포 도구를 도입하고 유지보수해야 한다.
  • 테스트 자동화를 위한 추가 자원이 필요하며, 그것을 설정 및 유지보수하기가 어려울 수 있다.
• 데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 (특히 사용자 관점에서) 여전히 필요하다.

시프트-레프트 접근법

• 시프트-레프트는 테스트를 더 일찍 수행해야 한다는 것을 의미하지만(조기 테스팅), 그렇다고 소프트웨어 개발수명주기(SDLC) 후반의 테스트를 무시해도 된다는 의미는 아니다.
• 시프트-레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비 용의 절감을 기대할 수 있다.
• 형상 관리 프로세스를 구축하기 전에 테스트 스크립트 작성

회고 및 프로세스 개선

• 회고는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다.
• 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기 (SDLC) 모델에 따라 달라진다.
• 이점
  • 테스트 효과성
  • 테스트웨어 품질 향상
  • 팀의 결속 및 학습 향상
  • 테스트 베이시스 품질 개선
  • 개발과 테스팅 간의 협럽 개선

테스트 레벨

• 통합 테스트 접근법
  • 단위 간의 결합과 인터페이스를 중점적으로 검증한다.
  • ex) 하상향 통합, 상하향 통합, 백본 통합, 빅뱅 통합 등
• 테스트 레벨별로 서로 다른 테스팅 관점가 목적이 있다.
  • 개발 과정: 소프트웨어의 결함을 찾아내고 수정하기 위해 가능한 많은 장애의 원인을 발생시킨다.
  • 인수 과정: 예상된 대로 시스템이 동작하는지 확인하고 요구사항에 맞는지 확신을 얻는다.
  • 유지 보수 과정: 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입됐는지 확인한다.
  • 품질 평가: 신뢰성 또는 가용성과 같은 시스템의 특성을 평가한다.
• 테스트 환경 또는 시스템 정황에 다라 테스트의 독립성을 고려해 테스트 조직에서 테스트하지만 개발팀에서도 수행할 수 있다.
• 테스트 레벨은 다음과 같다.
  • 단위 테스팅(컴포넌트 테스팅)은 코드 레벨에서 또는 개발환경에서 개발자가 직접 수행한다.
    • 데이터 베이시스: 프로그램 프로세스, 테스트 하네스, 단위 테스트 프레임워크
  • 단위 통합 테스팅(컴포넌트 통합 테스팅)은 시스템, 시스템 구성요소, 소프트웨어 프로그램의 데이터, 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행한다.
    • 다양한 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행한다.
    • 통합 범위가 크면 클수록 장애 및 결함 대한 격리와 디버깅이 어려워져 리스크를 증가시킨다.
    • 상향식, 하향식, 빅뱅 등 통합 전략 접 근법에 따라 크게 달라진다.
  • 시스템 테스팅은 기능 및 비기능적 시스템의 요구 사항을 모두 포함한다.
    • 시스템 테스팅은 전체 시스템 및 제품의 동작을 실제 시스템과 유사하게 구성한 환경에서 테스팅하는 것으로 독립적인 테스트팁이 수행하는 경우가 대부분이다.
    • 시스템 간의 상호작용에 대한 테스트는 시스템 통합 테스팅이며 개발자가 코드레벨에서 수행하는 테스트 레벨은 단위 테스팅이다.(통합 테스팅도 코드 레벨에서 수행할 수 있다.)
    • 데이터 베이시스: 리스크 분석서, 요구사항 명세서, 비즈니스 프로세스, 유즈케이스, 시스템 동작 명세, 상호 작용 명세
  • 시스템 통합 테스팅은 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점을 둔다.
    • 시스템 통합 테스팅은 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.
  • 인수 테스팅은 시스템에 대한 확신을 갖기 위한 테스팅으로 결합을 발견하는 것이 주요 목적은 아니다.
    • 공장 인수 테스팅 == 알파 테스팅
      • 개발 조직 내에서 잠재 고객에 의해 수행된다.
    • 사이트 인수 테스팅 == 베타 테스팅
      • (실제 or 잠재)고객 또는 사용자가 자신의 업무환경에서 수행한다.
    • 주의! 최종 단계로 보기 어렵다.
    • 데이터 베이시스: 사용자 요구 사항
• 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려해 구분한다.
  • 테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할

테스트 유형

• 기능 테스팅은 문서화돼 있거나 테스터가 알고 있는 시스템의 기능과 특징을 근간으로 수행되며 모든 테스트 레벨에서 수행할 수 있다. 기능은 시스템이 수행하는 '그 무엇'을 의미한다.
  • 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것이다.
  • 기능 테스트에서 비기능 테스트를 도출하는 경우도 많다.
  • 블랙박스 테스팅과 관련, 주로 명세 기반 기법을 이용해 소프트웨어나 시스템 기능성에서 테스트 조건과 테스트 케이스를 도출한다.
  • 보안성 테스팅은 악의적인 코드와 같은 외부의 위협을 감지해 내는 것과 관련 있는 기능을 확인한다.(ISC/IES 9126)
• 비기능 테스팅은 소프트웨어 제품 특성 테스팅이라고도 하며 시스템이 '어떻게' 동작하는가를 테스팅한다.
  • 주요 목적은 비기능 소프트웨어 품질 특성을 확인하는 것이다.
  • 수명주기 초기에 시작하는 것이 바람직하다.
  • ex) 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 호환성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅, 인식성 테스팅 등
    • 부하 테스트란 실제 환경을 가정하고 일반적으로 요구사항에서 제시하는 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는지를 확인하는 테스티이다.
  • 비기능 소프트웨어 품질 특성을 다음과 같다.
    • 수행 효율성, 호환성, 유용성, 신뢰도, 보안, 유지 가능성, 이동성
• 가장 주요 품질 속성: 테스트 용이성! < 그러기 위해 사용자 요구사항, 모델을 분석, 검토, 평가해야 한다.
• 블랙박스 테스팅(명세 기반): 테스트 대상 외부에 있는 문서에서 테스트를 도출한다.
  • 주요 목적은 명세와 비교해 시스템의 동작을 확인하는 것이다.
• 화이트박스 테스팅(구조 기반): 내부 구조에서 테스트 도출한다.
  • 주요 목적은 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것이다.
•  모든 테스트 유형을 위한 테스트 컨디션과 테스트 케이스를 도출하기 위해 다양한 테스트 기법을 사용할 수 있다.

확인 테스팅 및 리그레션 테스팅

• 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다.
• 리그레션 테스팅은 이미 테스트된 프로그램이 테스팅을 반복하는 것으로 결함 수정 이후 변경으로 인해 유입됐거나 발견되지 않았던 다른 결함을 발견하는 것이다.
  • 반복적인 성향이 강하므로 자동화에 가장 적합하다.
  • 결함 마스킹은 어떤 이유로 결함이 가려져서 해당 결함을 발견할 수 없는 상태이다.
  • 영향도 분석은 소프트웨어의 어느 부분이 영향을 받을 수 있는지 보여준다.
  • 실패 > 성공
• 재테스팅(확인 테스팅)은 실행했던 테스트케이스를 다시 실행하는 테스팅이다. 주로 발견된 결함이 수정됐는지 확인하기 위해 실시한다.
  • 그러나 결함을 수정하는 데 시간이나 비용이 부족한 경우, 결함으로 생긴 장애를 재현하기 위한 절차를 거쳐 장애가 발생하지 않는지 확인하는 것만으로 확인 테스팅이 끝날 수도 있다.
  • 성공 > 성공, 신규
• 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확 인 테스팅과 리그레션 테스팅이 필요하다.

유지보수 테스팅

• 유지 보수 테스팅은 소프트웨어 시스템이 배포된 후에 수행한다.
  • 유지 보수성을 개선하기 위한 것
  • 이미 운영되고 있는 시스템에서 수행하며 소프트웨어나 시스템이 변경, 단종됐거나 마이그레이션 될 때 발생한다.
  • 변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기로 범위를 정함
• 주의! 유지보수성 테스팅과 다르다
  • 유지보수성 테스팅은 시스템 및 소프트웨어가 변경을 고려해 얼마나 잘 개발했는지 밝히는 테스팅이다.,
  • 일반적으로 유지보수성이 낮은 시스템은 작은 변경에도 취약해 이를 반영하려면 코드의 많은 부분을 수정하는 등 많은 재작업과 리소스를 투입해야 한다.
• 개발 중에 발생한 경우 확인 테스팅 또는 리그레션 테스팅 등을 수행한다.

---

3단원

정적 기법과 테스트 프로세스

• 동적 테스팅과 달리 정적 테스팅은 테스트 대상 소프트웨어를 실행하지 않아도 된다.
• 코드, 프로세스 명세, 시스템 아키텍처 명세, 기타 작업 산출물을 수동으로 또는 도구를 사용해 평가한다.
• 테스팅 목표는 품질 개선, 결함 식별, 또한 가독성/완전성/정확성/테스트 용이성/일관성과 같은 특성을 평가하는 것이다.
• 정적 테스팅은 베리피케이션과 밸리데이션 모두에 적용할 수 있다
• 정적 분석은 주로 구체적인 코드 결함을 식별하는 데 사용하지만, 유지보 수성과 보안을 평가하는 데도 사용한다.

정적 테스팅의 가치

• 조기 테스팅 원 리를 지킬 수 있게 한다.
• 동적 테스팅으로 식별할 수 없는 결함을 찾을 수도 있다.
• 정적 테스팅은 작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다.
• 정적 테스팅에 다양한 이해관계자가 참여하는 것이 권장된다.
• 리뷰를 구축하는 비용은 클 수 있지만, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 리뷰를 수행하지 않을 때보다 전체 프로젝트 비용이 훨씬 낮아지는 경우가 많다.
• 정적 분석은 동적 테스팅보다 효율적으로 코드 결함을 식별할 수 있으며, 대부분의 경우 결과적으로 코 드 결함이 줄고, 전반적인 개발 노력도 감소한다.

정적 테스팅과 동적 테스팅의 차이

• 정적 테스팅과 동적 테스팅은 서로를 보완한다.
• 비슷한 목적을 가지고 있지만, 다음과 같은 차이도 있다.
  • 정적 테스팅과 동적 테스팅(장애 분석을 통해) 모두 결함을 식별한다는 것은 같지만, 정적 테스 팅이나 동적 테스팅 중 한 가지로만 식별할 수 있는 결함 유형도 있다.
  • 정적 테스팅은 결함을 직접 식별하는 반면, 동적 테스팅은 장애를 일으킨 후 연관된 결함을 후 속 분석을 통해 찾아낸다.
  • 정적 테스팅은 거의 실행되지 않거나 동적 테스팅으로 도달하기 어려운 코드 경로에 있는 결함 을 더 쉽게 발견할 수 있다.
  • 정적 테스팅은 비-실행(non-executable) 작업 산출물에도 적용할 수 있지만, 동적 테스팅은 실행 가능한 작업 산출물에만 적용할 수 있다.
  • 정적 테스팅은 코드 실행에 의존하지 않는 품질 특성을 측정할 수 있고, 동적 테스팅은 코드 실행에 의존적인 품질 특성을 측정할 수 있다.
• 정적 테스팅을 통해 더 쉽게 적은 비용으로 식별할 수 있는 대표적인 결함은 다음과 같다.
  • 요구사항 결함, 설계 결함, 특정 유형의 코딩 결함, 표준 위반, 잘못된 인터페이스 명세, 특정 유형의 보안 취약성, 테스트 베이시스 커버리지의 차이 또는 부정확성

피드백과 리뷰 프로세스

이해관계자 피드백을 조기에 자주 받을 때의 이점

• 피드백을 조기에 자주 받으면 잠재적인 품질 문제를 조기에 파악할 수 있다.
• 소프트웨어 개발수명주기(SDLC) 전반에 걸쳐 이해관계자의 피드백을 자주 받으면 요구사항에 대한 오해를 방지하고 요구사항 변경을 조기에 이해하고 구현할 수 있다.

리뷰 프로세스 활동

• 작업 산출물이 너무 커서 한 번의 리뷰로 다룰 수 없는 경우도 많다.
• 전체 작업 산출물의 리뷰를 끝내 기 위해 리뷰 프로세스를 여러 번 수행할 수 있다.
• 공식적인 리뷰 절차: 계획 활동 > 시작 > 개별 준비 > 논의 및 분석(리뷰 미팅) > 수정 및 보고(재작업 > 후속 처리 확인)
• 결함 발견을 목적으로 둠
  • 공식적인 리뷰: 인스펙션 > 체크리스트, 기술적 리뷰 > 워크쓰루 > 비공식적 리뷰
  • 리뷰 공식성이 강하면 강할수록 참여자의 역할을 명확히 나누고 절차를 철저히 따른다.
    
    • 계획 활동: 역할 분담, 시작 및 종료 기준 정의, 검토할 문서와 범위 설정
    • 시작(리뷰 착수): 문서 배포, 목표/절차/문서에 대한 설명, 시작 기준(조건) 확인
    • 개별 준비: 잠재 결함 체크, 회의에서 제기할 질문과 의견 준비, 검토자는 식별한 모든 이상 사항, 권장 사항, 의문 사항을 기록한다.
    • 논의 및 분석(리뷰 미팅): 토론하고 기록함(공식적일 수록 상세하게)
      • 결함 기록 > 결함 처리 방안 제안 > 결함 여부 결정
    • 재작업: 발견한 결함 수정
    • 후속 추적: 발견된 결함이 처리됐는지 확인, 메트릭 수집 & 확인, 리뷰 종료 기준 확인

리뷰 역할에서의 역하로가 책임

• 중재자(리더, Moderator)
  • 리뷰를 계획하고 미팅을 진행
  • 문서의 리뷰를 리드
  • 리뷰어(검토자)의 다양한 관점과 의견을 조율(주요 임무)
  • 리뷰 미팅에 대한 준비를 했는지 검사
• 관리자(Manger)
  • 리뷰 실행 여부 결정 및 시간 할당하며 목적 달성 여부 확인
• 검토자(Reviwer)
  • 리뷰 대상에서 인시던트 발견하고 기술
  • 리뷰 실행
• 리뷰 리더
  • 리뷰에 참여할 사람을 결정하고, 리뷰 시간과 장소를 협의하는 등 리뷰에 대한 전반적인 책임을 진다
• 기록자(서기, Scriber or Recorder)
  • 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 문서화한다.
• 작성자(저자, Author)
  • 리뷰 대상 작업 산출물을 작성하고 수정
• 리뷰 미팅 참여자: 작성자, 기록자, 중재자, 검토자
• 설계 문서 리뷰 중 테스트 엔지니어가 가장 관심을 가지고 확인해야 할 것은 '테스트 용이성'
• 리뷰의 성공 요소
  • 리뷰 참여자들이 역할과 책임을 명확하게 한 후, 리뷰 프로세스에 따라 진행해야 한다.
  • 사람 관련 이슈와 심리적 측면을 고려해야 한다.
  • 리뷰도 리스크를 반영해 전략적으로 적용하려는 시도가 필요하다.

도구에 의한 정적 분석

• 정적 분석은 장애보다 결함을 발견한다. 그리고 테스트 대상 소프트웨어를 실제 실행하지 않는 상태에서 도구의 지원을 받아 수행한다.(정적 분석 도구)
• 정적 분석 도구를 통해 발견되는 전형적인 결함
  • 정의되지 않은 값으로 변수 참조
  • 모듈과 컴포넌트 간에 일관되지 않은 인터페이스
  • 사용되지 않는 변수
  • 사용되지 않는 코드
  • 코딩 표준 위반
  • 보안 취약성
  • 코드와 소프트웨어 모델의 구문 규칙 위반
• 정적 분석은 대부분 개발자가 수행한다.
• 다른 형태의 리뷰들은 개발자를 포함해 테스터, 이해관계자들로 구성해 수행할 수 있다.
• 데드코드를 찾아 제거하고 코드를 검토하는 작업은 인스펙션으로 가능하지만 주로 정적 분석에서 다룬다.

리뷰 유형

• 비공식 리뷰
  • 공식 절차 없음
  • 주요 목적 이상 사항 식별
  • 저비용 문서 및 코드 검토
  • 선택적 문서화
  • 선택적 페어 프로그래밍 or 기술 선임자가 설계와 코드 리뷰로 참여
  • 리뷰어에 따라 효과가 각양각색

• 워크쓰루
  • 작성자에 의해 진행됨
  • 시간 및 인원수 등 제약하지 않음
  • 미팅 전 준비 과정은 선택적
  • 제품에 대한 학습이나 요구사항에 대한 이해 등이 주요 목적, 밸리데이션하고 검토하는 목적
  • 품질 평가
  • 공식 & 비공식에서 사용할 수 있다.

• 기술적 리뷰의 주요 목적은 기술적 문제 해결에 초점을 맞춘 리뷰의 형태이다.
  • 기술적인 자격을 갖춘 리뷰어가 수행하고, 중재자가 리더가 된다.
  • 설계 및 소스코드를 리뷰하는데 적합하다.
  • 기술 문제에 대한 합의를 도출하고 결정을 내리는 것뿐만 아 니라, 이상 사항 식별, 품질 평가 및 작업 산출물에 대한 신뢰 구축, 새로운 아이디어 창출, 저 자가 개선할 수 있도록 동기를 부여하고 지원하는 것이 목적
  • 발견 절차 존재
  • 기술적 문제 해결
  • 적합성 검토
  • 문서화
  • 동료 또는 기술전문가, 중재자가 참여
  • 일관되고 정량적인 효과
  • 미팅 사전 준비 단계 거침
  • 이상적으로는 중재자가 미팅 주도
  • 체크리스트, 리뷰 리포트, 발견한 인시턴트 리스트, 경영층 참여 활용
• 인스펙션
  • 훈련된 중재자(리뷰 리더, 서기)가 주도
  • 정식적인 후속 프로세스 존재
  • 3~5명이 적절
  • 정해진 절차
  • 효과를 높이기 위해 검토자가 사전 준비
  • 메트릭(metrics)을 수집해 리뷰 프로세스를 포함한 전체 소프트웨어 개발수명주기(SDLC)를 개선하는 데 사용한다.
• 인스펙션과 워크쓰루의 주요 차이점은 누가 주도하냐!

• 위 기법들은 상호 보완적이어서 각 기법은 다른 종류의 결함을 효과적이고 효율적으로 발견할 수 있다.
• 하위 레벨 테스트는 단위 테스팅과 통합 테스팅을 의미한다.
• IEEE 1028 기준 리뷰 유형: 비공식 리뷰, 워크쓰루, 기술적 리뷰, 인스펙션, 매니지먼트 리뷰, 감사 등
  • 매니지먼트 리뷰는 프로젝트 진행 상황을 확인하고 상태를 평가하며 향후 조치에 대한 결정을 내릴 수 있도록 모니터링한다. 이는 프로젝트나 시스템에 직접적인 책임이 있는 관리자가 실시한다.
  • 감사는 매우 공식적인 절차가 있고 주목적은 독립적으로 프로세스, 규정, 표준의 준수 여부를 평가하는 데 있다.

리뷰의 성공 요소

• 명확한 목표와 측정 가능한 완료 조건을 정의한다. 참가자의 평가가 목적이 되어서는 절대 안 된다.
• 주어진 목표를 달성할 수 있으면서 작업 산출물 유형, 리뷰 참여자, 프로젝트 요구사항 및 정황에 맞는 리뷰 유형을 선택한다.
• 리뷰어가 개별 리뷰 또는 리뷰 회의(개최 시)에서 집중력을 잃지 않도록 작은 단위로 리뷰를 진행한다.
• 이해관계자와 저자에게 리뷰 피드백을 제공해 제품 및 활동을 개선할 수 있게 한다.
• 참가자가 리뷰를 준비할 수 있는 충분한 시간을 제공한다.
• 리뷰 프로세스를 관리층이 지원한다.
• 학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.
• 모든 참가자가 자신의 역할을 어떻게 충족해야 하는지 알 수 있도록 적절한 교육을 제공한다.
• 회의에 퍼실리테이션(facilitation)을 적용한다

---

4단원

테스트 기법

• 블랙박스 테스트 기법(명세 기반 기법): 내부 구조를 참조하지 않고, 테스트 대상의 명시된 동작에 대한 분석을 기반으로 한다.
  • 테스트 케이스는 소프트웨어 구현 방식에 의존하지 않는다.
  • 구현이 바뀌더라도 필요한 동작이 동일하다면, 테스트 케이스는 여전히 유효하게 된다.
• 화이트박스 테스트 기법(구조 기반 기법): 테스트 대상의 내부 구조와 처리에 대한 분석을 기반으로 한다.
  • 테스트 케이스는 소프트웨어 설계 방식에 의존하기 때문에 테스트 대상의 설계나 구현 이 끝난 후에 만들 수 있다
• 경험 기반 테스트 기법: 테스터의 지식과 경험을 테스트 케이스의 설계 및 구현에 효과적으로 활용하게 한다.
  • 이 기법의 효과성은 테스터의 능력에 따라 크게 달라진다
  • 경험 기반 테스트 기법은 블랙박스와 화이트박스 테스트 기법으로는 식별하지 못할 수 있는 결함을 찾을 수 있게 해 준다.
  • 경험 기반 테스트 기법은 블랙박스 및 화이트박스 테스트 기법을 보완한다.

블랙박스 테스트 기법

동등 분할

• 테스트 대상이 하나의 분할에 포함된 모든 요소를 동일한 방식으로 처리할 것이라는 가정하에 데이터를 분할 단위로 나눈다.
• 분할은 연속적이거나, 연속적이지 않을 수도 있으며, 정렬돼 있거나, 유한 또는 무한일 수도 있다. 분할은 서로 겹치지 않아야 하며, 값이 없는 공집합일 수는 없다.
• 유효한 값을 포함하는 분할을 유효 분할이라고 한다. 유효하지 않은 값을 포함하는 분할을 비유효 분할이라고 한다.
• 이 기법으로 100% 커버리지를 달성하려면 테스트 케이스로 각 분할을 최소 한 번씩 다뤄서 식별한 모든 분할이 실행되도록 해야 한다.
• 커버리지는 하나 이상의 테스트 케이스로 실행한 분할 수를, 식별한 총 분할 수로 나눈 값으로 측정하며 백분율로 표시한다.
• 분할 집합이 다수인 경우, 가 장 간단한 커버리지 기준을 이치 초이스 커버리지(Each Choice coverage)라고 한다.

경계값 분석

• 동등 분할의 경계 실행을 기반으로 하는 기법이다.
• 경계값 분석은 정렬된 분할에만 사용할 수 있다.
• 분할의 최솟값과 최댓값이 경계값이 된다.
• 경계값 분석에서 두 값이 같은 분할 에 속하는 경우, 둘 사이의 모든 값도 해당 분할에 속해야 한다.
• 두 개 선택(2-value) 경계값 분석
  • 각 경계값에 대해 두 개의 커버리지 항목을 도출한다.
  • 경계값과 인접 분할에 속한 가장 가까운 값이 커버리지 항목이다.
  • 두 개 선택 경계값 분석에서 100% 커버리지를 달성하려면, 테스트 케이스로 모든 커버리지 항목, 즉 식별한 모든 경계값을 실행해야 한다.
• 세 개 선택(3-value) 경계값 분석
  • 각 경계값에 대해 세 개의 커버리지 항목을 도출한다.
  • 경계값과 이웃한 양쪽의 값 모두가 커버리지 항목이다.
  • 세 개 선택 경계값 분석에서는 경계값이 아닌 커버리지 항목도 있을 수 있다.
  • 세 개 선택 경계값 분석에서 100% 커버리지를 달성하려 면, 테스트 케이스로 모든 커버리지 항목, 즉 식별한 경계값과 그 이웃 값을 실행해야 한다.

결정 테이블 테스팅

• 다중 조건 조합으로 달라지는 결과를 나타내는 시스템 요구사항이 제대로 구현되었는지 테스트하는 데 사용한다.
• 결정 테이블을 만들 때 조건들과 그에 따른 시스템의 동작 결과를 정의한다.
• 제한-입력(limited-entry) 결정 테이블은 모든 조건과 동작 결괏값을 부울값(Boolean value)으로 표시한다.
• 확장-입력(extended-entry) 결정 테이블 은 조건 및 동작 결괏값의 일부 또는 전부가 복수의 값을 취할 수 있다.
• 결정 테이블 테스팅에서 커버리지 항목은 실현 가능한 조건 조합을 가진 열이 된다.
• 이 기법으로 100% 커버리지를 달성하려면, 테스트 케이스가 이런 열을 모두 실행해야 한다. 커버리지는 실행된 열의 수를 실행 가능한 열의 총수로 나눈 값으로 측정하며 백분율로 표시한다.
• 강점
  • 조합을 포함한 모든 조건 조합을 식별하는 체계적인 방법을 제공한다는 점이다.
  • 누락되거나 모순되는 요구사항을 찾는 데 도움이 된다.
• 단점
  • 조건의 수에 따 라 규칙의 수는 기하급수적으로 늘어나기 때문에, 조건이 많으면 모든 결정 규칙을 실행하는 데 오랜 시간이 걸릴 수 있다.
  • 이런 경우, 실행해야 하는 규칙의 수를 줄이기 위해 결정 테이블을 최소화하거나, 리스크 기반 접근법을 사용할 수 있다.

상태 전이 테스팅

• 상태 전이 다이어그램은 가능한 상태와 유효한 상태 전이를 표시해 시스템 동작을 모델링한다.
• 전이는 하나의 이벤트에 의해 발생하며, 별도의 가드(guard) 조건이 있을 수 있다.(노드)
• 전이는 즉각적인 것으로 간주되며, 가끔 소프트웨어의 어떤 동작으로 연결되기도 한다.(간선)
• 상태 전이 다이어그램이나 상태 테이블을 기반으로 하는 테스트 케이스는 보통 일련의 이벤트 순서와 그 결과로 생기는 상태 변화로 표현된다.
• 모든 상태 커버리지(All state coverage)
  • 모든 상태 커버리지 100%를 달성하려면, 테스트 케이스로 모든 상태를 확인해야 한다. 커버리지는 확인한 상태 수를 상태 총수로 나 눈 값으로 측정하고 백분율로 표시한다.
  • 노드
• 유효 전이 커버리지(Valid transitions coverage, 0-스위치 커버리지)
  • 유효 전이 커버리지 100%를 달성하려면, 테스트 케이스가 모든 유효 전이를 실행해야 한다. 커버리지는 실행된 유효 전이 수를 총 유효 전이 수로 나눈 값으로 측정하며 백분율로 표시한다.
  • 유효 전이 커버리지 100%를 달성하면, 모든 상태 커버리지도 달성된다.
  • 테스트 케이스
• 모든 전이 커버리지(All transitions coverage)
  • 모든 전이 커버리지 100%를 달성하려면 테스트 케이스로 모든 유효 전이를 실행하고, 유효하지 않은 비유효 전이의 실행도 시도해야 한다.
  • 하나의 테스트 케이스에서 테스트하는 비유효 전이를 하나로 제한하면 결함 마스킹(fault masking) 즉 하나의 결함으로 인해 다른 결함을 식별하지 못하는 상황을 방지하는 데 도움이 된다.
  • 커버리지는 실행된 테스트 케이스로 수행하거나, 커버하려고 시도한 유효 및 비유효 전이 수를 총 유효 및 비유효 전이 수로 나눈 값으로 측정하며 백분율로 표시한다.
  • 모든 상태 커버리지는 일반적으로 모든 전이를 실행하지 않고도 달성할 수 있기 때문에, 유효 전이 커버리지보다 약하다.
  • 모든 전이 커버리지를 100% 달성하면, 모든 상태 커 버리지와 유효 전이 커버리지도 모두 보장된다.
  • 미션(mission)과 안전에 치명적인 소프트웨어의 경우, 이 것을 충족해야 할 최소 기준으로 삼아야 한다

화이트박스 테스트 기법

구문 테스팅과 구문 커버리지

• 구문 테스팅에서 커버리지 항목은 실행 가능한 구문이 된다.
• 목적은 코드 구문을 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다.
• 커버리지는 테스트 케이스가 실행 한 구문 수를 코드의 실행 가능한 구문 총수로 나누어 계산하며 백분율로 표시한다.
• 100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행했다는 것이 보 장된다.
• 그러나 테스트 케이스로 구문을 실행했다고 해서 결함이 반드시 식별되는 것은 아니다.

분기 테스팅과 분기 커버리지

• 분기는 제어 흐름 그래프에서 두 노드(nodes) 간 제어의 이동으로 테스트 대상에서 소스 코드 구문의 실행 가능 순서를 보여준다.
• 분기 테스팅에서 커버리지 항목은 분기이며, 목적은 코드의 분기를 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다.
• 커버리지는 테스트 케이스가 실행한 분기 수를 분 기 총수로 나눈 값으로 측정하며 백분율로 표시한다.
• 테스트 케이스로 분기를 실행한다고 해서 반드시 결함을 식별할 수 있는 것은 아니다.
• 분기 커버리지는 구문 커버리지를 포함한다.
• 100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성하지만, 그 반대의 경우는 성립하지 않는다.
• 간선

화이트박스 테스팅의 가치

• 가진 근본적인 강점은 테스트 중 전체 소프트웨어 구현을 고려하므로 소프트웨 어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 감지할 수 있다는 점이다.
• 소 프트웨어가 하나 이상의 요구사항을 구현하지 않는 경우, 화이트박스 테스팅으로 그것이 누락됐다는 결 함을 식별하지 못할 수 있다는 단점이 있다.

경험 기반 테스트 기법

오류 추정

• 오류 추정이란 테스터의 지식을 기본으로 오류, 결함, 장애 발생을 예측하는 데 사용하는 기법이다.
• 테스터의 지식
  • 과거 앱의 동작, 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형
  • 다른 유사 앱에서 발생한 장애 유형
• 결함 공격은 오류 추정을 구현하는 체계적인 접근법이다.
  • 이 기법은 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득해서 오류와 관련된 결함을 식별 및 노출하거나, 장애를 유발하는 테스트를 설계하도록 한다.
  • 이런 목록은 경험, 결함 및 장애 데이터 또는 소프트웨어에 문제가 생기는 원인에 관한 일반적인 지식을 기반으로 작성할 수 있다.

탐색적 테스팅

• 탐색적 테스팅에서는 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하 게 된다.
• 탐색적 테스팅에서 테스트를 체계적으로 수행하기 위해 세션 기반 테스팅을 사용하기도 한다.
• 테스터는 테스트 목적이 정의된 테스트 차터(charter)를 테스팅 지침으로 사용한다.
• 테스트 세션이 끝나면 보고가 이 어진다. 이때 테스터와 테스트 세션 결과에 관심이 있는 이해관계자 간의 토론이 이루어진다.
• 이 접근 법에선 테스트 목적을 상위 수준의 테스트 컨디션으로 취급할 수 있다.
• 탐색적 테스팅은 명세가 부족하거나 부적합할 경우, 또 테스트에 시간적 압박이 심할 때 유용하다.
• 탐색 적 테스팅은 다른 공식 테스트 기법을 보완하기에도 유용하다.
• 테스터가 풍부한 경험과 도메인 지식을 가지고 있고 높은 수준의 분석 기술, 호기심, 창의성 등 필요 기술을 갖춘 경우 탐색적 테스팅이 더욱 효과적일 수 있다
• 리소스가 제한적일 경우 경함 기반 기법 및 탐색적 테스팅 사용

체크리스트 기반 테스팅

• 체크리스트 기반 테스팅에서 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.
• 체크리스트는 경험, 사용자에게 중요한 것이 무엇인지에 대한 지식, 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 바탕으로 작성할 수 있다.
• 자동으로 점검할 수 있는 항목, 시작/종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안 된다.
• 체크리스트는 기능 및 비기능 테스트를 포함한 다양한 테스트 유형을 지원하기 위해 만들 수 있다.
• 시간이 지남에 따라 일부 체크리스트 항목은 점차 효과가 떨어질 수 있다.
• 체크리스트는 결함 분석을 기반으로 정기적으로 업데이트해야 한다. 하지만 체크리스트가 너무 길어지지 않도록 주의할 필요가 있다.

협업 기반 테스트 접근법

협업 기반 사용자 스토리 작성

• 사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.
• 3C
  • 카드(Card) - 사용자 스토리를 설명하는 매체
  • 대화(Conversation) - 소프트웨어 사용 방법에 대한 설명
  • 확인(Confirmation) - 인수 조건
• 협업 기반 사용자 스토리 작성은 협업을 통해 팀원들은 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 만들어서 전달할 것에 대한 공유된 비전을 얻을 수 있다.
• 좋은 사용자 스토리는 독립적(Independent)이고, 협상 가능(Negotiable)하고, 가치 있고(Valuable), 추정 가능(Estimable)하고, 작고(Small), 테스트 가능(Testable) 해야 한다(INVEST).
• 이해관계자가 사용자 스토리를 테스트하는 방법을 모른다면, 그 사용자 스토리가 명확하지 않거나 사용자에게 중요한 내용이 반영되어 있지 않거나, 이해관계자가 테스트를 수행하는 데 있어 도움이 필요하다는 것을 의미할 수 있다.

인수 조건

• 사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건이다.
• 인수 조건
  • 사용자 스토리 범위 정의
  • 이해관계자 간 합의 도출
  • 긍정과 부정 시나리오 설명
  • 사용자 스토리 인수 테스팅의 베이시스 제공
  • 정확한 계획 및 추정
• 조건 작성법
  • 시나리오 기반
  • 규칙 기반

인수 테스트 주도 개발(ATTD)

• 인수 테스트 주도 개발(ATTD, Acceptance Test-driven Development)은 테스트 우선 접근법이다.
• 테스트 케이스는 사용자 스토리 구현 전에 만들어진다.
• 고객, 개발자, 테스터 등 서로 다른 관점을 가진 팀원들이 테스트 케이스를 만든다.
• 테스트 케이스는 수동 또는 자동으로 실행할 수 있다.

---

5단원

기본 테스트 프로세스

• 테스트 프로세스의 순서: 계획/제어 > 분석/설계 > 구현/실행 > 완료조건 평가/리포팅 > 마감
• 테스트 계획 및 제어 활동
  • 계획 대비 진행상황 비교
• 테스트 분석 및 설계 활동
  • 테스트 베이시스 리뷰
    • 데이터 베이시스: 요구사항 분석서, 아키텍처, 개발 설계 문서, 인터페이스, 테스트 하네스(: 테스트 대상이 실행되는 환경을 시뮬레이션함으로써 컴포넌트나 시스템 일부에 대한 테스팅을 가능하게 한다.)
  • 테스트 데이터 정의
  • 테스트 환경을 설정하고 테스트에 필요한 기반 환경과 도구 정의
• 테스트 구현 및 실행 활동
  • 테스트 케이스 개발과 우선순위 선정
  • 테스트 스위트 작성
• 테스트 완료 조건 평가 및 리포팅 활동
• 테스트 마감 활동
  • 회고 및 테스팅 과정에서 교훈 분석
• 결함 심각도와 처리해야 할 결함의 우선순위를 별도로 구분해야 한다.
• 테스트 정책은 테스팅을 위한 관리 방침을 명확히 하는 최상위 수준의 문서이다.
  • 테스트 프로젝트 차원: 프로젝트 테스트 계획, 프로젝트 테스트 상태 보고서
  • 테스트 레벨 차원: 레벨 테스트 계획
• 테스트 프로세스 심사 모델: TMMi, TIM, TPI Next 등

테스트 계획

• 테스트 계획서는 테스트 프로젝트의 목적, 자원, 프로세스를 설명한다.
  • 테스트 목적 달성을 위한 방법과 일정을 문서화한다.
  • 수행한 테스트 활동이 정해진 기준을 충족하는 데 도움을 준다.
  • 팀원과 기타 이해관계자의 의사소통 수단으로 사용된다.
  • 테스팅이 수립한 테스트 정책 및 전략을 준수함을 보여준다
• 테스트 계획서는 보통 다음과 같은 내용을 포함한다.
  • 테스팅 정황
  • 테스트 프로젝트의 가정 및 제약 사항
  • 이해관계자
  • 의사소통
  • 리스크 목록
  • 테스트 접근법
  • 예산 및 일정

시작 조건과 완료 조건

• 시작 조건은 어떤 활동을 수행하기 위한 전제 조건을 정의한다.
  • 자원의 가용성
  • 테스트웨어 가용성
  • 테스트 대상의 초기 품질 수준
• 완료 조건은 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항을 정의한다.
  
  • 충분함에 대한 측정(커버리지, 해결되지 않은 결함 수, 결함 밀도, 실패한 테스트 케이스 수)
  • 종료 기준(계획된 모든 테스트 실행, 정적 테스트 수행, 발견한 모든 결함 보고, 모든 리그레션 테스트 자동화 완료)
  • 시간 및 예산의 소진도 유효한 완료 조건으로 볼 수 있다.
  • 이해관계자들이 추가 테스트 없이 배포하는 리스크를 검토하고 수용했다면, 다른 완료 조건이 충족되지 않더라도 테스트를 종료할 수 있다.
• 시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며 테스트 목적에 따라 달라진다.
• 애자일 소프트웨어 개발에서 완료 조건을 완료의 정의라고 하는 경우가 많으며, 릴리스 가능 항목에 대한 팀의 목표 메트릭을 정의하게 된다.
• 개발 및 테스트 활동을 시작하기 위해 사용자 스토리가 충족해야 하는 시작 조건을 준비의 정의라고 한다.

추정 기법

• 테스트 노력 추정은 테스트 프로젝트의 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것이다.
• 추정치는 여러 가정을 기반으로 하며, 추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확히 이해하도록 하는 것이 중요하다.
• 보통은 규모가 큰 작업보다 작은 작업에 대한 추정치가 정확하다.

비율 기반 추정(Estimation based on ratios)

• 메트릭 기반 기법으로 조직에서 수행한 이전 프로젝트 수 치를 수집해 유사 프로젝트를 위한 “표준” 비율을 도출한다.

외삽법(Extrapolation)

• 메트릭 기반 기법으로 현재 프로젝트에서 데이터 수집을 위해 가능한 한 빨리 측정을 수행한다.
• 반복적 소프트웨어 개발수명주기 (SDLC)에 매우 적합

와이드밴드 델파이(Wideband Delphi)

• 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정
• 각 전문가는 독립적으로 노력을 추정한다.
• 플래닝 포커(Planning Poker)는 애자일 소프트웨어 개발에서 많이 사용하는 와이드밴드 델파이의 변형이다.

3점 추정(Three-point estimation)

• 가장 낙관적인 추정치(a), 확률적으로 가장 높은 추정치(m), 가장 비관적인 추정치(b)
• 최종 추정 치(E)는 이들의 가중 산술 평균
• E=(a+4*m+b)/6

테스트 케이스 우선순위지정

• 테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다.
• 리스크 기반 우선순위지정: 리스크 분석 결과에 따라 테스트 실행 순서를 결정한다. 가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행한다.
• 커버리지 기반 우선순위지정: 테스트 실행 순서를 커버리지에 따라 결정한다. 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행한다. “추가 커버리지 우선순위지정”이라는 다른 변형에서는, 가장 높은 커버리지를 달성하는 테스트 케이스가 먼저 실행된다; 이후에 실행되는 각각의 테스트 케이스는 가장 높은 추가 커버리지를 달성하는 것이다.
• 요구사항 기반 우선순위지정: 테스트 실행 순서를 해당 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정한다. 요구사항의 우선순위는 이해관계자가 정의한다. 가장 중요한 요 구사항 관련 테스트 케이스를 먼저 실행한다.
• 테스트 케이스 또는 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.
  • 우선순위 높은 테스트 케이스가 우선순위 낮은 테스트 케이스에 종속되는 경 우, 우선순위가 낮은 테스트 케이스를 먼저 실행해야 할 수도 있다.

테스트 피라미드

• 테스트 피라미드는 테스트에 따라 입도(granularity)가 다를 수 있다는 것을 보여주는 모델이다. 
• 하위 테스트 레벨에서의 더 많은 테스트 수행을 강조
• 일반적으로 단위 테스팅과 단위 통합 테스팅은 API 기반의 도구로 자동화한다.
• 시스템 테스팅과 인수 테스팅의 경우, 자도오하 테스트는 보통 GUI 기반 도구로 생성한다.

테스팅 사분면

• 1 사분면(기술 측면, 팀 지원)
  • 이 사분면은 컴포넌트 및 컴포넌트 통합 테스트를 포함한다. 이런 테스트는 자동화해야 하며, 지속적인 통합(CI) 프로세스에 포함돼야 한다.
• 2 사분면(비즈니스 측면, 팀 지원)
  • 이 사분면은 기능 테스트, 예제, 사용자 스토리 테스트, 사용자 경험 프로토타입, API 테스팅, 시뮬레이션 등을 포함한다. 이런 테스트는 인수 조건을 확인하며, 수동으로 실행하거나 자동화할 수 있다.
• 3 사분면(비즈니스 측면, 제품 평가)
  • 이 사분면은 탐색적 테스팅, 사용성 테스팅, 사용자 인수 테스팅을 포함한다. 이런 테스트는 사용자를 중심으로 이루어지며, 수동으로 실행하는 경우가 많다.
• 4 사분면(기술 측면, 제품 평가)
  • 이 사분면은 스모크 테스트와 비기능 테스트(사용성 테스트 제외)를 포함한다. 이런 테스트는 자동화되는 경우가 많다.

리스크 관리

• 주요 리스크 관리 활동은 리스크 분석과 리스크 제어이다.
• 리스크 분석과 리스크 제어를 기반으로 테스트 활동을 선택하고 우선순위를 정해 관리하는 테스트 접근 법을 리스크 기반 테스팅이라고 한다.

리스크의 정의와 리스크의 속성

• 리스크는 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황을 말한다.
• 리스크 발생 가능성 - 리스크 발생 확률
• 리스크 영향(피해) – 발생했을 때 생기게 될 피해
• 리스크 수준은 리스크를 측정한 값이 된다.
• 리스크 수준이 높을수록 그에 대한 조치 또한 중요해진다.
  • 리스크 영향도와 리스크 발생 가능성은 독립적이다.

프로젝트 리스크와 제품 리스크

• 프로젝트 리스크는 프로젝트 관리 및 제어와 관련이 있다.
  • 조직 문제
  • 인력 문제
  • 기술적 문제
  • 공급업체 문제
• 제품 리스크는 제품 품질 특성과 관련이 있다.
  • 누락, 잘못된 기능, 부정확한 계산, 런타임 오류, 열악한 아키텍처, 비효율적인 알고리즘, 부적절한 응답 시간, 열악한 UX, 보안 취약점 등

제품 리스크 분석

• 제품 리스크 분석의 목표는 제품 리스크를 인식해 잔존 제품 리스크 수준을 최소화하는 방향으로 테스트 노력을 집중할 수 있도록 하는 것이다.
• 제품 리스크 분석은 소프트웨어 개발수명주기 (SDLC) 초기에 시작하는 것이 이상적이다.
• 리스크 평가 리스크 수준은 리스크 발생 가능성과 리스크 영향을 곱한 값으로 계산
  • 리스크 수준 = 리스크 발생 가능성 * 리스크 영향

제품 리스크 제어

• 제품 리스크 제어는 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치를 말한다.
• 리스크 완화는 리스크 평가 때 제안된 조치를 실 행해 리스크 수준을 낮추는 활동을 말한다.
• 리스크 모니터링의 목적은 리스크 완화 조치가 효과적인지 확인하고, 또 리스크 평가 개선을 위해 추가로 필요한 정보를 확보하고, 새롭게 나타난 리스크를 식별하는 것이다.
• 테스팅으로 제품 리스크 완화를 위해 취할 수 있는 조치는 다음과 같다.
  • 주어진 리스크 유형에 적절한 경험과 기술을 갖춘 테스터 선정
  • 적절한 수준의 테스팅 독립성 적용
  • 리뷰 및 정적 분석 수행
  • 적절한 테스트 기법 및 커버리지 수준 적용
  • 영향을 받는 품질 특성을 다루는 적절한 테스트 유형 적용
  • 리그레션 테스팅을 포함한 동적 테스팅 수행

테스트 모니터링, 테스트 제어, 테스트 완료

• 테스트 제어에서는 테스트 모니터링에서 얻은 정보로 가장 효과적이고 효율적인 테스팅을 위한 제어 지침/ 지도/필요 수정 조치 등을 제공한다.
• 테스트 완료 활동은 어떤 프로젝트 마일스톤에 도달했을 때 이루어진다.

테스팅에 사용하는 메트릭

• 프로젝트 진행 상황 메트릭(작업 완료율, 자원 사용률, 테스트 노력 투입률)
• 테스트 진행 상황 메트릭(테스트 케이스 구현 진행률, 테스트 환경 준비 진행률, 실행/미실행 및 합격/불합격 테스트 케이스 수, 테스트 실행 시간)
• 제품 품질 메트릭(가용성, 응답 시간, 평균 장애 시간)
• 결함 메트릭(발견/수정한 결함의 수와 우선순위, 결함 밀도, 결함 발견 비율)
• 리스크 메트릭(잔여 리스크 수준)
• 커버리지 메트릭(요구사항 커버리지, 코드 커버리지)
• 비용 메트릭(테스팅 비용, 조직의 품질 비용)

테스트 보고서의 목적, 내용, 대상

• 일반적으로 테스트 진행 상황 보고서는 정기적으로 작성하며 다음을 포함한다.
  • 테스트 기간, 테스트 진행 상황, 테스팅 진행 방해 요소와 대응 방법, 테스트 메트릭, 테스팅 중 식별한 신규 및 변경된 리스크, 다음 주기에 예정된 테스팅
• 테스트 완료 보고서
  • 테스트 요약, 원래 테스트 계획, 테스트 계획과의 편차, 테스팅 방해 요소와 대응 방법, 테스트 진행 상황 보고서를 기반 한 테스트 메트릭, 완화되지 않은 리스크, 수정되지 않은 결함, 테스팅 관련 교훈

테스팅 상황 전달

• 대화, 대시보드, 전자 통신 채널, 온라인 문서, 공식 테스트 보고서

형상 관리

• 형상 관리(CM, Configuration Management)는 테스트 계획서, 테스트 전략서, 테스트 컨디션, 테스트 케이스, 테스트 스크립트, 테스트 결과, 테스트 로그, 테스트 보고서와 같은 작업 산출물을 형상 항목으로 식별, 제어, 추적하는 지침을 제공한다.
• 복잡한 형상 항목의 경우 형상 관리는 구성 항목, 항목 간 관계, 버전 등을 기록한다. 형상 항목이 테스팅용으로 승인되면 베이스라인이 되며, 공식적인 변경 제어 프로세스를 통해서만 수정할 수 있다.
• 테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다.
  • 테스트 항목(테스트 대상의 개별 부분)을 포함한 모든 형상 항목에는 고유한 식별자가 부여되고, 버전이 관리되며, 변경사항이 있는지 추적되고, 다른 형상 항목과 가지는 연관성이 식별돼 테스트 프로세스 전체에서 추적성이 유지된다.
  • 식별된 모든 문서와 소프트웨어 항목은 테스트 문서에서 명확히 참조된다.

결함 관리

• 테스트의 주요 목적 중 하나가 결함 식별이므로 잘 확립된 결함 관리 프로세스가 필요하다.
• 결함 관리 프로세스에는 기본적으로 개별 이상 현상을 발견부 터 종료까지 처리하는 작업 흐름(workflow)과 분류규칙이 포함되어야 한다.
• 이 프로세스는 관련된 모든 이해관계자가 따라야 한다. 정적 테스팅(특히, 정적분석)에서 식별한 결함도 비슷한 방식으로 처리하는 것이 좋다.
• 결함 보고서 목적
  • 결함을 처리 및 해결하는 책임을 진 사람에게 문제 해결을 위한 충분한 정보 제공
  • 작업 결과물의 품질을 추적할 수 있는 수단 제공
  • 개발 및 테스트 프로세스 개선을 위한 아이디어 제공
• 결함 보고서
  • 고유 식별자, 보고하는 이상 현상을 요약하는 제목, 이상 현상이 관찰된 날짜, 보고 주체 조직, 작성자(역할 포함),  테스트 대상 및 테스트 환경 식별 정보, 결함의 정황, 이상 현상을 발견한 절차, 관련 테스트 로그, 데이터베이스 덤프, 스크린샷, 녹음 파일 등 장애의 재현 및 해결에 필요한 정보, 기대 결과와 실제 결과, 결함이 이해관계자의 이익 또는 요구사항에 끼치는 영향의 심각도, 수정 우선순위, 결함 상태, 참조 사항

---

6단원

테스트 도구의 종류

• 테스트 도구 분류는 테스트레벨, 개발 수명주기, 테스트 프로세스(수명주기)를 고려한다.
• 테스트 도구 분류에서 테스트 프로세스 전반에 걸쳐 사용하는 도구는 테스트 관리 도구이다.
• 주로 테스트팀이 사용하는 틀 중심이나 정적 분석 도구, 커버리지 도구 등 개발팀에서 사용하는 도구도 일부 있다.
• 한 가지 도구가 여러 분류의 테스트를 자동화하는 데 사용한다.
• 테스트 관리 도구를 이용해 테스트 결과를 기록하고 테스트 진행 상황에 대한 리포트를 생성할 수 있다.
• 정적 분석 도구의 주요 목적: 코드에 대한 이해 지원, 구조와 의존관계 분석, 코딩 표준을 지키도록 한다.
• 리뷰 도구의 목적: 코드 리뷰 프로세스 정보를 저장한다.
• 컴포넌트 데스트나 통합 테스트 중에 개발자에게 유용한 도구
  • 정적 분석 도구, 모델링 도구, 테스트 하네스/유닛 테스트 프레임웍 도구, 커버리지 측정 도구, 동적 분석 도구
• 테스트 데이터 준비 도구는 테스트 설계 시 사용한다.(테스트 실행 전)
• 테스트 실행과 로깅을 지원하는 도구
  • 테스트 비교자, 커버리지 측정 도구, 단위 테스트 프레임웍 도구
• 소프트웨어를 실행하지 않고 코드를 분석해 메모리 누수를 발견하는 도구는 정적 분석 도구이다.

효과적인 도구 사용: 잠재적인 도구의 가치와 위험

• 테스트 자동화 도구
  • 도입하는 것이 테스팅의 효율성을 높이기 위한 것이다.
  • 반드시 전체적인 테스팅 시간이 줄어드는 것은 아니다.
  • 상황에 따라 도구가 통해 중대하고 지속 가능한 성과를 얻기 위해 시간과 노력을 투자해야 하는 것이 필요하다.
  • 스크립트 유비 보수해야 하는 경우나 테스터가 도구에 대한 지식이 부족할 경우에는 시간 단축이 어려울 수 있다.
• 자동화 도구 도입 시 도구를 유지 보수하는 데 필요한 노력도 고려하는 것이 좋다.
  • 도구에 대한 비현실적 기대, 도구 도입 초기에 필요한 시간, 비용, 노력 과소평가, 도구에 대한 지나친 의존
• 정적 분석 도구를 사용하는데 가장 큰 어려움은 정적 분석 도구가 발견하고 출력하는 경고 메시지가 지나치게 많다. 그래서 이를 잘 관리하는 것이 필요하다.
• 결함 관리 도구는 테스트 측면이 강하다.
• 테스트 관리 도구는 테스트 실행 도구, 성능 테스팅 도구 등 다른 테스팅 도구에서 실행할 테스트케이스나 스크립트를 관리한다.
• 정적 분석 도구는 다른 도구에 비해 상대적으로 도입 성공 확률이 높아 자동화 도입 시 가장 먼저 고려할 수 있는 도구이다.
• 거의 모든 테스트 활동에 여러 유형의 테스트 도구가 있다.
• 변경 부분이 심한 부분에 대해 자동화 도구가 사용하는 것은 적절하지 못하다.
• 키워드 주도 방식은 스크립트 언어에 익숙하지 않은 테스터 또는 비즈니스 분석가라도 테스트할 애플리케이션의 전체 또는 부분집합으로 생성된 키워드를 사용해 테스트를 정의하고 수행할 수 있다.
• 테스트 자동화는 결함 발견율이 높아져 테스트의 효과성을 확보하기보다 테스트의 효율성을 높이는 데 기여한다.

도구 도입

• 자동화 도구를 도입할 때에는 현 프로세스나 업무에 도구를 어떻게 적용할 수 있는지 평가하고, 적용을 위해서 현 프로세스나 업무의 무엇을 변경해야 하는지 결정해야 한다.
• 테스트 관련 도구 도입 시 제일 먼저 도구 도입 프로세스를 수립한다.
• 같은 도구라도 조직마다 테스트 자동화에 대한 요구사항이 다를 수 있다.
• 다른 팀에서 효과를 본 도구라도 도입하려는 팀과 주요 프로젝트의 특성, 팀의 테스트 성숙도에 따라 도입해야 할 도구는 다를 수 있다.
• 테스트 관리 도구는 요구사항 추적과 누락을 방지하고 요구사항과 추적성이 있는 테스트케이스를 실행할 때 발견하는 결함 등 통합적으로 추적 및 관리하고 보고한다.

---

주섬주섬

    문제는 기억, 이해, 응용 이렇게 3 난이도로 구분하여 출제된다.

참고

STEN

ISTQB_CTFL 1. 소프트웨어 테스팅의 기초