▶ 테스트 설계의 진행 방식 - 테스트 조직 구성 - 테스팅과 개발 프로세스의 성숙도 - 시간 절약 - 참여인원 등 테스트 정황에 따라 달라짐 ▶ 무엇을 테스트할지 결정하기 위해 테스트 베이시스 문서 분석 - 테스트 베이시스 - 요구사항 명세서, 개발 설계서 등 ▶ 테스트 조건 - 기능, 트랜잭션, 품질 특성 또는 구조적 요소 ▶ 테스트 설계 과정 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함 ▶ 테스트 케이스 - 입력 값의 묶음 - 실행 사전 조건 - 기대 결과와 실행 사후 조건으로 구성 ▶ 테스트 표준 문서 - 소프트웨어 테스트 문서 표준(IEEE 829) - 테스트 설계 명세와 테스트 케이스의 표준 양식 제안 ▶ 테스트 용이성 평가
테스트 분석 및 설계 단계
- 평가 대상 : 테스트 베이시스(개발 명세) - 낮은 품질의 테스트 베이시스는 테스트 케이스 도출이 어려우므로 테스트 베이시스의 테스트 용이성을 평가해 테스트 베이시스의 품질을 높임. - 명세서가 테스트를 고려해 작성됐는지 확인(테스트를 위한 API 설계 등)
테스트 구현 및 실행 단계
- 완결성 >> 테스트에 필요한 모든 것이 다 있는가? - 주요 기능성 >> 주요 기능이 잘 동작하는가? - 테스트 시작조건 준수 여부 검증 - 테스트 환경 검증 >> 테스트 인프라 확인(하드웨어, 도구, 테스트 데이터) >> 기타 어플리케이션(stub, driver)
▶ 테스트 분석, 설계, 구현
▶ 테스트 케이스 - 정의 >> 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음. >> 실행 사전 조건, 기대 결과와 실행 사후 조건의 집합 >> 테스트 돼야 하는 Test Condition((상황)을 입력 값과 기대결과로 표현 - 작성 목적 >> 요구되는 보장성을 갖는 최소개의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있도록 정의한 목표 수준의 테스트 보장성 확보
< 테스트 케이스의 목적 > 1. 최소한의 테스트 케이스로 많은 결함을 발견하는 것. 2. 테스트 대상을 가능한 빠짐없이 테스트하여 테스트 보장성을 확보할 수 있도록 설계되어야 함. 3. 공식적 기법과 경험 기반의 비공식적 기법을 모두 이용해야 함. - 공식적 기법을 먼저 작성한 후에 비공식적인 기법으로 보완이 필요함.
- 예시 테스트 케이스 결과값, 데이터나 상태 변화
▶ 테스트 케이스 개발 및 작성 >> 테스트 케이스 개발 시 우선순위 선정 - 테스트 프로시져 명세서(테스트 케이스의 실행 순서) 만듦 - 테스트 실행 스케쥴 작성(테스트 실행도구를 사용하여 테스트를 수행하면 테스트 프로시저는 테스트 스크립트로 기술할 수 있음) ▶ 테스트 수행 절차 >> 얼마나 상세하게 작성하는 것이 좋을 지 작성해야 함 - 테스터의 스킬, 능력, 해당시스템에 대한 이해를 고려하여 테스트 케이스의 상세함을 조절해야 함. >> 만약 외주를 주는 경우는 자주 테스터가 바뀌더라도 작업을 수행할 수 있도록 상세하게 수행 절차를 기록하여야 함. ▶ 테스트 케이스 작성 >> 테스트 수행 절차를 얼마나 상세하게 작성하는 것이 적절한 지 결정해 주어야 함(테스트 케이스당 7스탭이내로 수행 절차를 작성하는 것이 바람직) >> 7스텝이 넘을 경우는 두 개로 분리하여 관리하는 것이 좋음
4.2 테스트 설계 기법의 종류
▶ 블랙박스기법 VS. 화이트박스 기법
블랙박스 기법(>> 명세기반기법과 경험기반 기법) - 완성제품
화이트박스 기법(>> 구조기반기법) -소스 대상
- 테스트 대상의 내부구조(코드)를 참조하지 않고 테스트 베이시스 그리고 개발자와 테스터, 사용자들의 경험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법.
- 컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 테스트 케이스를 도출.
▶ 테스트 설계의 근원(Origin)을 기준 - 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류
명세 기반 기법
- 테스트 대상에 관한 공식적/ 비공식적 모델(명세) 사용 - 모델로부터 테스트 케이스를 체계적으로 도출
= 블랙박스 테스트 (공식적 방법)
구조 기반 기법
- SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출 - 작성한 테스트 케이스로부터 커러리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가할 수 있음.
= 화이트박스 테스트 (공식적 방법)
경험 기반 기법
- 테스터, 개발자, 사용자 등의 지식 활용 - 발생 가능한 결함과 그 분포 등에 대한 지식 활용 - 문서화 필요
= 탐색적 테스트 (비공식적 방법)
명세가 나오면 블랙박스, 구조가 나오면 화이트박스
4.3.1 명세 기반 기법(Specification - based)
▶ 명세 기반 기법
- 종류 : 동등 분할, 경계값 분석, 조합 테스팅, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅.
4.3.1.1 동등 분할
▶ 동등 분할 - 입력 / 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법. - 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분 - 적용 방법 >> 주어진 시스템 정보를 분석해 입력/ 출력 영역을 유사한 특징을 가진 클래스로 분할 >> 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출 >> 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성 >> 모든 Invalid equivalence class가 커버될 때까지 테스트 케이스 생성
4.3.1.2 경계값 분석
▶ 경계값 분석 - 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트 - 분할 영역의 최대값과 최소값이 그 영역의 경계값 - 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용 - 동등 분할의 확장으로 여겨지며 동일한 방식으로커버리지 보장
4.3.1.3 결정 테이블 테스팅
▶ 결정 테이블 - 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법 - 입력 값들이 논리적인 관계(Binary Condition - 참과 거짓)를 갖는 경우, 입력 값을 원인 / 결과로 나누어 기술 -- > 테스트 케이스 작성 - 구현이나 명세에 잠재된 오류를 찾는 데 효과적으로 이용 ▶ 특징 - 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정과 액션 조합 - 좋은 테스트 데이터 선택을 위해, 경계 값 또는 동등 분할 기법 사용 - 불가능한 Rule을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적. ▶ 결정 테이블 장단점
장점
- 요구사항 등 테스트 베이시스의 문제점을 발견할 수 있는 효과적인 테스트 케이스 생성 가능 (테스트 케이스를 작성하면서 결함 발견, 인스펙션 등 리뷰미팅에 테스트 전문가가 참여한다는 의미) - 테스트 베이시스의 불완전성과 모호함 식별 가능
단점
- 작성에 노력과 시간이 많이 소요될 수 있음(특히 테스트를 위해 결정 테이블을 작성해야 하는 경우) - 복잡한 시스템은 표현하기 어려울 수 있으며, 작성 시 논리적인 실수 가능성있음(개발팀 검토 필요)
▶ 정적기법 - SW를 실행하지 않고 테스팅 하는 기법 - 동적 테스팅과 달리 장애보다는 장애의 원인(결함)을 발견 ▶ 리뷰 - 코드를 포함하여 SW개발 및 테스트 산출물을 검토하고 테스팅 하는 방법. - 동적 테스팅 전에 수행 --> 초기 결함의 수정은 비용 절감 - 대상 >> 요구사항 명세, 설계 명세, 코드, 테스트 계획,테스트 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드, 웹페이지 등 모든 SW개발 및 테스트 산출물. - 리뷰의 이점 >> 조기 결함 발견및 수정 >> 개발 생산성 향상 >> 개발 기간 단축 >> 테스팅 비용 감소 및 시간 단축 >> 개발 생명 주기 전체에 걸친 비용 감소 >> 결함 감소(품질 향상) >> 커뮤니케이션 향상 - 리뷰를 통해 발견하기 쉬운 결함 >> 표준 위반, 요구사항 결함, 개발 설계 결함, 불충분한 유지보수성, 부정확한 인터페이스 명세.
3.1.2 리뷰와 테스팅
▶ 최근 테스팅 - 결함 예방활동 강조 - 조기 테스트 설계 -- > 초기에 결함을 줄임 >> 시스템 명세(요구사항 문서, 설계 기준서)에 대한 테스트 케이스 생성 >> 요구사항 분석서를 통한 테스트 케이스-- > 시스템 또는 인수 테스팅에 사용 - 프로젝트 초기 모든 테스트 케이스 생성은 부적절 - BUT, 리스크가 높거나 중요한 기능에 한해 테스트 케이스를 도출 하면서 문서를 테스트 -- > 조기 발현 중요.
3.2 리뷰 프로세스
▶ 리뷰 목적 - 결함 발견, 이해도 증진, 합의에 의한 결정과 이를 위한 토론 - 체계적인 리뷰를 통해 고품질 SW 개발과 비용 절감은 물론 개발 기간 단축의 효과 - 페이건 스펙션 >> 초기에 많은 인력, 코딩 단계 부터 인력이 줄게 됨, 품질 비용이 감소하고 개발 기간 단축.
3.2.1 공식적 리뷰의 단계
▶ 정적 테스트 활동의 중요성이 높아지고 있음 ▶ 정적 테스트 프로세스 - 정적 테스트 준비 단계 - 리뷰 / 분석 단계 - 후속 처리 확인 단계 >> 비공식적인 리뷰도 일반적인 프로세스를 준수하는 것이 좋음 ▶ 공식적 리뷰의 절차 - 계획 활동 -- > 시작 -- > 개별 준비 -- > 리뷰 미팅 -- > 재작업 -- > 후속 처리 확인
단계
실행 주체
세부 활동
1. 계획
Manager (관리자)
- 리뷰 기준 정의 - 인원 선택 - 역할 분담 - 매우 공식적인 리뷰에는 시작/ 종료 기준 정의 - 리뷰 범위 선정 - 시작 기준 준수 체크(매우 공식적인 리뷰일 경우)
2. 시작(Kick -off)
Moderator(중재자) Reviewer(검토자) Author(저자)
- 문서 배포 - 목적/ 절차/ 문서에 대한 설명
3. 개별 준비
Reviewer(검토자)
- 문서를 리뷰하며 리뷰 미팅을 준비 - 잠재 결함 체크, 회의에서 제시할 질문과 의견(Comment)준비
- 검사/ 평가/ 결과 기록 - 토론하고 기록함 - 결과를 문서화하거나 상세 회의록 작성(매우 공식적인 리뷰인 경우) - 결함 기록 -> 결함 수정 여부 결정( 결함의 해결 방안은 토론하지 않는 것이 원칙)
5. 재 작업(Rework)
Author(저자)
- 결함 수정 - 결함 상태 업데이트
6. 후속 조치(Follow up)
Moderator(중재자)
- 결함 수정 여부 확인 - 메트릭 수집 - 리뷰 완료 기준 체크(매우 공식적인 리뷰인 경우)
3.2.2 역할과 책임
▶ 역할과 책임 - 관리자(Manager) >>리뷰 진행 결정, 프로젝트 일정에 리뷰 시간 할당, 리뷰의 목적 달성 여부 확인하고 승인 - 중재자(Moderator) >> 리뷰 회의 리드(리뷰 계획, 미팅 진행, 미팅 후속 조치 추적 관리 등) >> 다양한 관점을 중재하는 자로 리뷰의 성패를 좌우 - 저자(Author) >> 리뷰 대상 문서(산출물)의 작성자또는 책임자 - 검토자(Reviewer)- 테스트 전문가 참여 >> 리뷰 대상 제품에서 인시턴트를발견하고 기술할 사람(검사자 또는 인스펙터) - 기술적 또는 비즈니스 배경을 갖춘자 >> 리뷰어는 다양한 관점과 역할을 대표하도록 선택되어야 함 - 기록자(Scribe or recorder) >> 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화함 ▶ 체크리스트 활용 - 효과적 /효율적인 리뷰를 위해 사용자, 유지보수 담당자, 테스터, 시스템 운영자 등 다양한 관점의 체크리스트 또는 문서 유형별 체크리스트이용 및 개발 권고 ▶ 테스트 케이스 -- > 시간과 노력 많이 필요 - 변경된 요구사항과 설계 반영을 위해 지속적으로 업데이트 필요 (초반에 다 만들지 않아. 계속해서 업데이트)
3.2.3 리뷰의 유형
항목
비공식 리뷰(Informal Review)
기술적 리뷰(Technical Review)
공식 절차 여부
No
동료와 기술 전문가가 참여, 문서화되고 정의된 결함 발견 절차 정의
주요 목적
저비용으로 문서/ 코드 검토
기술적 문서 해결. 토론, 의사 결정, 대안 평가, 결함 발견, 명세서 또는 표준과의 적합성 검토
▶ 워크쓰루(Walkthrough) -- > 이해 향상과 결함 발견 - 저자(Author: 산출물 작성자)에 의한 진행 및 제어 - 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토 - 시간 및 인원수 등에 제한이 없고상황에 따라 변경할 수 있는(Open - ended) 세션 - (선택적) 미팅 전 준비 과정 거침 -- > 역할 지정(검토자, 기록자 등), 리뷰 리포트 준비, 인시던트(조사가 요구되는 이벤트) 목록 준비 - 실무에서는 비공식적 또는 공식적일 수 있음. - 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발 ▶ 인스펙션(Inspection) --> 결함 발견 - 저자가 아닌 중재자가 주도적으로 진행 및 제어 - 주로 동료 검사 - 역할이 정의되어 있음 - 메트릭(측정 척도와 방법)을 수집하고 활용함 - 체크리스트와 규칙을 기반으로 시작과 종료조건이 있는 정식 프로세스 존재 - 미팅 전 준비 과정 필요 - 인스펙션 리포트와 발견 사항(인시턴트(조사가 요구되는 이벤트)) 리스트 산출 - 정식적인 후속 처리 확인(Follow -up) 프로세스 존재 - (선택적) 리뷰 프로세스 개선 활동 수행 ▶ 인스펙션 대상 - 모든 개발 산출물과 테스트 산출물 - 리스크 분석결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행 >> 비즈니스와 연관성이 높거나, 복잡도, 변경율, 결함률이 높은 부분이 이에 해당. - 리스크 기반테스트 전략 -- > 리뷰 강도 조절 ▶ 워크쓰루 vs. 인스펙션 - 사업적 리스크가 높은 영역 - 워크쓰루 - 기술적 리스크가 높은 영역 - 인스펙션이나기술적 리뷰
3.2.4 리뷰의 성공 요소
심리적 관점
- 사람 관련 이슈와 심리적인 측면을 고려해야 함. >> 코드 또는 문서의 저자가 리뷰를 통해 긍정적인 경험을 해야 지속적인 효과 기대 가능. - 리뷰는 신뢰가 바탕이 돼야 함. >> 리뷰 결과를 리뷰 참여자(리뷰어, 저자 등) 를 평가하는 용도로 사용하지 않음.
조직 및 체계적 관점
- 명확한 리뷰 목적 정의 - 리뷰 목적에 적합한 인력 선택 - 지속적인 학습 및 프로세션 개선 - 경영층의 적극적인 지원(리뷰에 충분한 리소스 할당) - 결함 발견은 언제나 환영하는 분위기이고 결함을 객관적으로 표현해야 함.
기술적 관점
- 적절한 리뷰 기법 적용. >> SW 산출물과 리뷰어(검토자) 수준과 성향(타입) 고려. - 효과적/ 효율적인 결함 발견을 위해 체크리스트 활용(적절한 역할 분담 필요) - 리뷰 기법에 대한 교육(훈련) 필요.(특히, 인스펙션의 경우) - 테스터의 리뷰 참여 >> 프로젝트 초기에 참여해 제품에 대한 이해를 높임.
3.3 도구에 의한 정적 분석
- 정적 분석 특징 >> 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견 >> 리뷰와 마찬가지로 정적분석은 장애보다는 결함을 발견함 > 코드를 돌리기 전에 문제점을 찾아내자!! >> 도구의 도움을 받아 수행 >> 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된결과물도 분석 - 정적 분석의 가치 >> 테스트 실행 전조기 결함 발견 >> 의심스러운 코드와 설계에 대한 조기 경보(프로그램 복잡도- 메트릭) >> 동적 테스팅으로 발견하기 어려운 결함 발견 >> SW 모델상의 의존도와 불일치성 발견 >> 코드와 설계의 유지보수성 향상 >> 결함 예방가능 - 정적 분석을 통해 발견될 수 있는 결함 >> 정의되지 않은 값으로 변수 참조 >> 모듈과 컴포넌트 간의 일관되지 않은 인터페이스 >> 사용되지 않는 변수 >> 사용되지 않는 코드 >> 코딩 표준 위반 >> 보안 취약성 >> 코드와 소프트웨어 모델의 구문 규칙 위반 - 정적 분석 도구 >> 기 정의된 규칙이나 코딩표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용. >> SW 모델링하는 동안 설계자에 의해 사용.
▶ SW관점에서 테스팅 - 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용 > 비중은 계속 증가. - 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상이나 사망(ex>에스컬레이터)에 이르기까지 다양하고 심각. - 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요.
1.1.2 소프트웨어 결함의 원인
▶ 소프트웨어 결함
오류(error)
결함(defect)
장애(failure)
인간의 행위, 실수 >> 코드 작성, 소프트웨어나 시스템 또는 문서 작성 시 결함을 만드는 오류
요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨. <결함의 원인> >>시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호간의 연동. >> 결함은 장애의 원인 BUT, 모든 결함이 장애를 발생시키는 것은 아님(결함이 있는 코드라도 실행되지 않으면 장애로 넘어가지 않음.)
코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함. >> 결함 + 환경적인 조건(방사, 전자기장, 물리적 오염 등)
장애는 실제로 벌어져야 장애로 이어지고, 리스크가 큰애 부터 장애를 해결. 리스크가 없으면 나중에 수정. 리스크 분석을 통해 어떤 것 부터 수정해야 하는지 판단, 우선순위로 해결 가능.
1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할
▶ 테스팅 - 개발 초기의 요구사항 분석 단계부터 리뷰와 정적 분석을 통해 정적으로 시작 -- > 각각의 개발 단계에 대응하는 테스트 레벨별. - 컴포넌트, 통합 테스팅은 개발 조직(개발자들) 중심으로 수행. - 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직(전문 테스터들) 중심 - 테스트 레벨에 따른 테스트 >> 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화. - 유지보수 활동으로 변경 및 단종되거나 환경이 변경 >> 변경된 환경에 대해 운영 테스팅(리그레션 테스팅 -반복 테스팅). >> 변경으로 인한 결함과 장애를 예방. - 계약상 요구 조건 및 산업에 특화된 표준 만족
1.1.4 테스팅과 품질
▶ 품질 특성 및 향상 - ISO / IEC 9126 소프트웨어 제품 품질(기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성) - 품질 향상 > 테스팅이 결함을 찾아내고, 발견된 결함 수정 - 품질 보증(Quality Assurance) >> 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보. >> 발견된 결함의 근본 원인 이해를 통해 프로세스 개선. >> 결함의 재발 방지 (품질보증(QA)을 통해 하고 싶은 것) - 개발 표준이나 교육 훈련 그리고 결함 분석.
1.1.5 테스팅, 얼마나 해야 충분한가?
▶ 적절한 테스팅 정도 - 리스크수준을 고려 - 프로젝트 제약 사항(기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간(얼마나 시간이 있는가), 비용(테스트를 위해 쓸 수 있는 돈)) - 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정을 내릴수 있도록 충분한 정보 제공.
1.2 테스팅이란 무엇인가?
▶ 테스팅 (테스팅의 목적 - 결함 발견 후 해결) - 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견 하는 메커니즘 > 정상 동작 여부 확인, 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인, 개발 프로젝트의 리스크 정보를 정량적 수치(숫자로)로 의사결정권자에게 전달. - 초기 개발 산출물 > 리뷰 - 테스트 케이스 작성 과정(결함 예방 활동) - 다양한 테스팅 활동 - 테스팅의 일반적인 목적 >> 남아있는 결함 발견,명세 충족 확인, 사용자 및 비즈니스의 요구 충족, 결함 예방, 품질 수준에 대한 자신감 획득과 정보 제공, 비즈니스 리스크를 감소 시키는 정보에 근간한 조언 제공, 개발 프로세스 점검, 이슈 제기, 논리적 설계의 구현 검증, 시스템과 소프트웨어가 적절히 동작함을 확인. - 관점에 따른 테스팅의 목적 >> 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연 >> 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인 >> 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달 >> 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인 (반복 테스트) >> 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가 >> 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함.
국제 자격증이라 일단 멋있다. 물론 멋있기도 하지만 사실은 소프트웨어 테스팅의 전문성에 대해 알아두면 나의 길에도 언젠간 도움이 될 것 같아 준비해 보려고 한다. 실러버스에 공부자료도 올라와 있어 공부하기에 어려운 환경이 전혀 아니라는 상황도 만족스럽다. 찾아보니 유튜브에서 대학생들을 위한 강의도 있길래 보면서 같이 공부할 예정이다.
4월에 시험이 하나 있고 6월에 시험이 있던데 업데이트 된 내용으로 시험을 보려면 6월에 시험을 봐야 하는 것 같다.
