시프트 레프트
시프트-레프트
애자일(agile)에서의 품질 보증
'조기 품질'이라는 용어를 더 좀 더 강한 표현으로 바꾼 것
제품이나 프로세스의 품질을 높이기 위해 초기 단계에서 설계에 중점을 둔 전략
문제는 요구사항, 설계, 코딩 및 모든 단계에서 발생하는 버그를 가장 마지막 단계인 테스트를 통해 해결하려고 하는 자세에서 비롯된다.
개발이 느리게 진행됨
개발자가 자신이 작성한 코드에 관심이 없어짐
버그는 사람이 작성한 요구사항과 이를 구현하는 복잡한 코드 과정에서 발생함
애자일 품질
시프트-레프트와 스크럼은 큰 프레임에서 비슷
시프트-레프트를 활용하면 개발 중에 발생하는 버그는 개발 중에 발견할 수 있게된다.
스크럼이란?
코딩이 끝나면 테스트 담당자가 각각 테스트하는 것이 아닌, 코딩하면서 동시에 테스트를 수행하는 것
다중 학습
스크럼에선 다중 학습이 필요하다.
팀이 하나가 되어 작업하는 만큼, 팀원이 어떤 작업을 하는지 이해해야 한다.
옆 팀원이 바쁘다면 도와줘야 한다!!
스크럼의 기본을 이해한 상태에서 상황에 맞게 품질을 보증하는 팀이 '애자일의 품질 보증'을 실현할 수 있다.
애자일 테스트란
애자일에서는 개발자와 테스트 담당자가 짝을 이뤄 동일한 이터레이션안에서 품질을 보증해야만 한다.
이터레이션: 짧고 반복적인 주기
워터폴 모델에선 개발자가 테스트 담당자에게 품질에 관한 책임을 전가할 수 있지만, 애자일에서는 불가능
품질 및 비용의 최소 절반 이상은 개발팀에 전가됨
개발자의 구체적인 작업 지침
어떻게 지표를 달성할지에 관한 구체적인 활동을 정의
기본적으로는 데이터에 기반한 품질 활동이 항상 중요할 것
개발자 테스트에서는 일정 수준 이상의 코드 커버리지 비율을 달성해야함
코드 품질을 어떻게 충족할 것인지 등의 목표로서 정의된 지표를 달성하는데 필요한 활동을 정의
테스터의 구체적인 작업 지침
마지막 단계에서 소프트웨어를 조작하다보면 분명히 버그가 발견됨
애자일에서도 품질 데이터 달성을 목표로하는 시스템 테스트는 필요
그 밖에도 사용자 시나리오로부터 테스트 케이스 추출해 이터레이션 중에 수행
애자일에서는 시스템 테스트 활동이 정의되지 않았지만 시프트-레프트 활동은 필수이며, 시스템 테스트에서 해야 할 활동은 조직이 스스로 정의해야 한다.
워터폴 모델과 같이, 라이프 사이클 전체에서의 버그 수를 세어서 "버그 수가 줄었으니 릴리즈 합시다!"와 같은 대화는 이후 입 밖으로 낼 수 없는 세계이다.
따라서 시스템 테스트를 어떻게 수행할 것인가 보다는 어떻게 정량적으로 측정할 것인가가 더 중요
진정한 의미에서의 신뢰도 성장 곡선을 그려야 한다.
시프트-레프트 테스트
모든 버그를 가장 마지막 이터레이션에서 시스템 테스트로 잡아내려고 하는 시도는 혼돈 상태를 야기한다.
각 부품의 신뢰성을 사전에 확인하고, 설계서대로 만들어졌는지를 확인한 뒤에 조립하고 검토해야함
SW 업계에서 후반 공정에서 소프트웨어 설계는 커녕, 단위 테스트 코드도 작성하지 못하는 인원들이 대규모로 들어와 테스트 대상을 마구잡이로 조작하고, 버그를 만들어내는 것이 일상적인 모습일 때가 많은데, 정말 위험한것
시프트-라이트란
제품 개발 과정에서 가장 분주한 시점을 후반부에 두는 것
일정에 맞춰 제품을 릴리즈한다는 의미에서 큰 리스크를 포함한다.
시프트-레프트 모델
조기 품질을 높이기 위한 모델
시프트-레프트는 시스템 테스트를 확실히 수행하는 것이 아니다.
조기 품질을 보증하는 요건
각 품질의 측면을 고려해서 빠르게 실행!
요구사항 사양 및 사용자 스토리의 명확화'
클래스나 함수 구조를 간단하게 유지
단위 및 통합 테스트 실행
코드 리뷰
시프트-레프트 테스트 특징
일본 IPA(정보처리추진기구)에서 발표한 수치로, 조기 단계에서 품질을 보증하는 것이 출시 후의 품질을 더 높인다고 명확히 기재되어있음
만약 조기 단계에서 많은 버그를 발견할 수 있다면, 대부분의 프로젝트에서 큰 폭의 일정 지연이 발생하거나 출시 후에 치명적인 버그가 나타나는 일은 없을것
많은 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로 불가능하고, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야함
즉, 후반 단계에서 아무리 버그를 찾아낸들, 출시 후의 오류를 줄이는데는 한계가 있다.
남은 버그의 리스크
조기 단계에 버그를 없애지 않으면 많은 버그가 후반에 발견되고, 마지막까지 발견되지 못한 버그는 출시 후 고객에게 발견될 리스크가 있다.
"조기 코드 인스펙션, 리뷰, 반복 개발, 주기적 구축 등에 중점을 두면 결함 추출 곡선은 개발 초기 단계(즉, 왼쪽)로 이동한다." - 로런스 퍼트넘
조기 코드 인스펙션이란
소프트웨어 개발 초기 단계에서 코드의 품질을 검토하고 오류를 찾아내는 활동
코드 리뷰, 테스트 자동화 등
프로젝트 후반에 버그를 없애는 비용은 전반에 드는 비용의 수 배에 달함 -> 효율이 낮고 비용 발생
프로젝트 후반에 버그를 없애려고 하면, 아직 해결되지 않은 버그가 제품 출시 후에 남겨질 리스크 있음
순전히 운에 따르는 문제가됨
과거에 잘 동작했다고 해서 이후에도 문제가 없으리라고 단언할 수 없음
버그 수정에 드는 공수와 개발 단계가 서로 연관되어있음
개발 단계가 한 단계 진행될 때마다 수정 공수는 배가 된다.
단위 테스트에서 발견된 버그가 통합 테스트에서 발견되면 비용이 배가 된다는 것
요약
시프트-레프트 테스트를 하지 않는다는 것은 출시한 뒤 버그가 발생한다고 보면 된다.
시프트-레프트 테스트를 시행하지 않으면(또는 이터레이션 안에서 확실한 테스트를 하지 않으면), 후반 단계에서 아무리 테스트하더라도 큰 리스크를 가진 채 출시하게 된다,.
후반 단계에 많은 버그를 고치게되면, 출시일을 우선하게 되는 만큼 일정 확률로 고치지 못한 버그가 남게됨
같은 버그를 조기 단계에서 고치는 경우와 후반 단계에 고치는 경우를 비교하면, 비용은 몇배로 불어남
최종 단계의 치명적인 버그 또는 출시 후의 버그에 따른 프로젝트 혼란 비용이 가장 높은 이유는 프로젝트 참여하는 전원이 관계되기 때문
조기에 테스트를 시행하지 않으면 치명적인 시장 버그가 발생하고 불필요한 개발 비용이 투입됨
출시 후 리스크(버그에 의한 매출 저하, 시장 버그 비용)
Last updated