노년코딩

3.1.1 리뷰의 이점과 목적

▶ 정적기법
 - SW를 실행하지 않고 테스팅 하는 기법
 - 동적 테스팅과 달리 장애보다는 장애의 원인(결함)을 발견
▶ 리뷰
 - 코드를 포함하여 SW개발 및 테스트 산출물을 검토하고 테스팅 하는 방법.
 - 동적 테스팅 전에 수행 --> 초기 결함의 수정은 비용 절감
 - 대상
   >> 요구사항 명세, 설계 명세, 코드, 테스트 계획, 테스트 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드, 웹페이지 등 모든 SW개발 및 테스트 산출물.
- 리뷰의 이점
   >> 조기 결함 발견 및 수정
   >> 개발 생산성 향상
   >> 개발 기간 단축
   >> 테스팅 비용 감소 및 시간 단축
   >> 개발 생명 주기 전체에 걸친 비용 감소
   >> 결함 감소(품질 향상)
   >> 커뮤니케이션 향상
 - 리뷰를 통해 발견하기 쉬운 결함
   >> 표준 위반, 요구사항 결함, 개발 설계 결함, 불충분한 유지보수성, 부정확한 인터페이스 명세.
 

3.1.2 리뷰와 테스팅

▶ 최근 테스팅
 - 결함 예방 활동 강조
 - 조기 테스트 설계 -- > 초기에 결함을 줄임
   >> 시스템 명세(요구사항 문서, 설계 기준서)에 대한 테스트 케이스 생성
   >> 요구사항 분석서를 통한 테스트 케이스 -- > 시스템 또는 인수 테스팅에 사용
 - 프로젝트 초기 모든 테스트 케이스 생성은 부적절
 - BUT, 리스크가 높거나 중요한 기능에 한해 테스트 케이스를 도출 하면서 문서를 테스트 -- > 조기 발현 중요.
 

3.2 리뷰 프로세스

▶ 리뷰 목적
 - 결함 발견, 이해도 증진, 합의에 의한 결정과 이를 위한 토론
 - 체계적인 리뷰를 통해 고품질 SW 개발과 비용 절감은 물론 개발 기간 단축의 효과
 - 페이건 스펙션
   >> 초기에 많은 인력, 코딩 단계 부터 인력이 줄게 됨, 품질 비용이 감소하고 개발 기간 단축.
 

3.2.1 공식적 리뷰의 단계

▶ 정적 테스트 활동의 중요성이 높아지고 있음
▶ 정적 테스트 프로세스
 - 정적 테스트 준비 단계
 - 리뷰 / 분석 단계
 - 후속 처리 확인 단계
   >> 비공식적인 리뷰도 일반적인 프로세스를 준수하는 것이 좋음
▶ 공식적 리뷰의 절차
 - 계획 활동 -- > 시작 -- > 개별 준비 -- > 리뷰 미팅 -- > 재작업 -- > 후속 처리 확인

3.2.2 역할과 책임

▶ 역할과 책임
 - 관리자(Manager)
   >>리뷰 진행 결정, 프로젝트 일정에 리뷰 시간 할당, 리뷰의 목적 달성 여부 확인하고 승인
 - 중재자(Moderator)
   >> 리뷰 회의 리드(리뷰 계획, 미팅 진행, 미팅 후속 조치 추적 관리 등)
   >> 다양한 관점을 중재하는 자로 리뷰의 성패를 좌우
 - 저자(Author)
   >> 리뷰 대상 문서(산출물)의 작성자 또는 책임자
 - 검토자(Reviewer) - 테스트 전문가 참여
   >> 리뷰 대상 제품에서 인시턴트를 발견하고 기술할 사람(검사자 또는 인스펙터) - 기술적 또는 비즈니스 배경을 갖춘자
   >> 리뷰어는 다양한 관점과 역할을 대표하도록 선택되어야 함
 - 기록자(Scribe or recorder)
   >> 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화함
▶ 체크리스트 활용
 - 효과적 /효율적인 리뷰를 위해 사용자, 유지보수 담당자, 테스터, 시스템 운영자 등 다양한 관점의 체크리스트 또는 문서 유형별 체크리스트 이용 및 개발 권고
▶ 테스트 케이스 -- > 시간과 노력 많이 필요
 - 변경된 요구사항과 설계 반영을 위해 지속적으로 업데이트 필요  (초반에 다 만들지 않아. 계속해서 업데이트)
 

3.2.3 리뷰의 유형

