노년코딩

들어가기 전 알아둬야 하는 1.5 용어 설명
: 사전적으로는 용어설명 글 참고 ㄱㄱ. 여기서는 간단하게 이해 쉽게 설명

도메인 : 유효한 입력값/ 출력값의 선택을 가능하게 하는 집합.

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

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

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

• 테스팅 지식(테스팅 효과를 높이기 위해 - ex> 테스트 기법 활용)
• 철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근(결함, 특히 찾기 어려운 결함 식별을 위해)
• 우수한 의사소통 기술, 경청하는 자세, 팀플레이(모든 이해관계자와 효과적으로 상호작용하고, 다른 사람에게 정보를 전달하고, 상대의 이해를 구하고, 결함을 보고하고, 논의하기 위해)
• 분석적 사고, 비판적 사고, 창의성(테스팅 효과를 높이기 위해)
• 기술 지식(테스팅 효과를 높이기 위해 - ex> 적절한 테스트 도구 사용)
• 도메인 지식(최종 사용자/ 비즈니스 대표자를 이해하고 그들과의 소통을 위해)

테스터에게는 의사소통 기술이 매우 중요. 결함과 장애 관련 정보를 건설적인 방법으로 전달할 수 있어야 함.

1.5.2 전체 팀 접근법
: 누구나 모든 작업 수행 O, 모든 팀원이 품질에 대해 책임. 의사소통 & 협업 Up!

- 전체 팀 접근법에서는 필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다. 같은 공간을 사용하는 것은 의사소통과 상호작용을 용이하게 하므로 팀원들은 작업 공간을 공유한다.
- 전체 팀 접근법은 팀의 활력을 높이고, 팀 내 의사소통과 협업을 강화하며, 프로젝트의 성공을 위해 팀이 가진 다양한 기술을 활용해 시너지를 창출한다.

테스터는 필요한 수준의 품질 달성을 위해 다른 팀원과 긴밀히 협력하게 된다. 여기에는 비즈니스 담당자와 협력해 적절한 인수 테스트를 작성하고, 개발자와 협력해 테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다. 따라서 테스터는 테스팅 지식을 다른 팀원과 공유하게 되며, 제품 개발에 영향을 주게 된다.

- 정황에 따라 전체 팀 접근법이 적절하지 않을 수 있다. ex> 안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요할 수 있다.

1.5.3 테스팅의 독립성

- 일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다. 그러나 독립성이 친숙함을 대체하는 것은 아니다. ex> 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

< 작업 산출물 독립성 단계 >

1단계 - 독립성 없음 : 저자가 직접 테스트. 2단계 - 일정 수준의 독립성 : 저자의 같은 팀 동료가 테스트. 3단계 - 높은 독립성 : 저자의 팀 외부에 있지만 조직 내에 있는 테스터가 테스트. 4단계 - 매우 높은 독립성 : 조직 외부의 테스터가 테스트.

< 독립적인 테스팅의 주요 이점 >
- 배경, 기술적 관점, 편향이 다르기 때문에 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다.
- 독립적인 테스터는 시스템 명세를 작성하고 구현하는 과정에서 이해관계자의 가정을 검증하고, 그것에 대한 이의를 제기하거나 반증할 수 있다.

< 독립적인 테스팅의 단점 >
- 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며, 개발팀과 적대적인 관계로 이어질 수 있다.
- 개발자가 품질에 대한 책임감을 잃을 수도 있다.
- 독립적인 테스터가 병목으로 인식되거나, 출시 지연의 원인으로 비난받을 수도 있다. 

▲ 여기는 생각보다 문제가 잘 나오는 구역 같다. ▲

테스터에게 요구되는 기술을 물어보거나, 전체 팀 접근법의 장단점 문제, 테스팅의 독립성 단계 선택이나 장단점을 찾아내는 문제들로 샘플문제에서 자주 봤다. 외울 필요는 없지만 이해만 하면 문제를 맞히기 쉬운 부분이다.

들어가기 전 알아둬야 하는 1.4 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해하기 쉽게 되도록 공부한 설명.

리그레션 테스팅 : 반복 테스팅.
테스트웨어 : 테스트 산출물.
테스트 차터 :  테스트 세션의 목적 또는 목표를 설명하는 문서.
테스트 환경 : 테스트 수행에 필요한 하드웨어, 계측, 시뮬레이터, 소프트웨어 도구 그리고 기타 지원 요소를 포함하고 있는 환경.
테스트 하네스 : 테스트 스위트를 실행하는 데 필요한 스텁 및 드라이버 모음.
문배에서의 테스트 하네스 : 테스트 대상이 실행되는 환경을 시뮬레이션함으로써 컴포넌트나 시스템 일부에 대한 테스팅을 가능하게 한다.
테스트 스위트 : 특정 테스트 실행에서 실행될 일련의 테스트 스크립트 또는 테스트 절차.

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

- 테스팅은 정황에 의존적이지만, 상위 수준에서 봤을 때 만약 없다면 테스팅이 테스트 목적을 달성하기 어렵게 되는 보편적인 테스트 활동이 있다.
- 이런 테스트 활동들이 테스트 프로세스를 구성하게 된다.
- 테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다.
- 테스트 프로세스에 포함할 테스트 활동과 그러한 활동의 구현 방법과 수행시기는 보통 해당하는 상황의 테스트 계획을 할 때 결정한다.

