테스팅 원리[4] - “결함 집중”이라는 말은 적은 수의 모듈에서 대다수의 결함이 발견된다고 나와 있는데요, 그럼 해당 부분만 집중적으로 고치면 해결되는 건가요?

질문

ISTQB 버전

ISTQB Syllabus 2018

답변

테스팅 원리[4] - 결함 집중(Defect clustering)

소프트웨어 버그는 전체 제품의 모든 기능에 거쳐 널리 공평하게 n개씩 존재하지 않습니다. 소프트웨어 버그는 일반적으로 특정 모듈 혹은 특정 모듈과 연관된 기능들에서 집중되는 경향이 있습니다. 이를 결함 집중(Defect Clustering)이라 부릅니다.

Cluster는 사전에서 찾아보면 아래의 의미를 가지고 있습니다. 즉, 어떤 특징적인 성질을 공통적으로 가진 무언가의 모임/무리를 의미하는 단어입니다. 그러므로 Defect Cluster라는 의미는 그 두 단어의 뜻 그대로 어떤 결함들(Defects)들이 무리지어 있다(Clustering)라는 의미입니다.

사실 '결함 집중'은 소프트웨어에서 출발한 개념은 아니고, 원래는 제조업에서 증명된 개념입니다. 그리고 이를 소프트웨어에 대입해도 동일한 결과가 나타나서 소프트웨어 공학에서도 사용하는 개념입니다.

결함 집중에 대해 과학적으로 증명되고, 일반적으로 받아들여지는 공학적 관점의 내용들은 아래와 같습니다.

결함 집중은 80-20 규칙인 Pareto 원칙을 기반으로 하며, 문제의 약 80%가 모듈의 20%로 인해 발생한다고 말 할 수 있습니다.
1:29:300의 하인리히 법칙에 따라 아주 작은 결함이라도 연관된 결함이 없는지 분석이 필요하며, 필요 시 추가적인 테스팅을 통해 결함이 없는지 확인이 필요합니다.
테스트하는 동안 대부분의 테스터는 코드 영역이 복잡하고, 까다롭기 때문에 기본적으로 발생하는 결함 집중 현상을 관찰했으며 테스트 설계자는 테스트 계획을 위한 위험 평가를 할 때 규칙에 대한 정보를 사용하며 핫스팟이라고 하는 알려진 영역에 초점을 맞추게 됩니다.

※ 참고
• Defect Density는 특정 운영 또는 개발 기간 동안 소프트웨어/모듈에서 확인 된 결함 수를 소프트웨어/모듈의 크기로 나눈 값을 의미합니다.

• Defect Density 계산 법 : Defect Density = Defect count/size of the release

결함 집중되는 곳 찾기

많은 테스터가 결함이 발생하기 쉬운 영역을 직관적으로 알고 있지만 여러 가지 방법으로 결함이 집중되는 곳을 찾기 위해 노력할 수 있습니다.

결함 밀도 지표
- 결함 밀도 차트 또는 모듈별 결함 수와 같은 메트릭을 사용하여 발견된 결함 기록을 검사하고, 결함 밀도가 더 높은 영역, 모듈 또는 기능을 찾을 수 있습니다. 여기서 결함 집중 검색을 시작해야 합니다.
- 이러한 영역을 테스트하는데 더 많은 시간을 할애하면 더 많은 경험이나 시도해 볼 수 있는 더 복잡한 사용 사례로 이어질 수 있습니다.

예를 들어, 아래 차트는 모듈 4에 가장 많은 결함이 있음을 보여주므로 앞으로도 해당 모듈에 계속 집중하는 것이 좋습니다.

코드 줄당 결함 수를 추적하거나 차트 또는 그래프에 결함 밀도 측정 값을 고정할 수도 있습니다.

결함 집중을 줄이는 방법

해당 영역을 테스트하는 더 나은 방법을 고안하십시오.

대부분의 결함이 포함된 기능 또는 모듈을 알면 테스터는 더 나은 테스트 방법을 찾는 데 더 큰 노력을 기울일 수 있습니다. 여기에는 해당 모듈에 대한 더 많은 단위 테스트 및 통합 테스트가 포함될 수 있습니다. 테스터는 또한 기능이 프로덕션에서 가장 잘 사용되는 방법에 대한 고객의 사용 사례를 사용하여보다 심층적인 테스트 시나리오를 작성할 수 있습니다.
테스트 데이터에 집중하고, 변수에 대해 더욱 철저한 조합 테스트를 생성하면 더 많은 계산 또는 알고리즘 결함을 더 빨리 찾을 수 있습니다.

해당 영역을 테스트하기 위해 테스트 계획에 더 많은 시간을 할애하십시오.