▶ 리뷰에 리스크 분석을 연계한 사례

 
▶ 워크쓰루(Walkthrough) -- > 이해 향상과 결함 발견
 - 저자(Author: 산출물 작성자)에 의한 진행 및 제어
 - 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토
 - 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open - ended) 세션
 - (선택적) 미팅 전 준비 과정 거침 -- > 역할 지정(검토자, 기록자 등), 리뷰 리포트 준비, 인시던트(조사가 요구되는 이벤트) 목록 준비
 - 실무에서는 비공식적 또는 공식적일 수 있음.
 - 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발
▶ 인스펙션(Inspection) --> 결함 발견
 - 저자가 아닌 중재자가 주도적으로 진행 및 제어
 - 주로 동료 검사
 - 역할이 정의되어 있음
 - 메트릭(측정 척도와 방법)을 수집하고 활용함
 - 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
 - 미팅 전 준비 과정 필요
 - 인스펙션 리포트와 발견 사항(인시턴트(조사가 요구되는 이벤트)) 리스트 산출
 - 정식적인 후속 처리 확인(Follow -up) 프로세스 존재
 - (선택적) 리뷰 프로세스 개선 활동 수행
▶ 인스펙션 대상
 - 모든 개발 산출물과 테스트 산출물
 - 리스크 분석 결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행
   >> 비즈니스와 연관성이 높거나, 복잡도, 변경율, 결함률이 높은 부분이 이에 해당.
 - 리스크 기반 테스트 전략 -- > 리뷰 강도 조절
▶ 워크쓰루 vs. 인스펙션 
 - 사업적 리스크가 높은 영역 - 워크쓰루
 - 기술적 리스크가 높은 영역 - 인스펙션이나 기술적 리뷰
 

3.2.4 리뷰의 성공 요소

3.3 도구에 의한 정적 분석

- 정적 분석 특징
   >> 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
   >> 리뷰와 마찬가지로 정적분석은 장애보다는 결함을 발견함 > 코드를 돌리기 전에 문제점을 찾아내자!!
   >> 도구의 도움을 받아 수행
   >> 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석
 - 정적 분석의 가치
   >> 테스트 실행 전 조기 결함 발견
   >> 의심스러운 코드와 설계에 대한 조기 경보(프로그램 복잡도- 메트릭)
   >> 동적 테스팅으로 발견하기 어려운 결함 발견
   >> SW 모델상의 의존도와 불일치성 발견
   >> 코드와 설계의 유지보수성 향상
   >> 결함 예방 가능
 - 정적 분석을 통해 발견될 수 있는 결함
   >> 정의되지 않은 값으로 변수 참조
   >> 모듈과 컴포넌트 간의 일관되지 않은 인터페이스
   >> 사용되지 않는 변수
   >> 사용되지 않는 코드
   >> 코딩 표준 위반
   >> 보안 취약성
   >> 코드와 소프트웨어 모델의 구문 규칙 위반
 - 정적 분석 도구
   >> 기 정의된 규칙이나 코딩표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용.
   >> SW 모델링하는 동안 설계자에 의해 사용.
 
 
 

2.1 소프트웨어 개발 모델

▶ 테스팅 vs. 소프트웨어 개발

 - 서로 밀접하게 연계

 - 개발 수명 주기에 기반하여 테스팅 접근법을 다르게 적용

2.1.1 V-모델(순차적 개발 모델)

▶ 개발 산출물(Work product)

 - 비즈니스 시나리오 또는 유즈 케이스, 요구사항 명세, 설계 문서나 코드 --> 테스트 베이시스(Basis)로 사용

▶ V-모델의 역할

 - 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것.

 - V-모델을 통해 테스팅 기본 개념 이해

   >> 테스트 레벨의 의미 이해

   >> 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

   >> 결함 예방 차원에서 테스팅이 의미하는 바 이해

   >> V & V (Verification(검증) and Validation(확인))의 의미 (검증과 확인 구분가능 해야 돼.)

▶ 테스트 레벨의 의미

 - 컴포넌트 / 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

   >> 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행 주체, 테스트 완료 기준 등이 달라짐.

   >> 테스트 레벨은 독립적.

▶ 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

 - 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미 (문서만으로 발견)

   >> 결정 테이블 테스팅, 상태전이 테스팅, 유즈 케이스 테스팅 등

 - 개발 초기의 테스팅을 통해서 후반부에서 발생할 비용을 줄임.

▶ 초기에 테스트 설계를 통해 결함을 사전에 예방 ★

2.1.2 반복적 - 검증적 개발 모델

▶ 반복적 & 점진적 개발 모델 

▶ 폭포수 개발 모델 VS. 반복적 & 점진적 개발 모델 

>> 폭포수 모델은 코딩단계까지 리스크가 남아잇기 때문에 거의 쓰지 않아.

>> 반복적 & 점진적 개발 모델이 안정성도 더 높음. -리스크를 처음부터 수정해기 때문.(그대신 초반에 더딤.)