1.4.1 테스트 활동과 업무

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

- 테스팅은 단독으로 수행되지 않는다.
- 테스팅 비용은 이해관계자가 부담하게 되며, 테스팅의 최종 목표는 이해관계자의 비즈니스 목표 달성을 지원하는 것이다.

>> 따라서 수행 방식은 다음과 같은 여러 정황요소에 따라 달라진다.

이해관계자(필요, 기대, 요구사항, 협력 의지 등)

팀원(기술, 지식, 경험 수준, 가용성, 훈련 필요성 등)

비즈니스 도메인(테스트 대상의 중요도, 식별된 리스크, 시장 요구사항, 구체적인 법적 규제 등)

기술적 요인(소프트웨어 유형, 제품 아키텍처, 사용된 기술 등)

프로젝트 제약 조건(범위, 시간, 예산, 자원 등)

조직적 요인(조직 구조, 기존 정책, 적용한 실천법 등)

소프트웨어 개발수명 주기(SDLC)(공학적 실천법, 개발 방법론 등)

도구(가용성, 사용성, 규정 준수 등)

>> 이런 요소는 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트 문서 상세화 수준, 보고 등 많은 테스트 관련 문제에 영향을 미친다.

1.4.3 테스트웨어( == 테스트 산출물)

- 테스트웨어는 테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 생성/ 구체화/ 명명/ 구성/ 관리하는 방식에 상당한 차이가 있다.
- 적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.

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

- 효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 개별 요소와 관련된 테스트웨어(예: 테스트 컨디션, 리스크, 테스트 케이스), 테스트 결과, 식별한 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.
- 정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 기준이 테스트 베이시스에 정의되어 있을 때 매우 중요. 커버리지 기준은 테스트 목적 달성 상태를 나타내는 활동을 촉진하는 핵심 성과 지표로 기능할 수 있다.

 
< 좋은 추적성 5가지 >

• 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 한다.
• 테스트 감사를 용이하게 한다.
• IT 운영 및 관리 기준을 충족하는데 도움이 된다.
• 테스트 진행 상황 및 완료 보고서에 테스트 베이시스 개별 요소의 상태를 명시하여 보고서를 더 쉽게 이해할 수 있게 한다.
• 이해관계자에게 테스팅의 기술적 측면을 이해하기 쉬운 방식으로 전달하는 데 도움이 된다. 

** 추적성은 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공.
 

1.4.5 테스팅에서의 역할

 
 
++ 테스트 활동이랑 테스트웨어는 함께 보는게 좋을 것 같으니 표를 합쳐서 같이 봐보자.

테스트 활동과 테스트웨어 합쳐보기

테스팅의 원리는 완벽한 테스팅은 불가능하다는 확실히 인식하고 있어야 한다. 기본 중 기본.

들어가기 전 알아둬야 하는 1.3 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해가 쉽게 되도록 공부한 설명.

테스트 기법 : 무엇을 테스트(테스트 분석)할지, 어떻게 테스트할지(테스트 설계) 작업을 지원함. 실라버스는 블랙박스, 화이트박스, 경험기반으로 분류하고 있음.

테스트 케이스 우선순위 지정 : 테스트 케이스의 우선순위 지정.
실라버스에서는 3가지 우선순위지정법이 나옴 - 리스크 기반, 커버리지 기반, 요구사항 기반 우선순위지정.

리스크 기반 테스팅 : 테스트 활동을 선택하고 우선순위를 정해 관리하는 테스트 접근법.

파레토 원리(Pareto principle) : == 80 - 20 rule. 전체 결과의 80%은 20%의 원인 때문에 생긴다는 경험적 법칙.

베리피케이션 : 검증. 검사하여 증명하는 것. 프로세스 개념에서 검증은 "개선사항을 실제 실행하기 전"으로 이해.
밸리데이션 : 검정. 검사하여 정하는 것. 프로세스 개념에서 검정은 "개선사항을 실행한 후"로 이해.

1.3 테스팅의 원리 7가지

1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지 않는다.
2. 완벽한 테스팅은 불가능하다. - 완벽한 테스팅을 하려 하기보다는 테스트 기법, 테스트 케이스 우선순위 지정, 리스크 기반 테스팅을 사용해 테스트 노력을 집중해야 한다.
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다. - 결함을 조기에 식별하기 위해 정적 테스팅과 동적 테스팅 모두 최대한 이른 시점에서 시작해야 함.
4. 결함은 집중된다. - 대부분의 결함은 소수의 시스템 컴포넌트에 집중. 이런 현상은 파레토 원리의 예이다. 예상 결함 집중 영역과, 결함 집중 영역은 리스크 기반 테스팅의 주요 입력으로 사용.
5. 테스트 효과는 줄어든다. - 이게 이전 버전의 살충제 패러독스! 같은 테스트를 계속해서 반복하면, 결국 테스트의 신규 결함 식별 효과는 점점 줄어들게 됨. / 자동 리그레션 테스팅처럼 같은 테스트를 반복하는 것이 유익한 결과로 이루어지는 경우도 있다.
6. 테스팅은 정황에 의존적이다. - 정황에 따라 다르게 진행함.
7. 결함 - 부재는 궤변이다. - 사용자의 요구나 기대에 못 미치거나, 고객의 비즈니스 목표 달성에 도움이 되지 않고 경쟁 시스템에 비해 부족한 시스템이 만들어질 수도 있다. 따라서 베리피케이션과 함께 밸리데이션도 수행해야 한다.(=> 최종 사용자가 인수테스팅을 수행하도록 지원하면 대처 가능! 그래서 밸리데이션도 수행해야 함)

