노년코딩

들어가기 전 알아둬야 할 4.1 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.

블랙박스 테스트 기법 : 개발자 입장이 아닌 사용자 입장에서 바라본 제품의 요구사항이 일치하는지 확인하는 테스트 기법. 명세 기반 기법.
화이트박스 테스트 기법 : 개발자 입장에서 바라본 로직에 대한 설계로 구현이 제대로 되었는지 확인하는 테스트 기법. 구조 기반 기법.
경험 기반 테스트 기법 : 탐색적 테스팅.
테스트 케이스 : 테스트 베이시스를 토대로 만들어짐. 블랙박스와 경험기반 테스트의 주요 차이점은 테스트 베이시스가 다른 거야. 블랙박스는 명세, 경험기반은 탐색.

4.1 테스트 기법 개요
:테스트 설계와 분석에 적용할 활동들을 공부해보자고!

테스트 기법이란?
- 테스터의 테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업을 지원.
- 적은 수이지만 충분한 테스트 케이스를 체계적인 방식으로 개발할 수 있도록 해줌.
- 테스터가 테스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는데 도움을 줌.

용어 정리
: 용어부터 정리해 두고 봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

경계값 분석 : 경계값을 기반으로 테스트 케이스를 설계하는 블랙박스 테스트 기법.

분기 커버리지 : ==결정 커버리지. 결정된 결과값에 대한 커버리지. 

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

커버리지 : 커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분율로 표시한 것.
커버리지 항목 : 테스트 실행의 완전성을 측정할 수있는 테스트 기법을 사용해 하나 이상의 테스트 컨디션에서 도출하는 속성 또는 속성들의 결합체.

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

동등 분할 : 명세에 따라 모든 값이 동일하게 취급될 것으로 예상되는 컴포넌트 또는 시스템 내의 변수 값 도메인의 하위 집합.

오류 추정 : 과거 장애에 대한 테스터의 지식이나 장애 형태에 대한 일반적인 지식에 기초하여 테스트 케이스를 도출하는 테스트 기법.

탐색적 테스팅 : 테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식.
상태 전이 테스팅 : 테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법.

구문 커버리지 : 실행 가능한 구문에 대한 커버리지.

테스트 기법 : 테스트 조건을 정의하고, 테스트 케이스를 설계하고, 테스트 데이터를 지정하는 데 사용되는 절차.

블랙박스 테스트 기법 : 컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.

화이트박스 테스트 기법 : 컴포넌트 또는 시스템의 내부 구조에만 기반을 둔 테스트 기법.

경험 기반 테스트 기법 : 테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.

4장의 내용은 엄청 많으면서 엄청 중요한 내용이다. 테스트 기법에 대해서도 알아야 되고 분석 문제도 풀 줄 알아야 된다.

샘플문제도 많이 풀어보고 발품팔아 구글링이랑 네이버 블로그 뒤적거려서 문제도 많이 찾아보고 풀어보는 게 좋다.

용어 정리
: 용어부터 정리해 두고 먼저 읽어봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

이상 사항 : ==이상 현상. 요구사항 명세서, 설계 문서, 사용자 문서, 표준 또는 누군가의 인식이나 경험 등에 기반한 기댓값에서 벗어난 상태를 말한다. 이상 현상은 리뷰, 테스팅, 분석, 비교, 혹은 소프트웨어 제품이나 해당 문서의 사용 도중에 발견할 수 있지만, 이에 국한되지는 않음.

동적 테스팅 : 테스팅 항목의 실행과 관련된 테스트.

공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형.
비공식 리뷰 : 정의된 프로세스를 따르지 않고 문서화된 공식 결과가 없는 리뷰 유형.

인스펙션 : 작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로세스를 개선하는 데 필요한 정보를 제공.

리뷰 : 결함을 발견하거나 개선 사항을 제공하기 위해 한 명 이상의 개인이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅 유형.

정적 분석 : 형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스.

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

기술 리뷰 : 작업 산출물의 품질을 검사하고 명세 및 표준과의 불일치를 식별하는 기술 전문가의 공식 리뷰.

위크 쓰루 : == 워크스루. 작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형.

