Finding Signal Through The Noise by Jarrett Rosenberg

는 전세계적으로 소프트웨어 테스팅, 품질 관리 등의 주제에 관한한 가장 대중적인 잡지일 것이다. 예전에는 이 잡지를 계속 구독하면서 유명한 사람들이 누구인지, 그들이 고민하는 것이 무엇인지를 간접 경험하곤 했었다. 이제는 여러 가지 이유로 구독은 하지 않지만, 이런 잡지가 계속 발견되는 그들의 환경이 부러운 것이 사실이다. 우리도 STEN이 국내에 존재하지만, 저널은 나오지 않은지가 수 개월이 되는 듯 하다. 영미권을 제외하고는 이런 잡지가 없는 걸 보면, 소프트웨어 테스팅에 대한 저변이 아무래도 다른 나라들은 넓지 않은듯 싶다. 가까운 일본의 사정은 참으로 알 기회가 없는데, 일본은 어떨까?

예전에 번역을 해 두었던 걸 올리기로 한다.

소프트웨어 테스팅 분야가 깊어지면 여러 가지 다른 학문의 도움을 받게 마련인데(이건 다른 분야도 매 한가지인 것 같다.), 역시 통계 분야가 가장 도움이 되지 싶다. 예전 번역이라 실력이 미천할 때라 잘된 번역이라 할 수는 없지만, 역자의 하드 어딘가에서 굴러 다니기 보다는 아무래도 빛을 보는게 나으리라. 스스로 위안을 삼으며 올려본다.

이 원문은 인터넷에 공개가 되어 있지 않아 링크를 연결할 수가 없다. 다만, 이런 곳에서 얻을 수 있다는 흔적만 남긴다.

필자가 통계학자라니 기가 막히다. QA 엔지니어가 통계학자이며, 게다가 박사라니...  할 말이 없다... -_-

이하 번역이 나간다~~

노이즈에서 신호를 찾아내기

당신이 측정한 데이터에서 의미있는 정보를 뽑아내는 기본적인 가이드 라인

by Jarrett Rosenberg

소프트웨어 품질 엔지니어가 작업을 하는데 있어 데이터가 부족하진 않다. 버그 개수, 버그 밀도, 변경된 라인수, 테스트 커버리지 수 그리고 등등등. 업무의 중요한 부분은 이러한 결과를 정확하게 해석하는 것으로, 어떤 것이 진짜이고 어떤 것이 가짜인지, 어떤 것이 관계가 있고 어떤 것이 관계가 없는지 결정하는 것이다. 이런 것을 생각하는 유용한 방법은 불규칙한 변화나 에러로 유발된 노이즈에서 신호를 찾으려고 노력하는 것이다.

많은 사람들이, 심지어 엔지니어까지도 노이즈가 아예 없는 것처럼 행동한다. 이들은 무슨 일이 발생했는지 왜곡없이 정확하게 반영된 것처럼 완전히 문자 그대로 숫자를 받아들인다. 그게 어떤 때는 맞을 수도 있지만 일반적으로는 신호의 근본을 왜곡하지 않는 불규칙한 변화도 다수 존재한다. 하지만 그것으로 당신이 상황을 완전히 잘못
판단하게 만들 수 있다. 더 심각한 상황은 불규칙한 변화가 정말로 "완전히 제어되고 있는" 것처럼 보일 수 있다는 점이다. 자전거를 처음 타는 사람에게 매우 힘이 드는 코스로 인도한다거나, 아무것도 필요치 않은 상황인데 반대로 인식되거나, 시스템을 더 많이 변동하게 하거나 하는 등이다.

노이즈가 발생하는 두 가지 근본적인 원인은 샘플링 에러와 측정 에러이다. 전자는 당신이 원했던 모든 측정 값을 수집하지 못해서 전체 값 중에서 일부만 가지고 작업하는 것이다. 예를 들어, 당신은 베타 사이트가 우리가 예상하는 일반적인 유저의 구성을 가지게 될 것이라고 기대하지만 많은 수의 베타 사이트를 확보하지 못하는 경우 우연히 특정 유형이 너무 많거나 너무 적은 유저(사용 시나리오)만 확보하게 된다.

측정 에러는 기록 오류와 함께 측정된 값의 일부분이 부정확할 때 발생한다. 최종적인 결과는 에러의 근원이 제거되었던 아니던 간에 당신이 원하던 그 숫자가 아니다.
다음에서 불규칙 변화와 에러를 구별하고 어떻게 그 값을 보정하는지 도와줄 수 있는 팁을 소개한다.

관찰 기록을 표준화하라

일반적으로 결정을 내리려면 두 개 또는 그 이상의 숫자를 비교하는 작업을 한다. 시간을 두고 무언가를 추적하는 것 역시 비교이며 빈번하게 쓰이는 비교 방법중 하나이다. 이런 비교를 할 때 중요한 것은 실제적으로 단위를 동일하게 해놓고 비교하는 것이다. (그림 1)은 1년 동안의 월별 버그 수를 나타내고 있다. 수치가 올라갔다가 내려갔다 하는 것을 볼 때 10월에 그래프가 급증한 것으로 관리적인 문제와 관련이 있을 것으로 볼 수 있고 이런 그래프는 다음 달에 버그 수가 감소한 결과를 볼 때 문제가 직접적으로 수정된 것으로 이해될 수 있다.