정석대로라면 실라버스 4.0 버전을 꼼꼼하게 다 읽어 봐야 되지만 시간이 없을 땐 여기 있는 내용들이라도 전부 읽어보도록 하자. 5번 이상 읽어서라도 이해해서 알아둬야 한다. 

들어가기 전 알아둬야 하는 1.1 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해가 쉽게 되도록 공부한 설명.

베리피케이션 : 요구사항 충족 확인, 준수 여부 확인.
밸리데이션 : 이해관계자가 만족하는지 확인.

동적 테스팅 : 소프트웨어 실행. << 시스템 돌리면서 처리.
정적 테스팅 : 리뷰 + 정적 분석. << 문서, 코드 보면서 해결.

< 테스팅과 디버깅의 차이 >
테스팅 : 결함이 존재하는 지 판단. 장애를 통해 결함을 발견하는 것.
디버깅 : 결함을 제거.

확인테스팅 : 수정이 되었는지 테스트 실행.
문배 속 확인 테스팅 : 결함을 수정했는지 확인하는 테스팅. 수정 여부를 확인하기 위해 이전에 실패했던 테스트를 실행한다.
리그레션 테스팅 : 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행.
문배 속 리그레션 테스팅 : 수정으로 인해 변경되지 않은 소프트웨어 영역에 의도하지 않은 새로운 결함이 유입되지 않았는지 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트한 프로그램을 다시 테스팅.

1.1 테스팅이란 무엇인가?

- 올바르게 동작하지 않는 소프트웨어는 금전적, 시간적, 비즈니스 평판 손실은 물론, 심하게는 부상이나 사망에 이르기까지 다양한 문제를 일으킬 수 있다.
- 소프트웨어 테스팅은 소프트웨어 품질을 평가하고, 소프트웨어 사용 시 나타나는 장애의 위험을 줄여줄 수 있다.
- 소프트웨어 테스팅은 결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동이다.
- 흔히 테스팅이 단지 소프트웨어를 실행하고 결과를 확인하는 테스트 수행에 국한된다고 오해하는 경우가 많지만, 소프트웨어 테스팅에는 다른 활동이 포함되며, 이 활동은 소프트웨어 개발수명주기(SDLC)에 따라서 달라진다.
- 테스팅은 시스템이 주어진 요구사항을 충족하는지 확인하는 베리피케이션을 포함, 시스템이 운영환경에서 사용자 또는 기타 이해관계자가 필요한 바를 만족하는지를 확인하는 밸리데이션도 포함한다.
- 테스팅은 동적 또는 정적일 수 있다. 
- 테스팅은 기술적인 활동에 국한되지 않으며, 적절한 계획/ 관리/ 추정/ 모니터링/ 제어도 필요하다.
- 테스터는 도구를 사용하지만, 테스팅은 주로 테스터가 전문 지식을 갖추고 분석 기술을 사용해 비판적 사고와 시스템적 사고를 적용하는 지적 활동이라는 점을 기억해야 함.

1.1.1 테스트 목적

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

1.1.2 테스팅과 디버깅

들어가기 전 알아둬야 하는 1.2 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해가 쉽게 되도록 공부한 설명.

품질 보증(QA) : 프로세스 중심의 예방 접근법. 개발 및 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용.
품질 제어(QC) : 제품 중심의 교정 접근법. 결함을 수정하는 데 사용. 테스팅은 품질 제어의 주요 활동.
오류 : 인간의 행위, 실수.
결함 : 고장이나 장애의 원인. 결함은 제품에 있어.
장애 : 결함의 실행. 이벤트와 관련.

1.2 테스팅이 왜 필요한가?

- 품질 제어 활동의 일환으로 테스팅은 정해진 범위, 시간, 품질, 예산 내에서 합의된 목표를 달성하는 데 도움을 줌.
- 성공에 기여하는 테스팅이 테스트팀의 활동으로 국한된 것은 아니다.
- 모든 이해관계자는 자신이 가진 테스트 기술을 사용해 프로젝트 성공에 기여할 수 있다. 
- 컴포넌트, 시스템, 관련 문서를 대상으로 한 테스팅은 소프트웨어 결함을 식별하는데 도움이 된다.

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

- 테스팅은 결함을 식별하는 비용 효율적인 방법이다.
- 디버깅을 통해 식별한 결함은 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.
- 테스팅은 소프트웨어 개발수명주기(SDLC)의 여러 단계에서 테스트 대상의 품질을 직접 평가하는 방법을 제공한다. 이런 평가 결과는 대규모 프로젝트 관리 활동에서 릴리스 여부의 판단과 같은, 소프트웨어 개발수명주기(SDLC) 다음 단계로의 이동 여부 결정에 기여하게 된다.
- 테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다.
- 테스터는 개발수명주기 전반에 걸쳐 그들이 이해하고 있는 사용자 요구사항을 고려한다.
- 계약 또는 법적 요구사항을 충족하거나 규제 표준 준수를 위해 테스팅이 필요할 수 있다.

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

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

