목적

본 글은 ISTQB 자격증 취득 시험을 목적으로 학습한 내용을 기록하였습니다.

---

내용

2.1 소프트웨어 개발 수명주기 모델

2.1.1 소프트웨어 개발 수명주기에서의 소프트웨어 개발 활동과 테스트 활동의 관계를 설명하기

💡 모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성

1. 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
2. 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.
3. 주어진 테스트 레벨에 맞는 테스트 분석 과 설계 는 상응하는 개발 활동이 이루어지고 있는 동안 시작 해야한다.
4. 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여 하고, 작업 산출물의 초안이 나오는 즉시 리뷰에 참여한다.

💡 테스트 활동 시기

• 테스팅 활동은 수명주기 초반에 시작할 수록 비용과 시간을 절약할 수 있음.

💡 순차적 개발 모델과 테스팅

• 이론적으로는 각 단계가 서로 중첩하지 않지만, 실제로는 다음 단계에서 빨리 피드백을 받는 것이 유익함.

💡 V-모델과 테스팅

• 각 테스트 레벨의 테스트 실행이 순차적으로 이루어지도록 하고 있지만 경우에 따라서는 중첩 되기도 함.

💡 반복적 점진적 개발 모델과 테스팅

• 테스트 레벨은 중첩 되거나 반복적 으로 적용
• 지속적 전달 혹은 배포를 활용하는 경우 여러 테스트 레벨에 대해 상당한 자동화 구현 요구
• 시스템이 커짐에 따라 리그레션 테스팅의 중요성 증가

2.1.2 소프트웨어 개발 수명주기 모델을 프로젝트 정황과 제품 특성에 따라 수정해야 하는 이유

• 시스템의 제품 리스크 차이
• 많은 사업부가 프로젝트나 프로그램의 일부 일 수 있음. (순차적 및 애자일 개발의 조합)
• 제품의 짧은 출시 기간 (테스트 레벨에서 테스트 유형의 통합 및 테스트 레벨 병합)

2.2 테스트 레벨

2.2.1 목적, 테스트 베이시스, 테스트 대상, 대표적 결함과 장애, 접근법과 책임의 관점에서 다양한 테스트 레벨을 비교하기

💡 테스트 레벨 분류 특성

1. 구체적인 목적
2. 테스트 베이시스
3. 테스트 대상
4. 일반적인 결함과 장애
5. 구체적인 접근법과 역할
6. 테스트 환경

💡 목적 관점에서 비교

1. 일반적인 목적
   • 리스크 완화
   • 명시된 요구사항 충족 검증
   • 기대한 대로 동작하는지 확인
2. 컴포넌트 테스팅
   • 리스크 완화
   • 컴포넌트 기능 과 설계 및 명세 일치 여부 판단
   • 컴포넌트 품질 수준에 대한 자신감 획득
3. 통합 테스팅
   • 리스크 완화
   • 인터페이스 기능 과 설계 및 명세 일치 여부 판단
   • 인터페이스 품질 수준에 대한 자신감 획득
4. 시스템 테스팅
   • 리스크 완화
   • 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증(Verification)
   • 전체 시스템 품질 에 대한 자신감 획득
   • 완성된 시스템이 기대한 대로 동작하는지 확인(Validation)
5. 인수 테스팅
   • 시스템의 기능/비기능 동작이 명시된 대로 이루어지는지 검증(Verification)
   • 전체 시스템 품질 에 대한 자신감 획득
   • 완성된 시스템이 기대한 대로 동작하는지 확인(Validation)
   • 알파 테스팅 : 개발 현장에서 개발자 외 사람들이 수행
   • 베타 테스팅 : 실제 현장에서 고객/운영자가 수행

💡 테스트 베이시스 관점에서 비교

1. 컴포넌트 테스팅
   • 상세 설계
   • 코드
   • 데이터 모델
   • 컴포넌트 명세
2. 통합 테스팅
   • SW 및 시스템 설계
   • 시퀀스 다이어그램
   • 인터페이스 및 통신 프로토콜 명세
   • 컴포넌트나 시스템 레벨의 아키텍처
   • 워크플로우
   • 외부 인터페이스 정의서
   • 유스케이스
3. 시스템 테스팅
   • 에픽과 사용자 스토리
   • 시스템 동작 모델
   • 상태 다이어그램
   • 유스케이스
   • SW 및 시스템 요구사항 명세 (기능/비기능)
4. 인수 테스팅
   • 유스케이스
   • 시스템 요구사항
   • 비기능 요구사항

💡 테스트 대상 관점에서 비교

1. 컴포넌트 테스팅
   • 컴포넌트, 단위, 모듈
   • 코드 및 데이터 구조
   • 클래스
   • 데이터베이스 모듈
2. 통합 테스팅
   • 서브 시스템
   • 인프라
   • 인터페이스
   • API
   • 마이크로서비스
   • 데이터베이스
3. 시스템 테스팅
   • 애플리케이션
   • 운영 시스템
     HW/SW 시스템
4. 인수 테스팅
   • 완전 통합된 시스템의 비즈니스 프로세스
   • 복원 시스템
   • 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트
   • 양식
   • 보고서
   • 데이터
   • 운영 및 유지보수 프로세스
   • 테스트 대상 시스템

💡 대표적 결함과 장애에서 비교

1. 컴포넌트 테스팅
   • 잘못된 코드 및 논리
   • 잘못된 기능
   • 데이터 흐름 문제
