# 시프트 레프트

## 시프트-레프트

> 애자일(agile)에서의 품질 보증

* '**조기 품질**'이라는 용어를 더 좀 더 강한 표현으로 바꾼 것
* 제품이나 프로세스의 품질을 높이기 위해 초기 단계에서 설계에 중점을 둔 전략
* **문제는** 요구사항, 설계, 코딩 및 모든 단계에서 발생하는 **버그를 가장 마지막 단계인 테스트를 통해 해결하려고 하는 자세에서 비롯된다.**
  * 개발이 느리게 진행됨
  * 개발자가 자신이 작성한 코드에 관심이 없어짐
* 버그는 사람이 작성한 요구사항과 이를 구현하는 복잡한 코드 과정에서 발생함

### 애자일 품질

* 시프트-레프트와 스크럼은 큰 프레임에서 비슷
* 시프트-레프트를 활용하면 개발 중에 발생하는 버그는 개발 중에 발견할 수 있게된다.

{% hint style="info" %}
**스크럼이란?**

* 코딩이 끝나면 테스트 담당자가 각각 테스트하는 것이 아닌, 코딩하면서 동시에 테스트를 수행하는 것
  {% endhint %}

### 다중 학습

* 스크럼에선 **다중 학습**이 필요하다.
* 팀이 하나가 되어 작업하는 만큼, 팀원이 어떤 작업을 하는지 이해해야 한다.
  * 옆 팀원이 바쁘다면 도와줘야 한다!!
* 스크럼의 기본을 이해한 상태에서 상황에 맞게 품질을 보증하는 팀이 '**애자일의 품질 보증**'을 실현할 수 있다.

### 애자일 테스트란

* 애자일에서는 개발자와 테스트 담당자가 짝을 이뤄 동일한 이터레이션안에서 품질을 보증해야만 한다.
  * **이터레이션**: 짧고 반복적인 주기
* 워터폴 모델에선 개발자가 테스트 담당자에게 품질에 관한 책임을 전가할 수 있지만, 애자일에서는 불가능
  * 품질 및 비용의 최소 절반 이상은 개발팀에 전가됨

### 개발자의 구체적인 작업 지침

* 어떻게 지표를 달성할지에 관한 구체적인 활동을 정의
* 기본적으로는 데이터에 기반한 품질 활동이 항상 중요할 것
* 개발자 테스트에서는 일정 수준 이상의 코드 커버리지 비율을 달성해야함
* 코드 품질을 어떻게 충족할 것인지 등의 목표로서 정의된 지표를 달성하는데 필요한 활동을 정의

### 테스터의 구체적인 작업 지침

* 마지막 단계에서 소프트웨어를 조작하다보면 분명히 버그가 발견됨
* 애자일에서도 품질 데이터 달성을 목표로하는 시스템 테스트는 필요
* 그 밖에도 사용자 시나리오로부터 테스트 케이스 추출해 이터레이션 중에 수행

{% hint style="success" %}
애자일에서는 시스템 테스트 활동이 정의되지 않았지만 시프트-레프트 활동은 필수이며, 시스템 테스트에서 해야 할 활동은 조직이 스스로 정의해야 한다.
{% endhint %}

* 워터폴 모델과 같이, 라이프 사이클 전체에서의 버그 수를 세어서 "버그 수가 줄었으니 릴리즈 합시다!"와 같은 대화는 이후 입 밖으로 낼 수 없는 세계이다.
* 따라서 시스템 테스트를 어떻게 수행할 것인가 보다는 **어떻게 정량적으로 측정할 것인가가 더 중요**
* 진정한 의미에서의 **신뢰도 성장 곡선**을 그려야 한다.&#x20;

## 시프트-레프트 테스트

> 모든 버그를 가장 마지막 이터레이션에서 시스템 테스트로 잡아내려고 하는 시도는 혼돈 상태를 야기한다.

* 각 부품의 신뢰성을 사전에 확인하고, 설계서대로 만들어졌는지를 확인한 뒤에 조립하고 검토해야함
* SW 업계에서 후반 공정에서 소프트웨어 설계는 커녕, 단위 테스트 코드도 작성하지 못하는 인원들이 대규모로 들어와 테스트 대상을 마구잡이로 조작하고, 버그를 만들어내는 것이 일상적인 모습일 때가 많은데, 정말 위험한것

