Shift-left testing과 전도결함율(前倒し欠陥率) - 2

Dahun Yoo·2022년 8월 7일

QA or Test

목록 보기

26/38

이전 포스트에서 Shift-left test를 실현하기 위해, 빠른 단계인 요구사항 정의와 기획 단계에서의 기획리뷰를 하는 것이 효과적이라고 말씀 드렸습니다.
그러나 이 기획리뷰가 정말로 효과적이다! 라는 것을 어떻게 표현할 수 있을까요?

하나의 가설로 부터 출발

Shift-left test라는 하나의 방법론에 입각해서, 프로젝트나 프로덕트 제작의 Kick-off단계부터 QA/Test담당자가 같이 참여해서 요구사항과 스펙이 빌드업해나가는 과정을 확인하고, 틈틈히 산출물들을 테스트하면서, 이른 타이밍에 테스트계획을 준비하고 테스트케이스를 작성하는 과정을 통해 Shift-left를 한다고 해봅시다.

그럼 정말로 이른 단계에서부터 버그를 없앨 수 있을까요? 이것을 증명할 수 있을까요??

코멘트의 갯수와 버그 개수는 반비례하다?

제가 있던 이전 회사에서는, 아래의 가설을 세우고 데이터를 수집하기 시작했었습니다.

기획단계에서 이해관계자들이 말하는 코멘트들의 개수가 더 많으면 많아질수록 시스템테스트, 릴리즈 후에 발생하는 버그의 갯수는 줄어든다.

그래서 동일피쳐에 대해, 기능추가 안건이 있는 경우 킥오프 단계부터 이해관계자들과 회의록을 훑어가면서 개발 후 구현물에 영향이 있을만한 의사결정 및 지적사항에 대해서 수집하기 시작했습니다.
그러니까, 시프트-레프트 활동을 하기 전후로 시스템 테스트 및 운영환경에서 발생하는 버그들의 차이를 확인하여, 시프트 레프트 활동을 함으로 인하여 효과가 있다는 사실을 검증하기 위해서 였습니다.

확실히 버그의 숫자는 줄어드는 것 처럼 보였으나.. 부서장님은 이것만으로는 부족했는지 어떠한 산식을 가져왔습니다;

전도결함율 (前倒し欠陥率)

前倒し(마에다오시)
예정·예산 등을 앞당겨 씀.

https://ja.dict.naver.com/#/entry/jako/747a1aead4634491913091dca88f110f

굳이 번역하자면 전도결함율 이라고 할 수 있을 것 같습니다.

2018년에 히타치제작소 개발팀의 Matsuda genki 는 소프트웨어 품질 심포지움에서 전도결함율 에 대해 발표하였습니다. 본 포스팅에서는 해당 발표자료와 저의 경험을 바탕으로 기재해봅니다.

https://www.juse.jp/sqip/library/shousai/?id=410

위 연구에 대한 성과에 대해, Matsuda는 아래와 같이 설명하고 있습니다.

장점

Iterative한 개발에서도 운영환경에서의 이슈를 예측할 수 있다.

BTS에서 버그를 관리하고 있다면 계산이 어렵지 않다.

빠른 단계에서 테스트가 필요한 것을 인지하는 것으로 이해, 빠르게 테스트를 진행하고 더 나아가서 개발팀으로의 빠른 피드백을 전달할 수 있다.

단점

프로젝트 종료 시 까지에는 정확한 측정은 어렵다. 때문에 개발중에는 전도율의 추이나 버그 발견 경향을 확인해서 가능하다면 좀 더 빠른 단계에 (Shift-left) 테스트를 해야한다는 의식을 가지는 것이 필요하다.

연구자의 애자일을 도입하게 된 동기와 연구

동기

변화에 유연하게 대응하고 싶다
효율적으로 일하고 싶다
빠르게 리스크를 없애고 싶다.
- (통합테스트를 위해 테스트환경으로 많은 모듈들을 배포해보니 안된다던지 하는 이슈를 없애고 싶었음...)
가치 / 품질을 올리고 싶다

연구했던 내용

2주 단위의 스프린트로 Iterative 개발
1 스프린트에서 E2E테스트까지 진행해서 피드백을 빠르게 주고받기
빌드 자동화
유닛테스트, E2E 테스트 자동화
QA도 설계 초기단계부터 참여해서 요구사항의 검토와 테스트를 실시

스프린트 초기단계에서는 어려운 기능과 리스크 높은 기능을 중점적으로 개발을 하고 후반 스프린트로 갈수록 우선도 낮은 기능들과, 종국에는 버그 수정 및 회귀 테스트등을 실시합니다.

그러나 릴리즈 후에도 버그가 많이 나왔고, E2E 테스트의 버그를 중심적으로 분석하게 됩니다.

버그 발생 경향의 분석

Y축 : 버그의 비율 / X축 : 버그를 발견해낸 날짜 (프로젝트 시작일로부터 종료일을 1로 지정)
좌측 표 : 운영환경 버그가 없었던 프로젝트들 / 우측표 : 운영환경 버그가 있었던 프로젝트들

버그의 경향을 분석해보니, 프로젝트 초기단계에 버그가 많이 나올수록, 운영환경에 릴리즈되어서 버그가 없는 것을 알아차리게 되었고, 반대로 초기 단계에 버그가 안나왔던 프로젝트들에 대해서는 운영 환경에서 버그가 있었다는 것을 알게 됩니다.

여기서 아래의 가설을 세우게 됩니다.

버그를 빨리 찾아내게 된다면, 운영환경에서 발생하는 버그는 적다.

전도율의 제안

종래에 폭포수 개발모델에서 사용하던, 결함 적출 전도율 을 조금 개량해서 애자일 개발모델에서도 사용할 수 있도록 개량을 합니다.