2.1.3 개발 생명 주기 모델에서의 테스팅

▶ 성공적인 테스팅을 위한 조건

   >> 모든 개발 활동은 이에 상응하는 테스트 활동을 동반.

   >> 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있음.

   >> 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작.

   >> 개발 생명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가.

▶ 테스팅 레벨 조절

 - 테스팅은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정하거나 합쳐질 수 있음.

2.2 테스트 레벨(Test Levels)

- 테스트 레벨의 일반적인 구분

   >> 단위, 통합, 시스템, 인수.

▶ 테스트 레벨에 따라 독립적으로 정의할 수 있는 사항

 - 테스트 레벨의 일반적인 목표(목적)

 - 테스트 케이스를 도출해 내는 데 참조되는 개발 산출물(베이시스)

 - 테스트 대상(테스트할 그 무엇)

 - 발견된 전형적인 결함과 장애

 - 테스트 하네스(드라이버/ 스텁) 필요 여부와 툴 지원의 필요성

 - 상세한 테스트 접근법

 - 테스트 수행 주체 또는 조직  

2.2.1 컴포넌트 테스팅

▶ 단위 테스트(Unit Test)

 - 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증 ->대부분 개발자가 하는데 본인이 직접 코드 짠 경우 동료 개발자가 함. 

   >> 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해서 독립적으로 테스트 수행.

   >> 스텁, 드라이버, 시뮬레이터 사용.

 - 일반적으로 프로그램 소스코드를 대상 -- > 구조기반(화이트 박스)

 - 컴포넌트 테스트의 일반적인 목적

   >> 기본 경로 확인

   >> 모든 오류 처리 경로 확인

   >> 컴포넌트 내의 인터페이스 확인

   >> 로컬 데이터 확인, 데이터의 경계값 확인

2.2.2 통합 테스팅(Integration testing)

▶ 통합 테스팅

 - 컴포넌트 간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트.

 - 컴포넌트 통합 테스트

 - 시스템 통합 테스트

 - 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성 등)을 테스팅 수행.

 - 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용.

   >> 통합 그 자체에만 집중하는 오류 주의!!!!

2.2.3 시스템 테스팅(System testing)

▶ 시스템 테스팅

 - 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트

-- > 리스크 최소화를 위해 실제 환경과 유사한 상태.

 - 시스템 관련 고객의 요구사항이 완벽하게 실행되는지를 테스트.

 - 테스트 베이시스(개발 산출물) 이용.

   >> 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비즈니스 레벨의 시스템 동작 명세, os 및 시스템 리소스와 상호작용 명세.

 - 기능 및 비기능 요구사항 모두 검증

   >> 기능적 테스트 : 명세기반(블랙박스) 기법으로 수행 - 문서 기반 테스팅( 테스트 베이시스(개발 산출물) 이용).

   >> 비기능적 테스트 : 기능적 외의 나머지 부분에 대한 요구사항 검증.

 - 일반적으로 독립적인 테스트 팀이 수행 --> 검수 테스팅이라 함 (이후 출시)

2.2.4 인수 테스팅(Acceptance testing)

▶ 인수 테스팅

 - 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것. --> 결함 발견이 목적이 아님. (시스템이 잘 돌아가는지 확인, 결함은 이전 테스팅에서 끝내야 돼)

 - 품질에 대한 확신.

 - 시스템을 베포 하거나 실제 사용할 준비가 되었는지 평가.

 - 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행.

   >> 인스테스팅이 반드시 최종 단계의 테스팅은 아님.

 - 인수 테스팅은 프로젝트 전 개발 과정에서 수행(프로젝트 진행하면서 계속 진행).

   >> 상용(COTS) SW제품은 설치, 통합하면서 테스팅.

   >> 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능.

   >> 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능.

▶ 인수 테스팅 형태

 - 사용자 인스 테스팅(비즈니스 사용자가 확인)

 - 운영상의 테스팅

   >> 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검

 - 계약 인수 테스팅과 규정 인수 테스팅

   >> 맞춤식 - 개발 SW가 계약상의 인수 통과 조건/ 규정을 준수하는지 확인.

 - 알파 테스팅과 베타(필드) 테스팅 --> 고객의 피드백

(알파 테스트 : 회사의 다른 팀 테스트 / 베타 테스트: 외부 고객들이 테스트)

   >> 알파 테스트 : 개발 조직 내에서 고객에 의해 수행

      -고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미

   >> 베타 테스트 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행.

      - 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미.

2.3 테스트 유형(Test types)

▶ 테스트 유형은 테스트 목적에 따라 구분

1. 소프트웨어가 수행하는 기능에 대한 테스팅.

2. 호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅.

3. 소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅.

4. 변경 내용에 관련된 테스팅(확인 테스팅, 리그레션 테스팅)