{% hint style="info" %}
**시프트-라이트란**

* 제품 개발 과정에서 가장 분주한 시점을 후반부에 두는 것
* 일정에 맞춰 제품을 릴리즈한다는 의미에서 큰 리스크를 포함한다.
  {% endhint %}

### 시프트-레프트 모델

> 조기 품질을 높이기 위한 모델

{% hint style="danger" %}
시프트-레프트는 시스템 테스트를 확실히 수행하는 것이 아니다.
{% endhint %}

### 조기 품질을 보증하는 요건

> 각 품질의 측면을 고려해서 빠르게 실행!

* 요구사항 사양 및 사용자 스토리의 명확화'
* 클래스나 함수 구조를 간단하게 유지
* 단위 및 통합 테스트 실행
* 코드 리뷰

### 시프트-레프트 테스트 특징

* 일본 IPA(정보처리추진기구)에서 발표한 수치로, 조기 단계에서 품질을 보증하는 것이 출시 후의 품질을 더 높인다고 명확히 기재되어있음
* 만약 조기 단계에서 많은 버그를 발견할 수 있다면, 대부분의 프로젝트에서 큰 폭의 일정 지연이 발생하거나 출시 후에 치명적인 버그가 나타나는 일은 없을것
* 많은 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로 불가능하고, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야함
* 즉, 후반 단계에서 아무리 버그를 찾아낸들, 출시 후의 오류를 줄이는데는 한계가 있다.

### 남은 버그의 리스크

* 조기 단계에 버그를 없애지 않으면 많은 버그가 후반에 발견되고, 마지막까지 발견되지 못한 버그는 출시 후 고객에게 발견될 리스크가 있다.

{% hint style="success" %}
"**조기 코드 인스펙션**, 리뷰, 반복 개발, 주기적 구축 등에 중점을 두면 결함 추출 곡선은 개발 초기 단계(즉, 왼쪽)로 이동한다." - 로런스 퍼트넘
{% endhint %}

{% hint style="info" %}
조기 코드 인스펙션이란&#x20;

* 소프트웨어 개발 초기 단계에서 코드의 품질을 검토하고 오류를 찾아내는 활동

* 코드 리뷰, 테스트 자동화 등
  {% endhint %}

* 프로젝트 후반에 버그를 없애는 비용은 전반에 드는 비용의 수 배에 달함 -> 효율이 낮고 비용 발생

* 프로젝트 후반에 버그를 없애려고 하면, 아직 해결되지 않은 버그가 제품 출시 후에 남겨질 리스크 있음
  * 순전히 운에 따르는 문제가됨
  * 과거에 잘 동작했다고 해서 이후에도 문제가 없으리라고 단언할 수 없음

* 버그 수정에 드는 공수와 개발 단계가 서로 연관되어있음
  * 개발 단계가 한 단계 진행될 때마다 수정 공수는 배가 된다.
  * 단위 테스트에서 발견된 버그가 통합 테스트에서 발견되면 비용이 배가 된다는 것

### 요약

* 시프트-레프트 테스트를 하지 않는다는 것은 출시한 뒤 버그가 발생한다고 보면 된다.
* 시프트-레프트 테스트를 시행하지 않으면(또는 이터레이션 안에서 확실한 테스트를 하지 않으면), 후반 단계에서 아무리 테스트하더라도 큰 리스크를 가진 채 출시하게 된다,.
* 후반 단계에 많은 버그를 고치게되면, 출시일을 우선하게 되는 만큼 일정 확률로 고치지 못한 버그가 남게됨
* 같은 버그를 조기 단계에서 고치는 경우와 후반 단계에 고치는 경우를 비교하면, 비용은 몇배로 불어남
* 최종 단계의 치명적인 버그 또는 출시 후의 버그에 따른 프로젝트 혼란 비용이 가장 높은 이유는 프로젝트 참여하는 전원이 관계되기 때문
* 조기에 테스트를 시행하지 않으면 치명적인 시장 버그가 발생하고 불필요한 개발 비용이 투입됨
* 출시 후 리스크(버그에 의한 매출 저하, 시장 버그 비용)