- 사람은 오류(실수)를 저지르며, 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다.
- 사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등 다양한 이유로, 또 단순히 피로하거나 충분한 훈련이 부족해서 오류를 범할 수 있다.

- 결함은 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물에서 나올수 있다.

- 장애의 원인이 오류와 결함만 있는 것은 아니다. 환경 조건으로 발생하는 것도 있다.

- 근본 원인은 문제 발생의 근본적인 이유(예 : 오류로 이어지는 상황)을 말한다. 근본 원인 분석을 통해 식별하며, 근본 원인 분석은 보통 장애가 발생하거나 결함을 식별한 경우 수행한다.
- 근본 원인을 처리(가령 제거)하면 유사한 장애나 결함을 예방하거나 빈도를 줄일 수 있다.

오로지 내 시험을 위해 정리해 보는 ISTQB 4.0 공부.

ISTQB가 4.0 버전으로는 정리되있는게 잘 보이지 않길래 직접 정리해 보면서 공부를 해보려 한다.

용어 정리를 시작으로 중간중간 이해되지 않았던 단어들 정리, 이론 정리, 샘플 문제 오답풀이, 문배 풀이 순서로 진행. 

처음부터 이렇게 공부하고 싶었지만 시간이 없었던 관계로 시간이 생긴 지금 내방식대로 정리 Start!

혼자 하는 공부가 제일 잘되는 나로서는 오늘도 역시 혼자 공부하겠지만 이 글을 보는 누구든 같이 공부해서 합격해 보자!

혹시나 나같이 취업을 준비하고 있는 경우라면 우리 모두 취준 화이팅!

++ 이 블로그를 보시는 모두가 제가 정리해 둔 내용으로 합격된다면 그 또한 기분 째질 것 같으니 혹시나 합격하면 댓글 달아주기! 

용어 정리
: 용어부터 찬찬히 알아둬야 문제에서 뭐라는지 알 수 있음.
▼ ISTQB에서 알려주는 용어 사전. 혹시나 모르는 단어가 있다면 Search해보라구. 영어로도 가능. ▼
++ https://glossary.istqb.org/ko_KR/  

커버리지 : 커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분로 표시한 것.

디버깅 : 컴포넌트 또는 시스템에서 장애의 원인 찾고 분석하고 제거하는 프로세스.

결함 : 요구사항이나 명세를 충족시키지 못하는 작업 산출물의 불완전함 또는 결점.
문배에서의 "결함" 설명 : 일반적으로 버그, 결함, 결정은 동의어로 사용될 수 있으며 요구된 기능을 적절히 처리하지 못하는 것. 즉 장애를 발생시키는 것.

오류 : 부정확한 결과를 만들어내는 인간의 행동.
문배에서의 "오류" 설명 : 잘못된 결과를 낳는 인간의 행위, 실수와 동의어.

장애 : 지정된 범위 내에서 요구되는 기능을 컴포넌트나 시스템이 수행하지 못하는 경우.
문배에서의 "장애" 설명 : 코드에 존재하는 결함의 실행.

품질 : 컴포넌트 또는 시스템이 다양한 이해관계자의 명시적 및 암시적 요구를 충족시키는 정도.

품질 보증 : 품질 요구사항이 충족될 것이라는 확신을 제공하는 데 초점을 둔 활동.

근본 원인 : 결함의 원인 중 제거되면 해당 결함유형 발생이 감소하거나 제거될 수 있는 원인.

테스트 분석 : 테스트 베이시스를 분석하여 테스트 컨디션을 식별하는 활동.

테스트 베이시스 : 테스트 분석 및 설계의 기초로 사용하는 지식 체계.

테스트 케이스 : 테스트 컨디션을 기반으로 개발된 사전 조건, 입력값, 행동(해당하는 경우), 기대 결과, 사후조건의 집합.

테스트 완료 : 테스트웨어를 나중에 사용할 수 있도록 만들고 테스트 환경을 만족스러운 상태로 남겨놓고 관련 이해관계자에게 테스트 결과를 전달하는 활동.

테스트 컨디션 : 테스팅의 베이시스로 식별된 컴포넌트 또는 시스템의 테스트 가능한 측면.

테스트 제어 : 테스트 프로젝트가 계획을 벗어났을 때 예정대로 진행되도록 시정 조치를 개발하고 적용하는 활동.

테스트 데이터 : 테스트 실행에 필요한 데이터.

테스트 설계 : 테스트 컨디션에서 테스트 케이스를 도출하고 명시하는 활동.

테스트 실행 : 컴포넌트 또는 시스템에서 테스트를 실행하여 실제 결과를 도출하는 활동.

테스트 구현 : 테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 활동.

테스트 모니터링 : 테스트 활동의 상태를 확인하고 계획 또는 예상과의 차이를 식별하고 이해관계자에게 상태를 보고하는 활동.

테스트 대상 : 테스트할 작업 산출물.

테스트 목적 : 테스팅의 이유 또는 목적.

테스트 계획 : 테스트 계획서의 수립 또는 수정 활동.