- 기능적, 구조적 테스팅은 SW 모델 활용.

   >> 기능적 테스팅 --> 명세 기반 기법(블랙박스 테스팅) -프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 이용.

   >> 구조적 테스팅 --> 구조기반 기법(화이트박스 테스팅 (개발능력 반드시 필요)) - 제어흐름 모델, 메뉴 구조 모델 이용.

2.3.1 기능 테스팅( Functional testing)

▶ 기능 테스팅

 -  문서화되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 수행하며 모든 테스트 레벨에서 수행 --> 시스템이 수행하는 무엇(what)을 의미.

 - 명세 기반 기법(블랙박스 테스팅)을 이용해서 테스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부적인 행동을 고려.

▶ 보안성 테스팅

 - 악의적인 코드(바이러스 등)와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능을 확인.

   >> 보안 정책 확인, 트랩도어(진입점) 파악, 보안 관련 평가(가용성, 무결성, 기밀성, 부인 방지 등).

2.3.2 비기능 테스팅

▶ 소프트웨어 제품 특성 테스팅

 - 어떻게(How) 동작하는 가를 테스팅

   >> 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅 그리고 이동성 테스팅 등을 포함한 개념.

 - 전문적 지식인과 도구 필요.

 - 모든 테스트 레벨에서 수행.

 - 다양한 척도 또는 비율로 정량화 가능한 SW품질 특성 측정. - 무조건 수치로 표현되야 돼

 - 소프트웨어 품질 모델 참조(ISO/IEC 9126)

   >> 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성(6가지 척도) 이라는 품질 특성으로 분류.

2.3.3 구조적 테스팅(Structural testing)

▶ 구조 테스팅

 - 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적인 테스트 유형.

 - 커버리지

   >> 시스템 또는 SW구조가 테스트 스위트(test suite)에 의해 테스트된 정도.

   >> 테스팅의 충분함을 측정(100%로 표시 --> 추가 테스트 설계)

 - 모든 테스트 레벨에서 수행 가능

   >> 구조적 테스트 기법(화이트 박스 테스트)

   >> 시스템 아키텍처에 기반을 두고 수행

   >> 비즈니스 모델이나 메뉴 구조(인수 or 시스템 테스트 레벨)

2.3.4 확인/ 리그레션 테스팅

▶ 확인(confirmation/re- testing) 테스팅

 - 결함이 발견되고 수정된 후에 SW는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 경우.

   >> 결함을 수정하기 위한 디버깅은 테스팅이 아닌 개발 활동.

▶ 리그레션(regression) 테스팅

 - 이미 테스트된 프로그램의 테스팅을 반복.

 - 결함 수정 이후 변경의 결과로 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않았던 다른 결함을 발견.

 - SW 또는 환경이 변경되면 실시.

 - 모든 테스트 레벨에서 수행.

 - 리그레션 테스팅 -- > 반복적인 성향 -- > 자동화 대상.

2.4 유지보수 테스팅

▶ 유지보수 테스팅

 - 이미 운영되고 있는 시스템에서 수행되며, SW나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생.

 - 변경에 대한 유지 보수 테스팅.

   >> 계획된 개선을 위한 변경, 수정에 의한 변경과 환경의 변경.

   >> 계획된 OS, DB 업그레이드, OS의 새로 드러난 취약점 패치.

 - 마이그레이션에 대한 유지보수 테스팅.

   >> 변경된 SW에 대한 운영 테스트 + 새로운 환경에서의 운영 테스트

 - 변경된 것 + 변경되지 않은 시스템 요소(영향도 분석 후)에 대한 방대한 리그레션 테스팅 고려.

 - 범위는 변경 범위 및 기존 시스템의 리스크와 크기 고려.  

(참고)

테스트 정책

▶ 소프트웨어 테스팅에 대한 조직의 철학을 정의한 문서

▶ 테스팅 관련 최상위 레벨 문서(일반적으로 간단한 형태)

 - 테스팅 정의

 - 테스팅 미션 및 목적

 - 테스팅 조직의 핵심 역할

 - 고객 만족을 위한 테스팅 관점과 시각

 - 테스트 프로세스 개선

소프트웨어 테스트 윤리강령

▶ 공공성 우선 : 공공의 이익을 위해

▶ 고객과 고용주의 이익 고려 : 고객, 고용주, 공공의 이익 고려

▶ 전문성 있는 결과물 : 표준화된 전문적 산출물

▶ 판단의 독립성 : 판단에 무결성과 독립성 보장

▶ 윤리적 관리 : 윤리적으로 테스팅을 관리해야 함

▶ 직업 의식 : 공공의 이익에 부합하도록 무결성과 신뢰 제공