하지만, 사실은 이 데이터에서 그러한 일은 발생하지 않았다. 이것은 매달 이렇게 보여졌을 뿐이다. 하지만 정의하기에 따라 "월"은 길이가 변경되며 휴일이나 다른 예정되지 않은 이벤트들에 의해서 그 차이는 더 커질 수 있다. 우리가 버그 리포트 데이터를 그 달에 실제로 일을 한 숫자로 표준화할 수 있다면(실제 일한 일수로 버그 수를 나누어서), (그림 2)와 같은 일년간 쭉 일정한 버그 수를 보여주는 그래프를 볼 수 있을 것이다. 결론적으로 그래프의 변화는 버그에 수에 의해서 발생한 것이 아니고 실제는 작업 일수의 영향을 받은 것이다.

비슷한 개념으로 각기 다른 날에 서로 다른 분량의 테스트가 수행되었는지 어떤지 측정하는데 작업 일수가 사용될 수 있다. 중요한 것은 인자에서 빼거나 나누어 노이즈를 제거하는 것이다.

데이터 수집을 등급별로 하라

사과와 오렌지를 구별하는 것이 어렵다면 같은 바구니에 그 두개를 담는 것은 더 나쁜 방법이다. 가끔은 잘못된 데이터 수집 절차가 신호를 노이즈로 변화시키기도 한다. 무차별적으로 다른 종류의 데이터를 섞는다면 각각의 신호는 서로간에 간섭하는 노이즈가 될 것이다. 예를 들어, 일반적으로 버그는 심각도에 따라 그룹핑되어 지고 (high / medium / low), 월별 버그 리포트는 각 심각도에 관계 없이 하나의 수치로 나타내어 지는데 반해 버그 수정의 노력은 항상 분류된 심각도에 의해서 분석된다.

(그림 3)은 12달 동안의 작업 일수 당 버그수를 보여주고 있다. 이 그림은 일반적으로 감소세에 있는 유형인 것처럼 보이는데 우리가 다시 high, medium, low 심각도로 나누어서 그래프를 작성하면 (그림 4)와 같이 된다. 그러면 실제 high 심각도의 버그는 증가하는데 반해 low 심각도의 버그가 전반적인 그래프의 유형을 주도한다는 것을 알 수 있다. 결국 품질은 좋아 지는 것이 아니라 나빠지는 것이다!(* 역자주 : 버그 수 그래프가 낮아 지는 것은 품질이 좋아 지는 것) 정리하면 동일한 유형의 데이터끼리 그룹핑을 할 때 노이즈 레벨은 감소하게 된다.

불 충분한 데이터를 보정하라

때때로 노이즈는 정보가 부족한 상황이 아니라 상관 없는 정보가 추가됨으로서 발생하게 된다. 각각의 데이터는 불충분하다. 통계학자들은 이것을 "data censoring" 이라고 부른다. 예를 들어, 버그 수정에 얼마나 걸렸는지 알아내려면 버그 데이터 베이스를 변경하고 접수된 버그의 라이프타임을 추가할 수 있을 것이다. 하지만, 당신의 샘플은 아직 수정이 완료되지 않은 버그를 포함하고 있을 것이고 따라서 그 완료되지 않은 버그는 "종료된" 날짜를 포함하고 있지 않을 것이다. 이런 데이터 들은 검열되어야 한다.(* 역자주 : 아직 모르는 데이터로 인한 영향을 최소화 할 수 있는 방법은 전체 값 중에서 모르는 데이터의 영향만 지우는 것이기 때문에 검열이라는 표현을 사용함) 현재까지는 최종적인 값(* 역자주 : 수정 완료일)이 아닌 수정하는데 약간의 시간이 더 걸린다는 것만 알고 있다. 한 버그가 바로 어제 오픈되었다면 수정 완료일은 하루, 한달, 일년중 어떤 값이라도 가질 수 있다.
이런 문제의 일반적인 반응은 단순히 부정확한 관측값을 버리는 것이다. 하지만 샘플에 변형을 가져오고, 측정 값을 한쪽으로 치우치게 한다. 일반적으로 이런 치우침은 내려가는 경향이 있는데 이는 아주 긴 지속 시간을 가지는 케이스가 대부분 아직 완료되지 않은 것이기 때문이다. 이런 케이스에 대해서 어떻게 하면 정확하게 측정할 수 있을까?
통계학자들은 이런 검열된 데이터를 다루는 몇 가지 방법을 개발했으나 이런 것들은 특별한 교육을 필요로 하거나 통계 소프트웨어의 도움을 필요로 한다. 하지만, 아래에 항상 적용할 수 있는 방법을 소개한다.

 o 거의 동일한 시간에 시작한 케이스를 선택한다. 예를 들어, 같은 주(week)나  월(month)중에서 시작일이 같은 모든 버그 리포트를 선택하는 것이다. 이것은  시간 추이를 반영하는 "코호트"(통계 인자를 공유하는 집단)가 될 수 있다.

 o 이런 버그중 75%가 종료될 때까지 추적해 본다. 이 지점에서 수정에 걸리는 중간값은 "코호트" 값의 시작에서 지금까지의 시간이 되며 중간값(75%)이 수정 시간의 순위에 기반하게 되면 더 이상 그것은 실제 값이 아니게 된다. 따라서, 남아 있는 50%의 앞으로 발생한 수정 시간이 무엇이든 관계 없이 중간 값은 변하지 않게 된다.(그림 5)