3장은 공부시간이 80분으로  6장 테스트 지원도구(20분) 외에 가장 짧은 시간이 필요하다. 읽어보면서 이해하고 넘어가야 80분의 시간 안에 끝낼 수 있다. 아무 생각 없이 읽기만 반복한다면 뫼비우스의 띠처럼 글씨, 글씨, 글씨로 시간이 줄줄이 흘러가 버려지는 시간이 늘어날 수 있다. 도저히 집중이 안된다 싶다면 문제를 풀어보면서 해설을 읽으며 공부해도 좋은 구역이다.

들어가기 전 알아둬야 할 2.2 용어, 2.3 용어 설명
: 사전적으로 설명 정리한 건 용어 설명 글 ㄱㄱ, 여기는 이해 쉽게 봐보자.

테스트 레벨 : 테스트 프로세스 중의 특정 예시 단계. 
테스트 유형 : 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

컴포넌트 : 개별적으로 테스트할 수 있는 시스템의 최소 구성단위.
엔드 투 엔드 테스팅 : 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형.
테스트 명세 : 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서.

< 기능 테스트 & 비기능 테스트의 기능과 비기능 해석 >
기능 : 무엇을 해야 하는지.
비기능 : 얼마나 잘 돌아가는지.

확인 테스팅 : 원래 결함이 성공적으로 수정됐는지 확인.
리그레션 테스팅 : 변경으로 인해 부정적인 영향 있는지 확인. 확인 테스팅 이후에 리그레션 테스팅하는 거임.

운용 환경 : 움직이는 환경으로 이해 ㄱㄱ.

2.2 테스트 레벨과 테스트 유형

- 테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.
: 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수 있다.
- 테스트 레벨은 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.
: 순차적 소프트웨어 개발수명주기 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.

- 테스트 유형은 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

2.2.1 실러버스에서 다루는 테스트 레벨 5가지