테스트 절차 : 실행 순서로 나열된 테스트 케이스 순서. 초기 사전 조건을 설정하는 데 필요한 모든 관련 동작과 실행 이후의 모든 마무리 활동까지 포함.

테스트 결과 : 테스트 실행의 결과 또는 결괏값. 화면 출력과 데이터 변경, 보고서, 전송된 통신 메시지 등이 여기에 포함.

테스팅 : 소프트웨어 제품 및 관련 작업 산출물이 특정 요구사항을 충족하는지 확인하고, 목적에 부합하는지 여부를 입증하고, 결함을 발견하기 위해 정적/ 동적의 모든 계획, 준비, 평가와 관련된 수명주기 활동으로 구성된 프로세스

테스트웨어 : 테스팅에 대한 계획, 설계, 실행, 평가, 보고 등에 활용하기 위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물.

밸리데이션 : 의도된 특정 용도 또는 용도에 대한 요구사항이 충족되었음을 보증하기 위해 객관적 증거와 조사를 통해 확인하는 것.

베리피케이션 : 특정 요구사항이 모두 구현되었는지를 객관적 증거와 조사를 통해 확인하는 것.

자주 나오는 테스팅의 종류
: ISTQB 공부하면 적어도 한번 이상 접하는 애들이니까 잘 읽어봐.

기능 테스팅 : 컴포넌트 또는 시스템이 기능 요구사항을 충족하는지 평가하기 위해 수행되는 테스트.
비기능 테스팅 : 컴포넌트 또는 시스템이 비기능적 요구사항을 충족하는 지 평가하기 위해 수행되는 테스트.

정적 테스팅 : 테스트 항목의 실행을 수반하지 않는 테스팅.
동적 테스팅 : 테스트 항목의 실행과 관련된 테스트.

화이트박스 테스팅 : 컴포넌트나 시스템의 내부구조 분석에 기반한 테스팅.
경험 기반 테스팅 : 테스터의 경험, 지식, 직관에 기반한 테스팅.
리스크 기반 테스팅 : 연관된 리스크 유형과 리스크 수준을 기반으로 테스트 활동 및 리소스의 이용, 관리, 선택, 우선순위 등을 다루는 테스팅.

베타 테스팅 : 개발 조직에 속하지 않는 인원에 의해 개발자의 테스트 환경과 다른 외부 사이트에서 수행되는 인수 테스트 유형.
사용자 인수 테스팅 : 의도된 사용자가 시스템을 승인하는지 확인하기 위해 수행되는 인수 테스트 유형.
운영 인수 테스팅 : 운영 및 시스템 관리 직원이 시스템을 인수할 수 있는지 확인하기 위해 수행되는 인수 테스트 유형.

리그레션 테스팅 : 소프트웨어의 변경되지 않은 영역에 결함이 도입 또는 발현되었는지 여부를 감지하기 위한 변경 관련 테스트 유형.
확인 테스팅 : 결함을 수정한 후 해당 결함으로 인해 발생한 장애가 다시 나타나지 않는지 확인하기 위해 수행하는 변경 관련 테스트 유형.

애자일 테스팅 사분면 : 4 사분면으로 구성된 테스트 유형/ 레벨 분류 모델로, 테스트 목표의 두 가지 차원(팀 지원 대 제품 비평, 기술 대면 대 비즈니스 대면)과 관련됨.

시스템 테스팅 : 전체로 봤을 때 시스템이 명시된 요구사항을 충족하는지 확인하는 데 초점을 둔 테스트 레벨.
시스템 통합 테스팅 : 시스템 간의 상호작용에 초점을 둔 테스트 레벨.
통합 테스팅 : 컴포넌트 또는 시스템 간의 상호작용에 중점을 둔 테스트 레벨.
컴포넌트 테스팅 : 개별 하드웨어 또는 소프트웨어 컴포넌트에 초점을 둔 테스트 레벨.

탐색적 테스팅 : 테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식.
요구사항 기반 테스팅 : 테스트 케이스를 요구사항을 기반으로 설계하는 테스트 접근 방식. 

컴포넌트 통합 테스팅 : 테스트 항목이 통합된 다른 컴포넌트와 인터페이스하고 상호 작용하는 테스트. 통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함을 노출시키기 위한 테스팅.

화이트박스 테스트 기법 : 컴포넌트나 시스템의 내부 구조 분석에만 기반을 둔 테스트 기법.
블랙박스 테스트 기법 : 컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.
경험 기반 테스트 기법 : 테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.


조건 테스팅 : 테스트 케이스가 원자 조건의 결과를 실행하도록 설계된 화이트박스 테스트 기법.
결정 테스팅 : 테스트 케이스가 결정 결괏값을 실행하도록 설계하는 화이트박스 테스트 기법.

조합 테스팅 : 테스트 케이스가 복수의 매개변수 값의 특정 조합을 실행하도록 설계되는 블랙박스 테스트 기법.
유스케이스 테스팅 : 유스케이스 동적을 수행하도록 테스트 케이스를 설계하는 블랙박스 테스트 기법.
사용자 스토리 테스팅 : 사용자 스토리를 기반으로 테스트 케이스를 설계하여 올바르게 구현되었는지를 확인하는 블랙박스 테스트 기법.
상태 전이 테스팅 : 테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법. 
동등 분할 기법 : 각 도메인의 구성 데이터 중 하나를 사용하여 테스트 케이스가 동등 분할을 실행하도록 설계하는 블랙박스 테스트 기법.