수정 완료에 걸리는 시간 변화를 알아내기 위해서는 이들의 시작 시간과 반대로 연속적인 "코호트"의 중간값을 그래프로 그린다. 이것은 이전에 비해 더 버그 수정에 걸리는 시간이 짧아 졌는지 길어 졌는지 알려주는 경향 챠트를 만들 수 있게 한다.
이 방법의 단점은 경향 파악이 늦게 된다는 것이다. 즉 몇 주나 몇 달 전에 오픈된 버그 수정 시간의 중간값을 보여주지 오늘 오픈된 버그가 어떻게 되는지는 알려주지 못한다는 점이다. 하지만 이런 불편은 간단하고 치우침이 없는 방법을 사용하기 때문에 감수해야 한다. 만약 수정 시간이 적절하게 빠르고 "코호트" 값이 짧은 간격(몇 주)에 기초하고 있다면 지연은 참을 수 있을 것이다.(어쨋든, 긴 휴일이전에 오픈된 버그 리포트가 수정에 더 시간이 걸린다는 점을 알아챘다면, 시간 측정으로 달력의 일수 대신에 작업 일수를 사용하기를 원할 것이다.)

대부분의 시간이 공평하게 짧거나 몇 개의 시간이 아주 크다면 항상 수정시간 같은 지속 시간은 편향적인 분포를 보인다는 점을 주의하라.
이러한 편향성은 끝을 향하는 형상의 분포도의 중심을 산술 평균쪽으로 끌어당기게 되어 어떤 데이터가 가장 많은지 잘못 판단하게 만든다. 중간값은 이러한 편향의 영향을 덜 받기 때문에 일반적으로 버그 수정에 걸리는 "평균" 시간을 측정하는 좋은 방법이다.

전체적인 그림을 보라

방금 설명한 방법은 변화성 보다는 의미나 중간 값에 초점을 맞춘 것이다. 변화성은 주로 노이즈로 취급되지만 가끔은 그 자체로도 유용한 정보를 전달해 준다. 통계적인 프로세스 제어의 어떤 방법은 하나의 프로세스 내에서의 변화성의 양과 평균 경향이 논리적으로 독립적이라면 두 가지 모두 측정하기도 한다. 가끔은 산술 평균이나 중간값 뿐 아니라 변화성의 근거가 비교에 유용할 때도 있다. 이것을 수행하는 가장 간단한 방법은 범위(가장 큰 값과 가장 작은 값의 차이) 측정이지만 문외한에게 어려운 아주 정밀한 작업이다. 더 유용한 방법은 "사분위 사이의 범위"로 불리는 25% ~ 75% 사이의 차이값이다. (그림 6)
예를 들어, 버그 수정 시간의 범위가 몇 몇 버그의 수정이 오래 걸린 것(수정하는데 실패하거나 수정하는 사람이 아파서 작업을 하지 못해)에 의해 증가하거나 화면상의 오자 수정으로 버그 수정 시간이 몇 초만 걸릴 수 있다. 하지만, 이 이외의 케이스에서는 "4분위 사이의 범위"가 완전히 영향받지 않을 것이다.

변화성을 의미있는 정보로 변환하는 또 다른 방법은 극단적인 것에 집중하는 것이다. 말하자면 프로세스를 분해(또는 진행)에 대한 가치있는 정보를 제공할 수 있는 극단적인 케이스를 살펴보는 것이다. 어떤 데이터에 대한 유용한 테크닉은 아주 높은 혹은 낮은 값을 보고 그 값이 왜 그런지 물음을 던지는 것이다. 아마 그 답에 대해 당신은 놀라게 될 것이다.

노이즈에서 신호를 찾아내기

이러한 모든 방법들은 전혀 관계 없는 변화에도 실제 무엇이 진행되고 있는지를 찾아 낼 목적으로 결과를 분석해 보았으며 변화를 제거해 보고, 그것을 보정해 보고, 심지어 직접적으로 이용해 보았다. 특정한 적용 방법은 끝이 없겠지만 기초가 되는 아이디어는 항상 동일하다.

data = information + noise

Jarrett Rosenberg는 Sun Microsystems의 품질 엔지니어이며 통계학자이다. 버클리 캘리포니아 대학에서 통계학 박사 학위를 받았고 1990년에 Sun에 입사전까지 Xerox와 Hewlett Packard에서 일했다. 그는 American Statistical Association과 IEEE Computer Society의 회원이며 ASQ 인증의 소프트웨어 품질 매니저 이다. 그와
연락하려면 Jarrett.Rosenberg@Sun.com를 이용하라.

{끝}