• 컴포넌트 테스팅(== 단위 테스팅) : 컴포넌트를 개별적으로 테스트하는 데 중점. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많음. 일반적으로 개발자가 자신의 개발 환경에서 수행함.
• 컴포넌트 통합 테스팅(== 단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점. 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
• 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점. 엔드 투 엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많음. 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있음.
• 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점. 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용함.
• 인수 테스팅 : 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점. 실제 사용자가 수행하는 것이 이상적. 주요 유형으로 사용자 인수 테스팅, 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅이 있음.

▶ 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다양한 속성 "테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할"들을 고려해 구분한다.

2.2.2 실러버스에서 다루는 테스트 유형 4가지

• 기능 테스팅 : 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가. 기능은 테스트 대상이 "무엇을" 해야 하는지를 의미. 주요 목적 - 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것.
• 비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가. "시스템이 얼마나 잘 동작하는지" 테스트하는 것. 주요 목적 - 비기능 소프트웨어 품질 특성을 확인하는 것.

ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류함.
- 수행 효율성.
- 호환성.
- 유용성.
- 신뢰도.
- 보안.
- 유지 가능성.
- 이동성.

수명 주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다. 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.

• 블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출. 주요 목적 - 명세와 비교해 시스템의 동작을 확인하는 것.
• 화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출. 주요 목적 - 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것.

2.2.3 확인 테스팅 및 리그레션 테스팅

일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.

▶ 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.

2.3 유지보수 테스팅

유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수, 환경 변화에 적응, 성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다.
운용환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.

▶ 유지보수 테스팅의 범위는 일반적으로 "변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기"에 따라 달라진다.

< 유지보수와 유지보수 테스팅의 계기 >

• 계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항.
• 운영 환경의 업그레이드나 마이그레이션 하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션 할 때, 데이터 변환 테스트가 필요할 수 있다.
• 애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다. 보관기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다. 

들어가기 전 알아둬야 하는 2.1 용어 설명
: 사전적으로는 용어설명 글 참고 ㄱㄱ, 여긴 간단하게 봐보자.

리그레션 테스팅 : 수정으로 기존에 있던 프로그램에 새로운 결함이 생겼는지 테스팅.
프랙티스 : 관리 활동.
시프트 레프트 전략 == 조기 테스팅원리.
인수 테스트 주도 개발 >> 대표적인 테스트 우선 개발 접근법.
명세 : 자세한 내용.
테스트 하네스 : 자동화된 테스트 지원도구.
회고 : 프로젝트 종료 후 회의.

테스트 주도 개발 : 테스트 케이스가 개발되고 많은 경우 자동화된 다음 해당 테스트 케이스에 합격하도록 소프트웨어를 점진적으로 개발하는 소프트웨어 개발 기법.
>> 테스트가 주도하는 개발 방법론을 의미.

인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.
>> 인수테스트가 주도하는 개발 방법론을 의미.

행위 주도 개발 : 팀이 테스트의 베이시스를 형성하는 고객을 위한 컴포넌트 또는 시스템의 기대 동작을 제공하는 데 집중하는 개발에 대한 협업적 접근 방식.
>> 시스템 동작의 행위를 기반. 행위에 대한 명세를 작성하는 것이라 생각하면 이해가 쉬움.

비기능 테스트 : 기능이 아닌 거. 테스트 결과가 기능 테스트처럼 Yes/No로 판단하기 힘듦.
ex> 로그인 기능 테스트. 버튼 클릭시 로그인은 되는데 지연이 10초 이상 되었다가 로그인이 될 때.(기능은 정상 작동하지만 뭔가 문제가 있지.)

2.1 소프트웨어 개발수명주기에서의 테스팅

소프트웨어 개발수명주기(SDLC) 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상화해서 표현한 것이다.
소프트웨어 개발수명주기(SDLC) 모델의 예 :
순차적 개발 모델(ex> 폭포수 모델, V - 모델), 반복적 개발 모델(ex> 나선형 모델, 프로토 타이핑), 점진적 개발 모델(ex> 통합 프로세스)등이 있다.

2.1.1 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향

• 테스트 활동 범위 및 시기(ex> 테스트 레벨 및 테스트 유형)
• 테스트 문서 상세화 수준
• 테스트 기법 및 테스트 접근법 선택
• 테스트 자동화 범위
• 테스터의 역할과 책임

2.1.2 소프트웨어 개발수명주기(SDLC)와 우수한 테스팅 프랙티스
: 선택한 소프트웨어 개발수명주기 모델에 상관없이 다음과 같은 우수한 테스팅 프랙티스가 있다.

• 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어 모든 개발 활동이 품질 제어의 대상이 되게 한다.
• 테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.
• 특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기의 상응하는 각 개발 단계에서 시작해 (테스팅 원리 중) 조기 테스팅 원칙을 준수할 수 있게 한다.
• 테스터가 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서, 시프트-레프트 전략 지원을 위한 조기테스팅과 결함 발견이 가능하도록 한다.

2.1.3 소프트웨어 개발 주도를 위한 테스팅

테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다.
이런 접근법은 코드 작성 전에 테스트를 정의하므로 조기 테스팅 원리를 구현하고 시프트-레프트 접근법을 따르게 한다. 반복적 개발 모델을 지원함.

2.1.4 데브옵스(DevOps)와 테스팅

- 테브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하도록 시너지 창출을 목표로 하는 조직 차원의 접근법이다.
- 데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄임과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 조직문화의 변화가 필요하다.
- 데브옵스는 팀의 자율성, 빠른 피드백, 통합 도구 체인, 지속적 통합과 지속적 배포와 같은 기술 실천법을 장려한다.
- 팀은 데브옵스 배포 파이프라인을 통해 높은 품질의 코드를 더 빠르게 빌드/ 테스트/ 릴리스할 수 있다.

2.1.5 시프트 레프트 접근법

조기 테스팅 원리는 테스트를 소프트웨어 개발수명주기 초기에 수행하도록 하는 접근법이기 때문에 시프트 레프트라고도 지칭하기도 한다.
시프트 레프트는 테스트를 더 일찍 수행해야 한다는 것을 의미하지만, 그렇다고 소프트웨어 개발수명주기 후반의 테스트를 무시해도 된다는 의미는 아니다.

< 테스팅에서 시프트 레프트를 달성하는 좋은 일부 프랙티스>

• 테스팅 관점에서 명세를 리뷰. - 모호성, 불완정성, 불일치 등 잠재적인 결함을 발견하는 경우가 많다.
• 코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.
• 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.
• 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적분석을 완료한다.
• 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다. 비기능 테스트는 완성 시스템과 실제 환경을 대변하는 테스트 환경이 가용한 소프트웨어 개발수명주기 후반에 수행하는 경향이 있으므로, 이는 일종의 시프트 레프트가 된다.

>> 시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다. 이해관계자들의 개념을 이해하고 받아들이는 것이 중요하다.

2.1.6 회고 및 프로세스 개선
: 회고 = 프로젝트 종료 후 회의 또는 프로젝트 회고라고 함.

회고는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다. 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기 모델에 따라 달라진다.
결과는 기록해야 하며 이를 테스트 완료 보고서에 포함하는 경우가 많다. 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어지는 것이 중요.

>> 회고와 최종사용자는 관련이 없어.

< 테스팅 관점에서 일반적인 이점 >

• 테스트 효과성/ 효율성 향상(ex> 프로세스 개선 권고 사항 구현을 통해)
• 테스트웨어 품질 향상(ex> 테스트 프로세스를 함께 검토함으로써)
• 팀의 결속 및 학습 향상(ex> 문제를 제기하고, 개선점을 제안할 기회를 제공함으로써)
• 테스트 베이시스 품질 개선(ex> 요구사항의 범위나 품질에서 부족한 점을 발견하고, 수정함으로써)
• 개발(개발자로부터 피드백)과 테스팅 간의 협업 개선(ex> 정기적으로 협업 과정을 검토하고 최적화함으로써) 

전체적으로 외우지 말고 계속 읽어보는 게 공부가 되는 구역. 

용어 정리
: 용어부터 알아둬야 문제 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

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

테스트 유형: 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

테스트 레벨: 테스트 프로세스 중의 특정 예시 단계.

인수 테스팅: 시스템을 승인할지 여부를 결정하는 데 초점을 둔 테스트 레벨.

컴포넌트 테스팅: 개별 하드웨어 또는 소프트웨어 컴포넌트에 초점을 둔 테스트 레벨.

통합 테스팅: 컴포넌트 또는 시스템 간의 상호작용에 중점을 둔 테스트 레벨.

시스템 통합 테스팅: 시스템 간의 상호작용에 초점을 둔 테스트 레벨.

시스템 테스팅:  전체로 봤을 때 시스템이 명시된 요구사항을 충족하는지 확인하는 데 초점을 둔 테스트 레벨.

블랙박스 테스팅: 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식의 테스팅.

화이트 박스 테스팅: 컴포넌트나 시스템의 내부 구조 분석에 기반한 테스팅.

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

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

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

유지보수 테스팅: 운영 중인 시스템에 대한 변화, 또는 운영 중인 시스템에 미치는 환경 변화의 영향에 대한 테스팅.

확인 테스팅: 결함을 수정한 후 해당 결함으로 인해 발생한 장애가 다시 나타나지 않는지 확인하기 위해 수행하는 변경 관련 테스트 유형. 

리그레션 테스팅: 소프트웨어의 변경되지 않은 영역에 결함이 도입 또는 발현되었는지 여부를 감지하기 위한 변경 관련 테스트 유형.

시프트- 레프트: 소프트웨어 개발 라이프 사이클(SDLC)에서 가능한 빨리 보안을 도입하는 것을 의미.

시프트레프트는 위에 말한 사이트에서 찾을 수 없어서 구글로 검색해 봤는데 생각보다 이해해 두고 넘어가는 게 중요할 것 같아서 참고할 만한 블로그를 찾았다. 한번 읽어 보고 넘어가는 걸 추천.

https://katalon.com/resources-center/blog/shift-right-testing

나에게 필요한 공부가 뭐가 있을까 찾아보다 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문제만 맞추면 된다지만 문제들이 생각보다 완벽하게 알지 못하면 헷갈릴 만한 문제들이 많나 보다.

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