▶ 동료 의식 : 동료를 공정하게 대하고 개발자와 협력을 촉진

▶ 자기 조직 : 전문성을 확보하고 윤리적 사고로 활동을 함   

테스터 사명

▶ 책임감 : 고객의 입장에서 대변하고 적극적으로 리스크 관리를 함

▶ 태도 : 끊임없는 호기심과 열정으로 창의적이고 혁신적인 테스팅을 위해 노력함

▶ 프로의식 : 테스팅을 사랑하고 자긍심을 갖고 끊임없는 학습으로 전문성을 확보함

▶ 커뮤니케이션 : 개발자는 완성도가 높은 제품을 함께 만들어가는 동반자로 누구에게나 배우려는 열린 마음 지향

1.5 테스팅의 심리학

▶ 개발자와 테스팅 엔지니어 분리 -- > 각자의 활동에 집중

▶ 테스팅 독립성(-- > 단계가 오를수록 독립성 높아짐)

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

- 명확한 테스팅의 목표설정은 테스팅을 성공적으로 수행하는 데 있어 중요.

▶테스팅 진행하는 동안 결함을 식별하는 과정

 - 작성자에 대한 비판으로 오해될 소지 존재

   >> 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험을 필요

 - 오류나 결함, 장애가 긍정적인 방법으로 의사소통 된다면, 테스트와 개발자 간에 발생할 수 있는 감정 악화를 피할 수 있다.

 - 테스터, 테스트 리더 사이

   >> 좋은 대인 관계가 필요

 - 결함 정보

   >> 결함 발견 --> 시간과 비용 절감 및 리스트 요소 줄임  

▶테스터의 역할

 - 다툼보다는 협력으로 시작 --> 코드를 짠사람과 테스터와의 관계 : 공통적인 목표로 인식하는게 중요.

 - 소프트웨어를 개발한 사람에게 비평을 배제하고 중립적이고 사실에 근거한 제품의 결함만 전달하려고 노력한다.

 - 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다. (대화의 기술을 높여야 돼)

 - 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다. (문서화- 체크리스트 만들어서 전달)

1.6 소프트웨어 테스팅을 제약하는 요소

▶ 최근 SW

 - 전통적인 컴퓨팅 영역 탈피

   >> 가전, 무선단말기, 산업 기기, 휴대폰, 자동치(ECU) 분야

 - SW 개발 프로세스 품질의 중요성과 함께 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 테스팅의 중요성 부각.

   >> 전체 개발비의 40% ~60% 이상이 테스팅 비용(개발 << 테스팅 비용)

   >> 하지만 기존 개발자들은 테스팅에 소극적 --> 하위레벨 테스트 부족

 - 품질에 대한 인식 높아져 기대 수준 높아짐 --> 리스크 관리 필요

   >> 체계적인 테스팅을 위해서는 테스트의 우선순위 중요. 

▶테스트에 대한 문제점

 - 테스터가 테스팅에 대해 너무 단편적으로 알고 있는 것은 체계적인 테스팅을 제약하는 요인

   >> 개념과 연관성 이해

   >> 리스크 기반 테스팅 접근법 / 테스트 기법 / 테스트 커버리지 올리는 방법

   >> 이론을 실무에 적용하는 노력 필요.

 - 의사결정권자와 매니저의 테스팅에 대한 인식 부족

   >> 임시방편

   >> 테스트 자동화 도구의 중장기적 계획 or 테스트 프로세스 정립 필요

 - 테스팅을 투자가 아닌 불 필요한 비용으로 인식(X)

   >> 테스팅은 개발보다 더 확실한 ROI(Return On Investment) 활동

1.7 테스팅 분야의 매력

▶ 테스팅 분야의 전문가

 - 체계적인 지식 체계를 갖는 전문 분야

   >> 기존적인 컨셉과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함 관리, 지원 도구, 정적 테스트 기법, 비기능성 테스팅, 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등의 분야 포함.

 - 테스팅 분야는 넓고 다양함

   >> 자동화 도구에 대한 전문적 기술

   >> 보안성 테스트, 신뢰성 테스팅 분야 전문가

   >> 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별 최적화하여 적용

 - 테스팅 필요성 급증

 - 테스팅 분야에서 연령 제한(X), 경험 중시

1.8 테스트 전문가

▶ 테스트 전문가에 대한 수요

 - 계속적으로 증가 --> 소비자의 품질에 대한 마인드와 기대 수준 up.

 - 전문 인력 수급 어려움

   >> 협력사 파견 인력 진원

   >> 테스팅 전문 회사에 아웃소싱

   >> 고급인력이 부족한 경우엔 테스트 컨설턴트 활용

 - 능력 있는 테스트 전문가

   >> 기술 능력 - 소프트웨어 공학 이해, 테스트 수행 능력

   >> 개인 능력 - 커뮤니케이션, 분석력, 문서화, 결함 유추

   >> 습성 - 충분한 이해와 도구 사용, 표준화 노력

   >> 사고방식과 태도 - 주인의식, 열정, 적극, 긍정, 호기심, 비판적인 시선 등