구문 테스팅 : 테스트 케이스가 구문을 실행하도록 설계하는 화이트박스 테스트 설계 기법.
결정 테이블 테스팅 : 테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계기법.

체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

아쉽게도 지난번 시험은 22개를 맞아서 떨어졌다. 흑.

그래도 약 일주일 동안 공부한 결과치고는 가능성이 보여 내가 시험문제를 풀 때 어렵게 느껴졌던 응용문제들에 대해 보완을 하고자 "문제로 배우는 소프트웨어 테스팅" 책을 구매했다. "개발자도 알아야 할 소프트웨어 테스팅 실무"라는 책도 고민을 해봤는데 책이 2010년에 나오고 더 이상 변화가 없는 상태인 것을 보고 아무래도 구글로 직접 검색해 보면서 공부하는 편이 좋을 것 같다는 결론을 냈다.

중고로 구매하려면 대략 배송비 포함 15000원 정도의 가격이 드는 것을 확인한 나는 알라딘으로 찾아 나섰다.(내가 애정하는 알라딘) 마침 가을이벤트를 하고 있었는데 최대 2000원까지의 랜덤 적립금을 주는 이벤트에서 무려 2000원이 당첨되었다. 이로써 기본 적립금 2000원과 합산하니 4000원의 적립금이 생겼다. 여기서 지난달 책선물을 하느라 1500원의 적립금을 적립해 두었던 나는  알라딘으로 새책을 샀을 때 중고 가격이랑 비슷하게 살 수 있었다.

양탄자 배송이라고 오후 1시 전에 사면 당일 밤까지 배송된다는 것을 보고 12시 57분에 구매했는데 아쉽게도 뭔가 오류가 있었는지 다음날에 도착했다. 어플에서 처음엔 떠있다가 나중엔 사라졌던 것 같기도 한데 뭔가 일정한 시간 이후가 되면 ui가 없어지는 걸까? 그래도 다음날 빠르게 받아 볼 수 있어서 세상 두근거리는 마음으로 택배 포장을 뜯어보았다.

영롱한 옥색의 책이 날 바라봤다. "이거 얘도 오래되어 보이네."라는 생각으로 책 맨 앞장을 읽어보았더니 2011년 ISTQB 내용인가 보다. 개정판이라 해서 달라져있을 까 싶었지만 뭐 어쩌겠는가. 그래도 문제들이 이렇게 한가득 있는데 어느 부분에서는 도움이 되겠지!

일단은 원래 공부하던 데로 실라버스를 중점으로 샘플문제 오답풀이와 함께 틀을 잡고 추가적으로 이 책을 통해 문제들을 보완하면서 공부를 해볼 생각이다. 실라버스가 4.0으로 업데이트되면서 내용들도 많이 추가되고 단어들 이름 또한 달라진 것들을 볼 수 있었는데 그런 부분에 대해 헷갈리지 않게 공부하는 게 가장 중요할 것 같다. 

이제 다음시험인 10월엔 합격해 보자고!

그래도 시험응시 비용 너무 빡셈... 제발 잘해보자.

8월 29일 오후 7시 30분 ISTQB 시험을 보고 나왔다. 

역시 시험은 봐봐야 안다. 이제 어떻게 공부를 해야 되는지 알 것 같다.

그래서 나 같은 비전공자들을 위한 간단한 후기이자 나의 경험을 일기로 남겨두기 위해 이렇게 글을 써본다.

나는 비전공자로써 QA에 대해 궁금증만 있었지 어떤 역할을 하고 무슨 공부를 해야 하는지 정확하게 알고 있지 않은 상태였다. 그럼에도 느낌 적인 느낌으로 나의 적성에 맞을 것 같다는 단순한 관심이 생겨 시험을 준비하고자 계획을 짜보았다. 그렇기 때문에 처음 ISTQB 실라버스의 4.0을 다운 받아 읽어봤을 때 도무지 이게 무슨 말들인가 라는 생각밖에 들지 않았었다. 그저 "72장의 페이지에는 글들이 쓰여있고, 그건 한글이었다." 정도였달까. 

시기적으로 내가 실라버스를 알게 된 날은 버전 4.0이 이미 나온 시점이었다. 6월의 시험을 마지막으로 이후 시험부터는 선택의 여지가 없이 무조건 4.0으로 공부를 해야 된다는 부분은 어떤 버전의 실라버스 공부를 선택해야 하는지 시작부터 고민이 되었었다. 두 가지 버전을 다 다운을 받고 읽어봤더니 다시 한번 깨달았다. 이건 버전의 문제보단 역시나 뭐라는지 전혀 모르겠다는 것을. 그냥 읽어서 공부하기에는 이해도 전혀 되지 않았던 상황이기에 유튜브 김기태 님의 강의였던 sw테스팅 강의를 전부 들어봤다.

1.

시험 보기까지 어느 정도 시간이 여유 있다면 나는 이 강의들을 들어보는 것을 추천한다. 나의 경우는 강의 속도가 좀 느리게 느껴져서 재생 속도를 올려 들어봤더니 훨씬 집중력이 올라갔었다. 재생 속도를 1.25나 1.5 정도로 듣는 것을 추천한다.

