시프트 레프트

시프트-레프트

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

• '조기 품질'이라는 용어를 더 좀 더 강한 표현으로 바꾼 것

• 제품이나 프로세스의 품질을 높이기 위해 초기 단계에서 설계에 중점을 둔 전략

• 문제는 요구사항, 설계, 코딩 및 모든 단계에서 발생하는 버그를 가장 마지막 단계인 테스트를 통해 해결하려고 하는 자세에서 비롯된다.

  • 개발이 느리게 진행됨

  • 개발자가 자신이 작성한 코드에 관심이 없어짐

• 버그는 사람이 작성한 요구사항과 이를 구현하는 복잡한 코드 과정에서 발생함

애자일 품질

• 시프트-레프트와 스크럼은 큰 프레임에서 비슷

• 시프트-레프트를 활용하면 개발 중에 발생하는 버그는 개발 중에 발견할 수 있게된다.

스크럼이란?

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

다중 학습

• 스크럼에선 다중 학습이 필요하다.

• 팀이 하나가 되어 작업하는 만큼, 팀원이 어떤 작업을 하는지 이해해야 한다.

  • 옆 팀원이 바쁘다면 도와줘야 한다!!

• 스크럼의 기본을 이해한 상태에서 상황에 맞게 품질을 보증하는 팀이 '애자일의 품질 보증'을 실현할 수 있다.

애자일 테스트란

• 애자일에서는 개발자와 테스트 담당자가 짝을 이뤄 동일한 이터레이션안에서 품질을 보증해야만 한다.

  • 이터레이션: 짧고 반복적인 주기

• 워터폴 모델에선 개발자가 테스트 담당자에게 품질에 관한 책임을 전가할 수 있지만, 애자일에서는 불가능

  • 품질 및 비용의 최소 절반 이상은 개발팀에 전가됨

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

• 어떻게 지표를 달성할지에 관한 구체적인 활동을 정의

• 기본적으로는 데이터에 기반한 품질 활동이 항상 중요할 것

• 개발자 테스트에서는 일정 수준 이상의 코드 커버리지 비율을 달성해야함

• 코드 품질을 어떻게 충족할 것인지 등의 목표로서 정의된 지표를 달성하는데 필요한 활동을 정의

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

• 마지막 단계에서 소프트웨어를 조작하다보면 분명히 버그가 발견됨

• 애자일에서도 품질 데이터 달성을 목표로하는 시스템 테스트는 필요

• 그 밖에도 사용자 시나리오로부터 테스트 케이스 추출해 이터레이션 중에 수행

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

• 워터폴 모델과 같이, 라이프 사이클 전체에서의 버그 수를 세어서 "버그 수가 줄었으니 릴리즈 합시다!"와 같은 대화는 이후 입 밖으로 낼 수 없는 세계이다.

• 따라서 시스템 테스트를 어떻게 수행할 것인가 보다는 어떻게 정량적으로 측정할 것인가가 더 중요

• 진정한 의미에서의 신뢰도 성장 곡선을 그려야 한다.

시프트-레프트 테스트

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

• 각 부품의 신뢰성을 사전에 확인하고, 설계서대로 만들어졌는지를 확인한 뒤에 조립하고 검토해야함

• SW 업계에서 후반 공정에서 소프트웨어 설계는 커녕, 단위 테스트 코드도 작성하지 못하는 인원들이 대규모로 들어와 테스트 대상을 마구잡이로 조작하고, 버그를 만들어내는 것이 일상적인 모습일 때가 많은데, 정말 위험한것

시프트-라이트란

• 제품 개발 과정에서 가장 분주한 시점을 후반부에 두는 것

• 일정에 맞춰 제품을 릴리즈한다는 의미에서 큰 리스크를 포함한다.

시프트-레프트 모델

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

시프트-레프트는 시스템 테스트를 확실히 수행하는 것이 아니다.

조기 품질을 보증하는 요건

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

• 요구사항 사양 및 사용자 스토리의 명확화'

• 클래스나 함수 구조를 간단하게 유지

• 단위 및 통합 테스트 실행

• 코드 리뷰

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

• 일본 IPA(정보처리추진기구)에서 발표한 수치로, 조기 단계에서 품질을 보증하는 것이 출시 후의 품질을 더 높인다고 명확히 기재되어있음

• 만약 조기 단계에서 많은 버그를 발견할 수 있다면, 대부분의 프로젝트에서 큰 폭의 일정 지연이 발생하거나 출시 후에 치명적인 버그가 나타나는 일은 없을것

• 많은 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로 불가능하고, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야함

• 즉, 후반 단계에서 아무리 버그를 찾아낸들, 출시 후의 오류를 줄이는데는 한계가 있다.

남은 버그의 리스크

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

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

조기 코드 인스펙션이란

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

• 코드 리뷰, 테스트 자동화 등

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

• 프로젝트 후반에 버그를 없애려고 하면, 아직 해결되지 않은 버그가 제품 출시 후에 남겨질 리스크 있음

  • 순전히 운에 따르는 문제가됨

  • 과거에 잘 동작했다고 해서 이후에도 문제가 없으리라고 단언할 수 없음

• 버그 수정에 드는 공수와 개발 단계가 서로 연관되어있음

  • 개발 단계가 한 단계 진행될 때마다 수정 공수는 배가 된다.

  • 단위 테스트에서 발견된 버그가 통합 테스트에서 발견되면 비용이 배가 된다는 것

요약

• 시프트-레프트 테스트를 하지 않는다는 것은 출시한 뒤 버그가 발생한다고 보면 된다.

• 시프트-레프트 테스트를 시행하지 않으면(또는 이터레이션 안에서 확실한 테스트를 하지 않으면), 후반 단계에서 아무리 테스트하더라도 큰 리스크를 가진 채 출시하게 된다,.

• 후반 단계에 많은 버그를 고치게되면, 출시일을 우선하게 되는 만큼 일정 확률로 고치지 못한 버그가 남게됨

• 같은 버그를 조기 단계에서 고치는 경우와 후반 단계에 고치는 경우를 비교하면, 비용은 몇배로 불어남

• 최종 단계의 치명적인 버그 또는 출시 후의 버그에 따른 프로젝트 혼란 비용이 가장 높은 이유는 프로젝트 참여하는 전원이 관계되기 때문

• 조기에 테스트를 시행하지 않으면 치명적인 시장 버그가 발생하고 불필요한 개발 비용이 투입됨

• 출시 후 리스크(버그에 의한 매출 저하, 시장 버그 비용)