< 테스팅의 일반적인 원리 >
원리 1. 테스팅은 결함이 존재함을 밝히는 것.
원리 2. 완벽한 테스팅은 불가능.
원리 3. 개발 초기에 테스팅 시작.
원리 4. 결함 집중.
원리 5. 살충제 패러독스.
원리 6. 테스팅은 정황에 의존적.
원리 7. 오류 - 부재의 궤변.

1.3 테스팅의 일반적인 원리

- 원리 1. 테스팅은 결함이 존재함을 밝히는 활동이다.

>> 잠재적으로 존재하는 결함 줄임. BUT, 결함이 없다고 증명할 수는 없음.

- 원리 2. 완벽한 테스팅은 불가능하다.

>> 한 프로그램 내에 내부 조건이 많음.

>> 입력이 가질 수 있는 모든 값의 조합이 무수히 많음. (실제로 발생하는 현상이 무수히 많음.)

>> 이벤트 발생 시 발생 순서에 대한 조합도 무수히 많음.

>> 리스크에 따라 테스트 강도 높게 수행 -- > 실제 완벽은 불가. >> 가능성이 높은 것부터 수정해 나가야 돼.

- 원리 3. 테스팅을 개발 초기에 시작한다.

>> 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근.

>> 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출.

- 원리 4. 결함 집중

>> 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임.

>> 결함의 집중은 운영상의 장애를 초래. (리스크가 높은 애들 먼저 수정)

   >> 복잡한 구조의 모듈.

   >> 다른 모듈과 다량의 상호작용을 하는 모듈

   >> 개발 난이도가 높거나 최신 기술을 사용한 모듈

   >> 크기가 큰 모듈

   >> 경험이 미흡한 팀에서 개발한 모듈

   >> 새롭게 개발한 모듈

- 원리 5. 살충제 패러독스  (면역력이 높아져서 결함 찾기가  어려워지는 상황)

 >> 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함을 찾기 어려워짐.

 >> 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선.

- 원리 6. 테스팅은 정황에 의존적.

 >> 테스팅은 정황과 도메인에 따라 다르게 진행.

 >> 모든 테스트에 적용되어야 하는 것. -표준화된 적용 방 (상황이나 도메인에 맞춰서 적절하게 적용해야 됨.)

   >>  테스트 프로젝트 기획

   >> 표준적인 기법 적용.

   >> 독립적인 테스트 환경.

   >> 효율적/ 효과적 테스트 팀 조직

   >> 정식 리포팅 등

- 원리 7. 오류-부재의 궤변 (사용자의 요구 수준에 맞지 않는다면 버그 수정은 의미가 없다.)

 >> 개발된 소프트웨어가 사용자 요구 수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음.

1.4 테스트 프로세스의 기초

▶ 테스트 프로세스

- 테스팅 관련 행동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성 요소를 엮어주는 역할.

>> 테스트 베이시스 -- > 계획 단계부터 필요설계 시 반드시 요구.

>> 테스트 조직 -- > 계획 단계부터 필요, 실행 단계에서 다수 인력 필요.

>> 테스트 전략

>> 테스트 기법 --> 분석 및 설계 단계에서 필요

>> 테스트 대상 --> SW는 가장 이른 시기 준비, 늦어도 실행 단계엔 필수.

>> 테스트 기반 설비 및 환경 --> 실행 단계 전에 구축

- 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크)을 제공.

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

▶ 테스트 계획과 제어

- 주요 활동

>> 테스트 목적/ 목표 및 대상 연구.

>> 테스트 전략 개발

>> 테스트 완료 조건의 결정

>> 테스트를 추정

>> 테스트 조직 구성

>> 테스트 계획 활동

>> 테스트 관리 및 제어

>> 리포팅

▶테스트 제어

- 계획 대비 실제 진행 상황을 비교하는 지속적인 활동.

- 계획과의 차이 확인 > 지속적 모니터링

- 제어 작업 

   >> 테스트 결과에 대한 측정과 분석

   >> 테스트 진척사항, 완료조건의 모니터링과 문서화

   >> 테스트 계획과의 차이 교정

   >> 테스팅의 진행과 변경에 대한 의사 결정 활동.

   >> 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영

1.4.2 테스트 분석과 설계

▶ 테스트 분석과 설계

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