각 기능이 똑같이 중요하거나 복잡하거나 "더러운" 것은 아니기 때문에 일반적으로 모든 기능을 테스트하는 데 동일한 노력이나 시간이 필요하지 않습니다. 결함이 집중되는 곳을 찾아서 테스터는 결함이 발생하기 쉬운 모듈에 더 많은 테스트 노력과 시간을 할당할 계획을 세울 수 있습니다.
이러한 투명성은 작업을 추정하고 사용자 스토리 당 실제 소요된 시간을 보고 할 때 테스터의 작업을 더 쉽게 만듭니다. 결함이 밀집된 영역에서 작업하는 테스터는 한 사용자 스토리에서 작업하는 데 다른 테스터가 여러 개의 작은 모듈에서 작업하는 데 걸리는 시간의 두 배일 수 있습니다. 이 지식은 현실적인 기대를 하고 작업 분배를 공정하고 개방적으로 유지합니다.

위와 같은 경우 당신의 선택은?

결함이 집중되는 곳에 더 많은 관심을 가지십시오.

결함이 많은 모듈은 향후 결함을 방지하기 위해 더 높은 수준과 수의 검토를 거쳐야 합니다. 피어 리뷰 및 버디 테스트는 다양한 단계에서 수행할 수 있음으로 기능 설계, 구현 및 테스트에 대한 다양한 관점과 피드백을 얻을 수 있습니다.

아주 쉽게 설명하면, 문제가 몇 번 발생한 특정 영역이 있다면 이후에도 지속적으로 발생할 가능성이 있으므로, 테스터는 결함이 집중되는 곳을 지속적으로, 오랜 시간과 노력을 투입하여 테스트해야 한다는 의미입니다.

지속적인 모니터링 프로세스 구축

결함 집중이 되는 곳이 식별되고, 팀이 위의 전략을 실행하기 시작하면 결함 수가 줄어들 수 있으며 시간이 지남에 따라 특정 결함이 집중되는 곳은 더 위협이 되지 않을 수 있습니다. 그때까지 시스템은 새롭고 복잡한 영역이 될 수 있습니다.
결론적으로, 테스터는 결함이 집중되는 곳을 지속적으로 모니터링해야 합니다. 결함 집중되는 곳을 찾고 테스트하는 것은 애플리케이션과 함께 성장하는 지속적인 프로세스가 될 것입니다.

그 부분만 잘 수정하면 품질이 향상될까요?

답은 두 개가 될 것 같습니다. "아니오. 그렇지는 않습니다. "와 "예, 맞습니다." - 두 개 모두입니다.

왜냐하면 소프트웨어 시스템에서 발생한 오류는 필연적으로 설계상의 문제일 가능성이 크며, 이는 곧 오류가 복잡도(Complexity)와 의존성(Dependency)의 문제를 야기시킨다는 의미입니다. 즉, 작은 구멍이었던 문제점들이 어느 순간 큰 문제점으로 나타날 수 있다는 의미입니다.

이에 대해서는 초심자가 쉽게 이해할 수 있도록 간단히 설명할 방법이 없습니다. 나중에 기회가 되면 다시 필요한 만큼 이야기를 하려 합니다.

그래서 발달한 MSA 적용

2000년 이후 인터넷은 급속도로 발전하여 소프트웨어들이 네트워크에서 서비스 단위로 작동하기 시작하였습니다. 인터넷에서 실시간으로 서비스되는 소프트웨어들에서도 이 결함 밀도, 결함 집중도는 발생합니다. 네트워크 상에서는 복잡성, 의존성 등이 훨씬 더 증가하기 때문입니다. 그래서 이와 관련한 근본적인 문제점들을 소프트웨어 설계상에서 해체하거나 최소화하려 발생한 개념이 MSA(Micro Service Architecture)입니다.

MSA는 인터넷에 수 많은 자료들이 있으므로 자세한 사항은 인터넷 검색을 이용해주세요. 본 블로그에서는 기회가 될 때 테스팅 활동과 결합되는 구간을 다시 알려드리도록 하고, 이번 포스팅에서는 자세한 이야기는 생략하겠습니다.

참여자 정보

• 글쓴이 : 품생품사, 천년나무

• 검토한이 : 아이티마니, Bykj

블로그 내의 관련 글

소프트웨어 테스팅의 7가지 원리에 대해 설명해 줄 수 있나요? (Episode 2/2)

목차 질문 소프트웨어 테스팅의 7가지 원리에 대해서 설명해 줄 수 있나요? ISTQB 버전 ISTQB Syllabus 2018 답변 본 글은 「소프트웨어 테스팅의 7가지 원리」에 대해 설명하지만, 글이 너무 길어져 2개

softwaretestingreference.tistory.com

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다. 개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

본 글과 관련한 전문가 의견이 없습니다.

[팀블로그] 소프트웨어 테스팅 참고서