ISTQB 2주컷 요약본

QA로 일하게 되며 이론적인 내용이 부족하다는걸 알게 되었고, 이를 보완하고자 10월 15일에
시행한 ISTQB CTFL 시험에 응시했다.

최종 70점으로 합격하였으며 아래와 같이 공부하였다.

• 공부기간 : 10일 (이론 8일 + 문제풀이), 하루 4시간

다른 사람들이 공유하는 요약본으로 시작했으나 시험 자체가 말장난이 심해 이해하지 못하고
외운 상태로 샘플 문제를 풀었을때 포기하고 싶은 점수가 나왔다.

그래서 공부 방법을 바꿔 실러버스와 샘플문제, AI만 활용했다.

중간에 추석연휴가 있어서 2주를 온전히 쓰지는 못했고 실제 공부는 10일 정도였다.

하루 4시간씩 공부했고, 이론에만 8일 정도를 썼으며 샘플문제는 A, B 세트만 풀었다.
4과목에서 계속 떨어져 시험 당일에는 4과목 문제만 풀어보고 들어갔다.

스타벅스 리저브 광화문이 공부가 잘됩니다. 최고

공부방법

1. 실러버스를 한번에 읽는게 아닌 한 단원씩 공부
2. 1과목 1회독 후 AI에게 실러버스를 기반으로 문제 내달라고 하기
3. 이해못한 부분은 이해 될때까지 다양한 방식으로 문제푼 다음 마지막 최종 정리본 받기
4. 전체 6과목 까지 위의 방법으로 회독 돌린 뒤 a, b 문제 풀기

실제 사용 프롬프트

실러버스 PDF를 첨부하고 과목별로 아래 프롬프트를 사용하였다.

파일을 기반으로 이 챕터에 대해서 내가 제대로 이해했는지 문제를 내줘.

제대로 이해를 못한 것 같으면 이해할 때까지 문제 내줘.

---

1장 테스팅의 기초

1. 핵심 용어 흐름

• 오류 (사람의 실수) → 결함 (산출물에 남은 잘못) → 장애 (결함이 실행될 때 나타나는
  기대와 다른 결과)
• 결함은 문서, 소스코드, 빌드파일 같은 지원 산출물에도 있을 수 있다.
• 결함이 실행되지 않으면 장애도 없고, 실행돼도 특정 조건에서만 장애가 나타나거나
  안나타날 수 있다.
• 환경조건(방사선, 전자기장) 만으로도 장애는 생길 수 있다.
• 근본원인 : 문제의 밑바닥 이유 / 근본원인 분석 : 장애 발생이나 결함 식별 시 수행하며,
  유사한 장애와 결함을 예방하거나 빈도를 줄인다.

2. 테스팅 vs 디버깅 vs QA

• 테스팅 : 장애를 일으키거나(동적), 결함을 직접 찾는다(정적)
• 디버깅 : 장애 재현 → 분석(결함 찾기) → 결함 수정
• 수정 후 : 확인 테스팅(원래 결함이 고쳐졌는지), 리그레션 테스팅(다른곳에 부작용 없는지)
• 테스팅 = 제품 중심의 교정 접근법
• 품질보증(QA) = 프로세스 중심의 예방 접근 법이고 모두의 책임이다.

3. 베리피케이션 vs 밸리데이션

• 베리피케이션 : 요구사항을 충족하는가 / 밸리데이션 : 사용자와 이해관계자가 필요한 것을 충족하는가

4. 7가지 원리

1. 테스팅은 결함의 존재를 밝힐 뿐, 부재를 증명하지 못한다.
2. 완벽한 테스팅은 불가능하다. 대신 테스트 기법, 우선순위 지정, 리스트 기반 테스팅으로
   노력을 집중한다.
3. 조기 테스팅으로 시간과 비용을 절약한다. 정적, 동적 모두 가능한 일찍 시작한다.
4. 결합은 집중된다. 소수의 컴포넌트에 몰린다.(파레토)
5. 테스트 효과는 줄어든다. 같은 테스트를 반복하면 새 결함을 못찾으니 테스트와 데이터를 갱신한다. (단, 자동 / 리그레션 처럼 반복이 유용한 경우도 O)
6. 테스팅은 정황에 의존적이다. 모든 상황에 맞는 하나의 접근법은 없다.
7. 결함-부재는 궤변이다. 결함이 없고 요구사항을 충족해도 사용자에게 쓸모없을 수 있으니 베리피케이션과 밸리데이션을 함께 한다.