2. 통합 테스팅
   • 컴포넌트 간의 통신 관련 장애
   • 시스템 간의 통신 관련 장애
   • 장못된 인터페이스 콜 순서나 타이밍
   • 인터페이스 불일치
   • 잘못된 데이터
3. 시스템 테스팅
   • End-To-End 기능 작업 수행 실패
   • 상용 환경에서 시스템 정상 동작 실패
   • 메뉴얼과 다른 시스템 동작
   • 잘못된 연산
   • 시스템 내 잘못된 제어 및 데이터 흐름
   • 시스템의 예상치 못한 기능/비기능 동작
4. 인수 테스팅
   • 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우
   • 잘못 구현된 비즈니스 규칙
   • 비기능 장애 (보안 취역송, 많은 부하로 인한 성능 효율성 저하 등)

💡 접근법과 책임의 관점에서 비교

1. 컴포넌트 테스팅
   • 테스트 우선 접근법
   • TDD
2. 통합 테스팅
   • 컴포넌트나 시스템을 빌드 하기 전에 통합 테스트 전략 수립
   • 통합은 한 번에 모든 것을 통합하지 않고 가능한 점진적으로 진행
3. 시스템 테스팅
   • 테스트 대상 시스템의 특성에 가장 잘 맞는 기법 사용
4. 인수 테스팅
   • 순차적 개발 수명주기의 마지막 테스트 레벨로 여겨지는 경우가 많지만 다른 시점에서 이루어지는 경우도 있음.
   • 상용 소프트웨어 제품이 설치되거나 통합될 때

2.3 테스트 유형

2.3.1 기능, 비기능, 화이트박스 테스팅을 비교하기

💡 기능 테스팅

• 시스템이 수행해야 하는 기능 평가
  • 기능 : 시스템이 해야 하는 그 무엇
  • 기능 성숙도(완전성), 기능 정확도(정확성), 기능 타당성(적합성)
• 모든 테스트 레벨 에서 수행
• 블랙박스 기법 활용
• 테스트 설계 및 실행에는 비즈니스 문제에 대한 지식 또는 SW가 하는 역할에 대한 특수한 역량 , 지식 필요
• 기능 테스트는 반드시 UI, 화면, 환경이 있어야할 필요는 없음

💡 비기능 테스팅

• 시스템 특성 평가
  • 시스템이 얼마나 잘 동작 하는지에 대한 테스팅
• 모든 테스트 레벨 에서 수행해야 함.
• 가능한 한 프로젝트 초반에 수행
• 블랙박스 기법을 사용할 수 있음. (필수는 아님)
• 테스트 설계 및 실행 또는 기술이 내재하고 있는 약점 대한 지식 또는 특정한 사용자 기반에 대한 지식 필요

💡 화이트박스 테스팅

• 시스템의 내부 구조나 구현을 기반으로 테스트 도출
• 테스트 설계 와 구현에 코드가 구축된 방법, 데이터가 저장되는 방법, 코드 커버리지 도구를 사용하는 방법과 해당 결과를 제대로 분석하기 위한 지식 필요

2.3.2 기능, 비기능, 화이트박스 테스트가 모든 테스트 레벨에서 이루어질 수 있음을 인지하기

• 기능, 비기능, 화이트박스 테스트 등 모든 테스트 유형 은 모든 테스트 레벨(컴포넌트 ~ 인수)에서 이루어질 수 있음.
• 그렇다고 모든 소프트웨어가 꼭 모든 레벨에 모든 테스트 유형을 적용해야 하는 것은 아님
• 각 레벨에서 가능한 테스트 유형을 수행하는 것이 중요함.

2.3.3 확인 테스팅과 리그레션 테스팅의 목적을 비교하기

💡 확인 테스팅

• 결함을 제대로 수정 했는지 확인하는 것이 목적

💡 리그레션 테스팅

• 의도하지 않은 부작용을 발견하기 위한 것이 목적

2.4 유지보수 테스팅

2.4.1 유지보수 테스팅이 필요한 상황을 요약하기

💡 개선을 위한 변경

1. 계획된 확장 (ex_ 릴리즈 기반 개선)
2. 수정 혹은 긴급 변경
3. 운영 환경 변경
4. 상용 SW 업그레이드
5. 결함 및 취약성을 위한 패치

💡 이관(migration)을 위한 변경

1. 기존 플랫폼에서 다른 플랫폼으로 이관할 때
2. 변경된 SW 뿐 아니라 신규 환겨엥 대한 운영 테스트가 필요할 수 있거나 유지보수 중인 시스템에 이관하는 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트 등

💡 단종

1. 애플리케이션의 수명이 다할 때
2. 장신간의 보관이 필요한 경우

2.4.2 유지보수 테스팅에서 영향도 분석의 역할 기술하기

1. 시스템의 다른 영역에 발생할 수 있는 영향을 기반으로 변경 사항을 적용할 지 여부를 판단할 수 있는 척도 역할을 함.

💡 영향도 분석이 어려운 이유

1. 명세가 너무 오래됐거나 없는 경우
2. 테스트 케이스가 문서화 되어있지 않거나 너무 오래된 경우
3. 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우
4. 도구 활용이 적거나 없는 경우
5. 구성원이 도메인이나 시스템 지식이 부족한 경우
6. 유지보수성에 충분한 신경을 쓰지 못한 경우