Matsuda 가 시도한, 개량한 전도율은 아래와 같은 특징을 같습니다.

Bug Tracking System의 티켓 생성일을 확인하여, 공정과 관계없이 버그의 전도율을 계산할 수 있다.
Bug Tracking System으로부터 전도율을 자동집계가 가능하도록, 수집 대상을 E2E 테스트의 버그만을 대상으로 한다.

1. 각각의 버그에 대해서 날짜값을 구한다.

티켓의 생성일을 기준으로 계산합니다.

이 티켓들에 대해서 날짜값을 구합니다.
날짜 값은 프로젝트 시작일을 0으로 하고, 프로젝트 종료일을 1로 했을 때, 이것을 표준화시키는 값입니다.

버그들을 bug 라고 하고, 각각의 버그를 bug[i] 라고 한다면,
bug[i].date 값은 아래와 같이 표현할 수 있습니다.

$\frac{버그\quad발생일 - 프로젝트\quad시작일}{프로젝트\quad종료일-프로젝트\quad시작일}$

2. 전도율 계산하기

위 내용을 이해하였다면, 전도율은 아래와 같이 구해볼 수 있을 것입니다.

$전도율 = 1-\frac{\sum_{i=1}^{N}bug[i].date}{N}$

예를들어, 90일간의 프로젝트에서, bug[i] 의 티켓 생성일이 프로젝트 시작일로부터 20일째라고 한다면, bug[1].date 는

$bug[i].date = 20/90 = 0.222$

로 계산할 수 있을 것입니다.

또한 bug[1].date ~ bug[8].date 의 평균이 0.7이라고 한다면, 전도율은 1 - 0.7 = 0.3 이 될 것 입니다.

위를 통해서 전도율이 높으면 높을 수록, 빠른 공정에서 버그를 찾아내거나, 막았다는 것을 알 수 있습니다.

가중치를 계산한 전도율

그런데, 보통 버그를 생성할때는 중요도나 대응 우선도와 같은 Priority를 추가로 설정하기도 합니다.
단순히 전도율을 계산하는거에 그치지 않고, 우선도나 중요도를 고려해서 가중치를 추가로 적용해봅니다.

예를 들어 가중치를 아래와 같이 적용한다고 가정해봅시다.

중요도	가중치	버그 수
Major	3	$N_3$
Minor	2	$N_2$
Trivial	1	$N_1$

각 버그에 대해 bug[i].date * 중요도 로 계산해줍니다.

위를 이용해 가중치를 고려한 전도율을 구할 수 있습니다.

$1-\frac{\sum_{i=1}^{N}3\ast bug[i].date+\sum_{i=1}^{N}2\ast bug[i].date+\sum_{i=1}^{N}1\ast bug[i].date} {3\ast N_3+2\ast N_2+1\ast N_1}$

즉 각각의 가중치를 반영한 bug[i].date의 합계 / 가중치의 합계를 구한 후 1에서 빼는 것입니다.

상: 가중치를 계산하지 않은 전도율로 계산한 프로젝트 / 하: 가중치를 계산한 전도율로 계산한 프로젝트

가중치를 고려함으로 좀 더 정밀한 전도율을 구할 수 있었습니다.

전도율 계산으로 얻는 장단점

장점

Iterative한 개발에서도 운영환경에서의 이슈를 예측할 수 있다.
BTS에서 버그를 관리하고 있다면 계산이 어렵지 않다.
빠른 단계에서 테스트가 필요한 것을 인지하는 것으로 이해, 빠르게 테스트를 진행하고 더 나아가서 개발팀으로의 빠른 피드백을 전달할 수 있다.

단점

프로젝트 종료 시 까지에는 정확한 측정은 어렵다. 때문에 개발중에는 전도율의 추이나 버그 발견 경향을 확인해서 가능하다면 좀 더 빠른 단계에 (Shift-left) 테스트를 해야한다는 의식을 가지는 것이 필요하다.

Shift-left testing과 전도결함율

발표자료에서는 전도결함율을 구하기 위해, E2E Test 단계에서 발생한 버그들을 대상으로 계산했습니다만, 이것은 굳이 E2E Test에서 발생한 버그들을에만 한정시킬 필요는 없습니다.

Kick-off단계에서부터, 프로덕트에 영향이 미치는 코멘트나 버그가 될뻔했던 내용들을 수정했던 내용에 대해 티켓으로 관리, 혹은 미팅을 진행한 날을 기록해서 전도율을 계산한다면, 시프트 레프트를 수행한 안건에 대해 측정할 수 있는 형태의 데이터를 얻을 수 있게 됩니다.

개인 경험

다시 처음으로 돌아가서, 저희 부서장님은 이 전도결함율을 가져와서 일부 프로젝트에 대해 시범적으로 계산을 하였는데, 생각보다 효과가 있었고 QA/Test 담당자들의 Shift-left 활동을 격려하기도 하였습니다.

물론 모든 프로덕트에서 효과가 있었던 것은 아닙니다.
QA/Test 담당자의 요구사항 분석능력도 한층 더 중요해졌는데 담당자들의 역량에 따라 다르기 때문입니다.

또한 많은 이해관계자들은 QA/Test 담당자들을 안건의 Kick-off 부터 초대해서 같이 진행하고자 하진 않습니다. 이해관계자들이 잘못했다기 보다는, 종래의 많은 프로젝트들이 기획이 완성되거나, 프로덕트가 완성되는 시점에 테스트 담당자들에게 연락을 하고 테스트를 해달라고 해왔기 때문입니다.

따라서 이러한 경우에는 이해관계자들에게 Shift-left와 함께 활동하고자 하는 바를 전달해서 의식을 개선시켜야겠습니다.

Ref