하지만 시간이 촉박할 때는 강의를 들을 때가 아니다. 무조건 실라버스를 우선적으로 외워라. 물론 실라버스를 외운다 해도 문제를 다 풀지는 못한다. 당장 샘플 문제만 풀어봐도 내가 무슨 말을 했는지 알 수 있을 것이다. 실라버스에 쓰여있는 내용만 문제로 나오지 않는다. 샘플 문제의 문제들과 해설을 같이 읽으며 공부해야 한다. 해설에는 문제마다 어디 부분에서 문제가 도출되었는지 알려주는 학습 목표가 기재되어 있다. 이걸 같이 보면서 공부를 해야 된다. 샘플 문제는 A, B, C, D 문제들로 구성되어 있으며 A가 가장 쉬운 난이도이고, 순차적으로 어려워져 D 샘플 문제가 제일 어렵게 느껴졌다.

처음에는 A 샘플 문제를 풀어보면서 내가 이해한 게 맞는지를 확인해 보고 B, C, D 샘플 문제로 가서 더 외워야 될 암기 내용들을 정리를 하면서 공부를 하면 될 것 같다. 문제를 풀고 오답풀이를 한 다음 실라버스 이론을 다시 공부하고 다시 풀어보는 방식으로 공부를 해보니까 나중엔 머릿속에 답이 외워져서 의미가 없어지더라. 그래서 추천하는 방법은 A 문제 풀고 오답풀이 후, B 문제 풀고 오답 풀이한 다음 실라버스 이론 공부하고 C 문제 풀고 오답풀이 하고 A문제로 돌아가서 다시 풀어보는 형식으로 세 개 정도의 샘플문제를 풀고 처음으로 돌아와서 다시 풀어보는 방법을 추천한다.

2.

그리고 계산 문제! 4단원에서 나오는 계산 문제는 답이 명확하기에 다 맞는 게 가장 중요하다고 어느 블로그를 통해 알게 되었다. 실제로 샘플 문제를 풀어봤을 때도 두 가지가 답이 되는 문항에서도 더 답과 가까운 답을 선택해야 되는 문제들이 있다. 그런 걸 생각해 보면 계산 문제는 정말 다 맞는 게 자격증을 딸 수 있는 확률을 높이는 지름길이다. 

하지만 비전공자들에겐 계산 문제가 쉬울 리 없다. 실라버스에서만 설명하는 내용으로는 어떻게 풀어야 하는 건지 이해도 안 될 수 있다. 나의 경우는 우선 김기태 님 유튜브에서 문제 푸는 설명을 해둔 강의들을 보면서(ex> 결정 테이블 테스팅 영상) 이해를 하고 네이버 카페 "SW TestER들의 모임. 소프트웨어 테스트/팅 QA,ISTQB,CSTS,검증"에서 찾아서 문제를 풀어봤다. 그 외에는 네이버나 티스토리나 구글에서 문제들을 찾아서 발품 팔듯 문제를 찾아 헤맸다. 이렇게 찾아서 풀 때도 약간 이해 안 가는 문제들이 생겨서 막막했었는데 시험 보러 가서는 문제들이 더 어렵게 나오기 때문에 계산 문제들은 많이 풀어보는 게 맞는 것 같다. 샘플 문제에서는 어딘가 눈치껏 풀면 정답을 찾을 수 있다 하면 자격증 시험 문제에서는 정확하게 모르면 시간만 엄청 잡아먹고 결국은 찍어야 되는 상황이 온다.

3.

40문제를 60분 안에 풀어야 하기 때문에 시간을 잘 분배해야 된다. 나의 경우에는, 샘플문제들을 40분 정도에 다 풀고 20분 정도가 남았던 반면에 시험장에서는 오히려 20분 정도가 모자랐다. 헷갈리는 문제가 있다면 아닌 답은 확실하게 그어 문제에 체크를 해두고 바로 넘어가는 방법을 추천한다. 아닌 답들은 이후에 다시 찾아오면 까먹기 때문에 찍으려고 해도 확실히 제거된 답들은 아웃시키고 남은 답들 중 선택하는 편이 오답률을 줄일 수 있다. 아 그리고 오히려 뒤에 남은 문제가 더 쉬울 수 있다. 시험시간이 촉박해져서 더 쉬운 문제를 놓치게 된다면 집 가는 길에 눈에서 뭔가 흐를지도 모른다.

그리고 답안지에는 이름, 영문 이름, 또 이것저것을 써야 하기 때문에 답안지 교체를 웬만하면 안 하는 것이 낫다. 시험지에 답을 체크를 해두고 한 번에 옮겨 적는 게 제일 시간 절약하는 방법이다.

4.

내가 선택한 7시 반 타임의 시험장은 대화빌딩 지하 1층이었다. 가는 길에는 스타벅스도 있고 파스쿠찌도 있다. 미리 와서 공부를 할 경우 저 두 개의 카페를 선택하는 것도 방법이긴 하지만 대화빌딩 지하 1층에도 카페가 하나 있다. 샐러드를 중심으로 판매하는 카페로 자릿수가 많지는 않다. 그래도 그곳에 있는 거의 모두가 시험을 준비하고 있어서 자리만 잡으면 아주 조용하게 공부할 수 있다. 그리고 5시 전에 가면 창문을 통해 5시 시험자들의 모습도 볼 수 있다. 만약 집중이 안 되는 상태라면 차라리 이 모습을 보고 빠르게 떨리는 마음을 장착하고 더 집중하는 게 나을지도 모른다.