- 주요 작업

 >> 테스트 베이시스 리뷰(가장 기초 문서 - 요구사항 명세서, 설계 계획서 등)

 >> 테스트 상황 / 테스트 케이스 / 필요한 테스트 데이터 식별

 >> 테스트 케이스 설계와 우선순위 선정★

 >> 테스트 기법 할당

 >> 테스트 용이성 평가

 >> 테스트 환경 구축(실제 환경과 동일)

 >> 필요한 도구 식별 

1.4.3 테스트 구현과 실행

▶ 테스트 구현과 실행

- 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화.

- 테스트에 필요한 환경이 구축되어야 함.

- 주요 작업

 >> 테스트 케이스 개발, 구현과 우선순위 설정

 >> 자동화 테스트 스크립트 작성

 >> 테스트 하네스 준비 (환경 준비)

 >> 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성

 >> 선행 테스트

 >> 테스팅 실행(결과 기록 - 식별과 버전 관리)

 >> 기대 결과와 비교 -- > 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고 - > 불일치 원인 파악. 

- 예상과 실제의 불일치

 >> 테스트 케이스 결함

 >> 테스트 정황 결함

 >> 어플리케이션 결함

- 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복.

 >> 수정이 되었는지 테스트 실행  -- > 확인 테스팅

 >> 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행 -- > 회귀 테스팅

- 결함의 유형

 >> 기획 시 유입된 결함 - 요구사항의 표준 미준수, 테스트 불가능 등

 >> 설계 시 유입된 결함 - 설계의 표준 미준수, 테스트 불가능 등

 >> 코딩 시 유입된 결함 - 코드의 표준 미준수 등

 >> 테스트 부족으로 유입된 결함

 >> 마무리 부족

 >> 팀간 의사소통 부족

 >> 코딩 실수

- 결함 심각도에 따른 결함 유형

 >> 치명적 결함, 매우심각, 심각, 보통, 경미 (-> 4단계)

 >> 치명적 결함, 주요 결함,  일반 결함, 사소한 결함, 개선 사항( -> 5단계)

- 결함 유형으로 부적절한 경우

 >> Major, Minor, Trifle(Minor를 결함의 심각도가 낮은 것으로 인식 가능 - 다 문제가 있어)

 >> A,B,C(어느 것이 결함이 높은 것인지 알 수 없음)

- 결함의 우선 순위 표현

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

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

▶ 테스트 완료 조건의 평가

 - 초기 목표 대비 완료 조건의 달성 여부 확인(->95% 만족 시)

 - 테스트 레벨에 따라 다 수행함.

 - 완료 조건 작업

 >> 테스트 실행 결과인 테스트 로그가 테스트 계획에 명시된 완료 조건을 만족하는지 확인.

 >> 추가 테스트 필요 여부 및 명세화된 테스트 완료 조건 변경 여부

 >> 이해관계자들에게 배포할 테스트 요약 보고서 작성. 

▶리포팅에 표현되는 내용

 -  발견된 결함과 미해결 된 결함의 추이 및 우선순위

 -  테스트 진척도

 - 리스크 및 메트릭으로 실증된 조건

 - 테스트 환경의 가용성(다음에 사용 가능한지 여부)

   >> 테스트 커버리지(참 인지 거짓인지 다 훑고 넘어가는 테스트)

   >> 결함 발견 효율성/ 효과성

   >> 품질 평가 결과

   >> 결함 상태별 결함수

   >> 소프트웨어 사이즈 대비 결함수

   >> 요구사항별 테스트 일수

   >> 해결되지 않은 결함과 영향 및 오래 수정되지 않은 결함 

1.4.5 테스트 마감 활동

▶ 테스트 마감 활동

 - 산출물 확인, 테스트웨어(산출물) 보관(-> 다음 프로젝트를 위해)

 - 테스트 프로세스 평가 심사

 - 주요 활동

   >> 테스트 결과 마감(예정된 산출물, 인시턴트(결) 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)

   >> 테스트웨어, 테스트 환경, 테스트 기반설비를 차후에 사용 위해 마감, 보관

   >> 테스트웨어를 유지보수 조직에 이관

   >> 테스트 프로세스 심사 및 개선 사항

   >> 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석.   

1, 소프트웨어 테스팅의 기초
용어: 커버리지, 디버깅, 결함, 오류, 장애, 밸리데이션, 베리피케이션
 
※ 학습목표
1.1. 테스팅이란 무엇인가?
1.2. 테스팅이 왜 필요한가?
1.3. 테스팅의 7가지 원리.
1.4. 테스트 프로세스(의 과정)
1.5. 테스팅의 심리학(어떤 마음으로 테스팅을 하는지)
 

1.1.1 SW 시스템 관점에서 테스팅의 필요성

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

1.1.2 소프트웨어 결함의 원인

▶ 소프트웨어 결함

