-
원래 주소: 버그가 수정되지 않는 이유
저자: Alan Page, Microsoft 테스트 엔지니어링 부문 이사, How We Test Software at Microsoft(중국어 번역: "Microsoft의 소프트웨어 테스팅 방식")의 공동 저자.
번역: Lu Yueli, Lu Mengyan, 왕홍
최근에는 버기 제품이 출시된다는 사실에 놀라시는 분들이 점점 많아지고 있습니다. 제가 놀랐던 점은 이들 중 상당수가 소프트웨어 테스터라는 점이었습니다. 그들은 이미 이에 대해 알고 있을 것이라고 생각했습니다. Eric Sink의 이전(그러나 훌륭한) 기사를 먼저 읽어보시기 바랍니다. 이 주제에 얼마나 더 기여할 수 있을지는 모르겠지만 시도해 보고 싶습니다.
많은 버그는 고칠 가치가 없습니다. "당신은 테스터입니까?", "테스터는 제품 품질의 수호자입니다."라고 다시 한 번 반복할 수 있습니다. 많은 버그는 고칠 가치가 없습니다. "이유를 알려드리겠습니다. 대부분의 경우 버그를 수정하려면 코드를 변경해야 합니다. 그리고 코드를 변경하려면 리소스(시간)의 투자가 필요하고 위험이 따릅니다. 짜증나지만 사실입니다. 때로는 위험과 투자가 멀리 떨어져 있으면 버그를 수정하는 것의 가치보다 더 중요하므로 우리는 버그를 수정하지 않을 것입니다.
버그 수정 여부에 대한 우리의 결정은 "느낌"에 기초하여 이루어져서는 안 됩니다. 나는 결정을 내리는 데 도움이 되도록 "사용자 고통"이라는 개념을 사용하는 것을 좋아합니다. 나는 "사용자 고통"을 고려하고 식별하기 위해 세 가지 핵심 요소를 사용합니다.
1. 심각도 - 이 버그는 어떤 영향을 미치나요? 전체 프로그램에 충돌이 발생합니까? 사용자 정보가 손실되나요? 아니면 그다지 심각하지 않은가? 더 쉬운 해결책이 있나요? 아니면 그냥 별 상관없는 문제인가요?
2. 빈도 - 사용자가 이 문제를 자주 경험합니까? 프로그램의 주요 작업 흐름의 일부인가요? 아니면 일반적으로 사용되지 않는 기능에 숨겨져 있는 걸까요? 프로그램의 가장 일반적으로 사용되는 부분에 존재하는 작은 문제는 아마도 수정되어야 할 것이며, 프로그램의 덜 일반적으로 사용되는 부분에 존재하는 일부 큰 문제는 제쳐두어도 됩니다.
3. 고객에 대한 영향 - 숙제를 잘 마쳤다면 고객이 누구인지, 그리고 각 고객 그룹에 사용자가 몇 명(또는 원하는 수)이 있는지 이미 알고 있어야 합니다. 그런 다음 이 문제가 모든 사용자에게 영향을 미치는지, 아니면 일부 사람들에게만 영향을 미치는지 판단해야 합니다. 고객이 제품을 어떻게 사용하는지 추적할 수 있다면 더 정확한 데이터를 얻을 수 있습니다.
위의 세 가지 요소가 공식을 구성합니다. 위의 각 요소에 다양한 값을 할당하고 몇 가지 계산을 수행합니다. 애플리케이션 및 시장 요소를 기반으로 가중치를 직접 추가, 곱셈 또는 추가할 수 있습니다. 예를 들어, 덧셈을 수행하고 각 버그에 10점의 숫자 범위를 할당하기만 하면 됩니다.
버그 #1: 예를 들어 프로그램을 충돌시키는 버그(10점)이고, 프로그램의 주요 부분에 존재하며(10점), 고객의 80%(8점)에게 영향을 미치므로 이 버그는 "사용자 고통" "볼륨이 28포인트인데 우리가 고칠 거라고 확신해요.
버그 #2: 단지 배열 버그일 뿐이고(2점), 보조 창에 나타나며(2점), 버그가 있는 프로그램 부분은 이전 버전에서만 사용됩니다(2점). 따라서 이 버그의 "사용자 고통" 값은 6점이며 아마도 수정되지 않을 것입니다.
불행하게도 많은 상황은 위와 같이 간단하지 않습니다. 버그 #3은 애플리케이션의 주요 부분에 존재하지만 특정 상황(5점)에서만 실패하는 데이터 손실 문제(10점)입니다(단, 데이터는 주관적입니다). 고객 조사에 따르면 거의 사용되지 않는 것으로 나타났습니다(2점). 따라서 "사용자 고통" 값은 17포인트이며 수정이 가능한지 여부가 모호한 데이터입니다. 한편으로는 이를 수정하는 데 필요한 투자가 그만한 가치가 없을 수도 있지만 문제를 이해하고 사각지대가 없는 한 버그를 무시하는 것이 아마도 올바른 접근 방식일 것입니다.
반면에 시스템의 다른 버그와 비교하여 평가해야 합니다. 여기서는 "Broken Window" 효과를 적용합니다. 애플리케이션에 중간 임계값 버그가 너무 많으면 제품 품질(또는 적어도 품질에 대한 인식)이 크게 영향을 받습니다. 시스템의 각 버그를 고려할 때 시스템의 다른 (알려진) 버그도 고려해야 하며 이를 사용하여 수정해야 할 버그와 수정할 가치가 없는 버그를 분석하고 결정해야 합니다.
공식적으로 출시된 소프트웨어에 버그가 있다는 것은 참으로 나쁜 일입니다. 하지만 기존 개발 도구와 개발 언어를 기반으로 우리는 아직 더 합리적인 해결책을 찾지 못했습니다.
다시 채우다:
이 글을 쓰면서 공식에서 네 번째 요소인 출시 날짜가 누락된 것 같습니다. 이 요소는 출시 날짜가 다가옴에 따라 버그 수정 여부를 결정하는 데에도 중요한 역할을 합니다. 그러나 이것이 네 번째 요소인지, 릴리스에 가까워지면 버그를 수정하는 데 필요한 "사용자 고통"의 양에 대한 임계값이 무엇인지 잘 모르겠습니다.