5.

경기도에 산다면 istqb 말고 kstqb를 준비를 해보는 것도 나쁘지 않다. 왜냐면 경기도 잡아봐 홈페이지에서 국가 자격증, 민간 자격증, 어학 자격증을 딸 때 응시료를 지원해 주기 때문이다. istqb는 국제 자격증이라 지원을 안 해주지만 kstqb는 민간 자격증이라 지원을 해주는 것 같았다. 최대 30만 원까지 응시료를 지원해 주기 때문에 이 돈으로 여유롭게 여러 번 봐봐도 될 것 같은 느낌이 들었다. 물론 한 번에 합격하는 것이 제일 좋겠지만 뭐가 돼었든 알아두면 손해 볼 정보는 아니지 않은가.

6.

시험 공부기간은 적어도 한 달 정도의 기준으로 잡는 게 심적으로 편하다. 나의 경우는 시험 보기 아주 예전에 유튜브 강의를 다 들어두고 본격적으로 시험 준비를 한 게 2주 전부터였는데, 사실 2주 중 1주일은 코로나에 걸려있어서 제대로 공부한 시간은 일주일이었다. 일주일 동안 준비를 하는 건 비전공자는 절대 불가능하다는 것을 알았다. "그냥 다 외우면 되지 뭐."라고 생각했던 마음은 진짜 샘플문제 풀어보면 산산조각 난다. 응용도 응용이지만 실라버스에 나와있지 않는 내용에 대해 문제로 만들어져 있다. 아니면 그냥 블라 블라 어쩌고 저쩌고 하는 곳에 적혀있던 사이에 껴있는 단어 한 개를 두고 예시를 주고 이 단어가 그거라는 것을 알아야 된다. 솔직히 이건 쫌...? 그렇기에 일주일 정도로 공부해서 시험 보겠다는 생각을 하는 사람이 있다면 QA가 직업인 사람, 전공자, 원래 이쪽 분야에 관심과 지식이 있었다 하는 사람들만 가능하다. 적어도 2주, 3주는 있어야 심적으로 편하다.  

시험장에는 7시부터 들어갈 수 있었다. 들어가기 전에 컴퓨터용 사인펜이나 유성 볼펜을 제대로 챙겨갔는지 확인을 하고 시험장 문 앞에 가면 안내해 주시는 분이 이름을 확인하고 자리를 안내를 해주신다. ISTQB 답게 자리가 a, b, c, d, e, f, g 열로 되어 있는데 "a열의 끝에서 몇 번째, 앞에서 몇 번째 자리로 가세요." 해주시면 그대로 가서 앉으면 된다. 만약 잘 모르겠다면 다시 한번 물어보면 되는데 그럴 때는 자리로 직접 데려다주시는 것 같다. 문제지를 다 나눠 주고 이름을 쓰고 다 준비가 되면 "시작하겠습니다." 하면서 그때부터 1시간의 타이머가 화면에 뜬다. 중간중간 답안지가 문제가 있을 때는 손을 들어 변경하면 되고 문제를 다 풀었다면 손들어서 시험지와 답안지를 제출하고 일어나서 나가면 된다. 이건 시험 시간이 꽤 남았을 때만 가능하고 시험 시간이 10분 전일 때는 앉아서 끝날 때까지 기다려야 한다. 시간에 쫓겼던 나는 당연히 1, 2분 정도를 남겨둘 때까지 시간을 사용했고 내가 끝나는 것을 보자마자 옆에 지나가시던 감독관님께서 시험지와 답안지를 가져가셨다. 실제로 중간에 가시는 분들이 계셨는데 잠깐이었지만 대단해 보였었다. 다 끝나면 감독관님들이 한 명 한 명 자리로 가서 시험지와 답안지를 가져가신다. 전부 수거가 되어도 바로 나갈 수 없다. 무언가의 규칙이 있는 것 같았는데 각 줄마다 앞에서 허락을 해주셔야 나갈 수 있다. 시험지와 답안지를 다 가져갔을 때가 그 타이밍 아닌 것은 내 눈으로 확인했다. 마치 학교나 교회 수련회에서 그룹마다 밥 먹으러 가는 걸 허락 맡는 것처럼 기다렸다 나오면 모든 게 다 끝난다.

시험 끝나고 나오니까 8시 50분쯤 되었었는데 밤 공기가 좋았다. 청담역까지 걸어가면서 빌딩들을 많이 봤다.

"저 어딘가 내가 일할 곳이 한 군데는 있겠지."라는 생각으로 걸음을 옮겼다.

19만 8000원이 큰돈으로 느껴지는 지금 나에게 응시료는 무거웠지만 그래도 도전해보길 잘 했다는 생각이였다. 시작해보지 않았을 때는 "내가 과연 저걸 해볼수 있을 까." 싶지만 막상 발로 밟아보니 "나 충분히 할 수 있겠구나." 생각할 수 있었다. 다음엔 더 잘 해보자 내 자신아.