장애는 실제로 벌어져야 장애로 이어지고, 리스크가 큰애 부터 장애를 해결. 리스크가 없으면 나중에 수정.  
리스크 분석을 통해 어떤 것 부터 수정해야 하는지 판단, 우선순위로 해결 가능.
 

1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할

▶ 테스팅
- 개발 초기의 요구사항 분석 단계부터 리뷰와 정적 분석을 통해 정적으로 시작 -- > 각각의 개발 단계에 대응하는 테스트 레벨별.
- 컴포넌트, 통합 테스팅은 개발 조직(개발자들) 중심으로 수행.
- 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직(전문 테스터들) 중심
- 테스트 레벨에 따른 테스트 
>> 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화.
- 유지보수 활동으로 변경 및 단종되거나 환경이 변경
>> 변경된 환경에 대해 운영 테스팅(리그레션 테스팅 -반복 테스팅).
>> 변경으로 인한 결함과 장애를 예방.
- 계약상 요구 조건 및 산업에 특화된 표준 만족
 

1.1.4 테스팅과 품질

▶ 품질 특성 및 향상
- ISO / IEC 9126 소프트웨어 제품 품질(기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성)
- 품질 향상 > 테스팅이 결함을 찾아내고, 발견된 결함 수정
- 품질 보증(Quality Assurance)
>> 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보.
>> 발견된 결함의 근본 원인 이해를 통해 프로세스 개선.
>> 결함의 재발 방지 (품질보증(QA)을 통해 하고 싶은 것)
- 개발 표준이나 교육 훈련 그리고 결함 분석. 
 

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

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

1.2 테스팅이란 무엇인가?

▶ 테스팅 (테스팅의 목적 - 결함 발견 후 해결)
- 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견 하는 메커니즘
> 정상 동작 여부 확인, 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인, 개발 프로젝트의 리스크 정보를 정량적 수치(숫자로)로 의사결정권자에게 전달.
- 초기 개발 산출물 > 리뷰
- 테스트 케이스 작성 과정(결함 예방 활동)
- 다양한 테스팅 활동
- 테스팅의 일반적인 목적
>> 남아있는 결함 발견, 명세 충족 확인, 사용자 및 비즈니스의 요구 충족, 결함 예방, 품질 수준에 대한 자신감 획득과 정보 제공, 비즈니스 리스크를 감소 시키는 정보에 근간한 조언 제공, 개발 프로세스 점검, 이슈 제기, 논리적 설계의 구현 검증, 시스템과 소프트웨어가 적절히 동작함을 확인. 
- 관점에 따른 테스팅의 목적
>> 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연
>> 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인
>> 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달
>> 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인 (반복 테스트)
>> 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가
>> 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함.

테스트 베이시스 - 요구사항 명세서(요구사항 분석) >> 가장 기초적인 문서 

나에게 필요한 공부가 뭐가 있을까 찾아보다 ISTQB 자격증에 대해 알게 되었다.

국제 자격증이라 일단 멋있다. 물론 멋있기도 하지만 사실은 소프트웨어 테스팅의 전문성에 대해 알아두면 나의 길에도 언젠간 도움이 될 것 같아 준비해 보려고 한다. 실러버스에 공부자료도 올라와 있어 공부하기에 어려운 환경이 전혀 아니라는 상황도 만족스럽다. 찾아보니 유튜브에서 대학생들을 위한 강의도 있길래 보면서 같이 공부할 예정이다.

4월에 시험이 하나 있고 6월에 시험이 있던데 업데이트 된 내용으로 시험을 보려면 6월에 시험을 봐야 하는 것 같다.

6월 20일 시험 접수기한 : 2024-06-10 ~ 2024-06-14 

++

실러버스 자료 링크와 샘플 문제 링크

자료링크:

http://www.kstqb.org/board_skin/board_view.asp?idx=1902&page=1&bbs_code=4&key=0&word=&etc=

샘플문제: (아직 한글 버전은 올라오지 않음)

http://www.kstqb.org/board_skin/board_view.asp?idx=1903&page=1&bbs_code=5&key=0&word=&etc=

유튜브 강의 링크

https://www.youtube.com/watch?v=hCD8799VmM8&list=PLUQt-s6e18eOY8rMTw95VsL-jzgLSMuXJ&index=2&ab_channel=%EA%B9%80%EA%B8%B0%ED%83%9C%EC%9D%98JAVA%EB%A5%BC%EC%9E%90%EB%B0%94

40문제 중 26문제만 맞추면 된다지만 문제들이 생각보다 완벽하게 알지 못하면 헷갈릴 만한 문제들이 많나 보다.

역시 쉬울 리가 없지. 잘 공부해서 웬만하면 다 맞아보자!