노년코딩

들어가기 전 알아둬야 하는 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> 정기적으로 협업 과정을 검토하고 최적화함으로써) 

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