5. 테스트 활동

• 계획 → 모니터링/제어 → 분석 → 설계 → 구현 → 실행 → 완료
• 분석 = "무엇을 테스트 할까" (테스트 컨디션)
• 설계 = "어떻게 테스트 할까" (테스트 케이스)
• 실제로는 순차가 아니라 반복적, 병렬적으로 진행될 수 있다.
• 정황요인 8가지 : 이해관계자, 팀원, 비즈니스 도메인, 기술적 요인, 프로젝트 제약 조건, 조직적 요인, SDLC, 도구

6. 추적성

• 테스트 베이시스 요소와 테스트웨어(컨디션, 리스크, 케이스, 결과, 결함)간을 연결한다.
  ex. TC ↔ 요구사항으로 커버리지 확인
• 추가효과 : 변경 영향 파악, 테스트 감사, IT 거버넌스 기준 충족

7. 역할과 기술

• 테스트 관리 역할 : 계획, 모니터링, 제어, 완료
• 테스팅 역할 : 분석, 설계, 구현, 실행
• 한 사람이 두 역할을 겸할 수도 있다.
• 필수 기술 : 테스팅 지식, 철저함, 호기심, 세부 주의력, 의사소통, 분석, 비판, 창의적 사고, 기술 지식, 도메인 지식

8. 전체 팀 접근법 | 독립성

• 전체 팀 접근법 : 익스트림 프로그래밍에서 시작. 필요한 기술을 가진 누구나 어떤 작업이든 하고, 모든 팀원이 품질에 대한 책임을 진다. 단, 안전이 치명적인 경우처럼 높은 독립성이 필요하면 부적절할 수 있다.
• 독립성 4단계 : 저자 본인(없음) → 같은 팀 동료(일정 수준) → 조직 내 다른 팀(높음) → 조직 외부(매우 높음)
• 장점 : 인지 편향이 달라 다른 유형의 결함을 찾고, 이해관계자의 가정을 검증한다.
• 단점 : 고립, 협업곤란, 개발자가 품질 책임을 잃을 수 있고, 병목이나 출시 지연의 원인으로 비난받을 수 있다.

2장 소프트웨어 개발수명주기(SDLC)와 테스팅

1.SDLC와 테스팅

• 순차적 개발(폭포수, V모델) : 실행 가능한 코드는 후반에 나옴
  → 초기에는 정적 테스팅(요구사항 리뷰), 테스트 분석, 설계를 하고 동적 테스팅은 후반에 한다.
• 반복적, 점진적 개발, 애자일 : 매 반복마다 동작 결과물이 나옴
  → 정적, 동적 테스팅을 모두 하고, 리그레션 테스팅과 테스트 자동화 필요성이 크다.
• 좋은 테스팅 프랙티스 4가지

1. 모든 개발 활동에 상응하는 테스트 활동을 둔다.
2. 테스트 레벨마다 구체적이고 독립적인 테스트 목적을 둔다. (중복 방지)
3. 테스트 분석, 설계를 상응하는 개발단계에서 시작한다. (조기 테스팅)
4. 테스터는 산출물 초안이 나오는 즉시 리뷰에 참여한다.

2. 테스트 먼저 하는 개발

• TDD(테스트 주도 개발) : 테스트 먼저 작성 → 테스트 기반 코드 작성 → 리팩토링
• ATDD(인수 테스트 주도 개발) : 인수 조건에서 테스트 도출, 코드 개발 전에 작성
• BDD(행위 주도 개발) : 기대 행위를 자연어(Given, When, Then)로 작성 → 자동 실행 테스트로 변환
• 공통 : 코드 전에 테스트를 정의 → 조기 테스팅과 시프트 레프트

3. 시프트 레프트 / 데브옵스 / 회고

3장 정적 테스팅

1.

4장 테스트 분석과 설계

1.

5장 테스트 활동 관리

1.

6장 테스트 도구

1.