위험 기반 검정에 대해 좀 알아볼까요? 우선 이 주제는 매우 민감한 주제라는 사실부터 말씀 드립니다. 품질은 마음 약한 사람들이 종사할 만한 분야가 아닙니다. 모든 산업에서 비용, 품질과 배송은 끊임없는 줄다리기의 관계에 있습니다. 소프트웨어 업계도 예외는 아닙니다. 품질 전문가는 이러한 3가지 요소의 균형을 찾는 과정에서 핵심적인 역할을 합니다. 그리고 이러한 균형이 '깨지면' 품질 전문가의 탓이 되거나, 적어도 품질 전문가 스스로가 그렇게 느끼곤 합니다.
저 또한 오랫동안 스스로에게 미안했습니다. 왜 다들 내 일이 얼마나 힘든지 알아주지 않는 거냐면서 말이죠. 매일 비용 및/또는 배송의 이름으로 품질을 희생시키려는 이들에게 맞서 싸우고 진리와 정의를 지키는 이런 나를...네, 사실 악당 같은 건 없고 저도 수퍼히어로가 아니며, 상황이 이렇게 극적이지도 않습니다. 다만 품질과 납품 사이의 완벽한 균형을 지키기란 쉽지 않은 것이 사실입니다.
그러나 최근 몇 년 사이에 검정에 투자하는 시간과 납품되는 제품의 품질 사이에는 상관관계가 없다는 사실이 드러났습니다. 다행일까요? 그렇지 않습니다. 이는 품질 보증이 쉬워졌다는 의미가 아니라, 같은 과정을 단순히 반복해서는 문제가 해결되지 않는다는 뜻입니다. 실제로는 문제가 훨씬 더 복잡한 셈이죠.
저는 품질 보증에서 중요한 것은 얼마나 많이 테스트하느냐가 아니라 테스트 하는 방법이라는 사실을 배웠습니다. 사실 많은 경우 검정 자체가 중요한 것도 아닙니다(이에 관한 내용은 다음 글에서 다루겠습니다).
Minitab에서는 비용, 품질 및 배송 사이에서 어떻게 균형을 찾을까요? 매우 섬세하게 찾습니다. 항상 성공한다고 하면 거짓말이겠죠. 품질 전문가의 가장 중요한 자질은 엄격한 정직함입니다. 다시 말하지만 품질 개선 전문가는 마음 약한 사람들이 종사할 만한 분야가 아닙니다. 하지만 Minitab이 품질을 매우 중요하게 생각하는 것은 사실이며, Minitab의 모든 직원은 지속적인 품질 개선에 기여합니다.
이 주제는 여러 개의 글에 걸쳐 다루어야 할 정도로 광범위하지만, 우선 위험 기반 검정(RBT)부터 알아보겠습니다. 기능이나 릴리스에는 거의 무한한 수의 검정 사례가 있으므로, 가능한 모든 검정을 실시하는 것은 비용과 시간 측면에서 불가능합니다. 품질 전문가의 역할은 어느 검정을 수행할지, 어느 빈도로 그리고 어떤 방식으로 검정을 수행할지 정하는 것입니다. 과거 제조회사에 재직하던 당시 샘플링 계획을 검사에 활용했던 경우를 이에 비유할 수 있는데요. 당시 모든 제품을 검사할 수는 없었지만, 검사할 제품을 스마트하게 정할 수 있었습니다.
Minitab에서는 RBT를 사용하여 고장 위험에 기반한 검정 전략을 수립합니다. 고장 위험은 발생 및 심각도 확률에 대한 함수입니다. 이 과정에서 Minitab Engage의 고장 모드 및 영향 분석(FMEA)을 활용합니다.
저는 90년대 초반에 의료기기 업계에서 일할 때 처음으로 FMEA를 사용했습니다. FMEA는 당시에도 효과적이었지만, 거의 20년이 지난 오늘날에도 제가 가장 선호하는 도구 중 하나입니다. 물론 Minitab Engage 덕분에 20년 전보다 관리가 훨씬 쉬워지기도 했지만요. 아래 그림과 같이 FMEA는 심각도, 발생 빈도와 감지 용이성에 기반하여 고장의 우선 순위를 지정하는 데 사용됩니다. 이러한 평가에 기반하여 위험 완화를 위한 명확한 전략을 식별하고 시행할 수 있습니다.
Minitab에서 수행한 FMEA를 간략히 살펴보겠습니다.
|
Step# |
Process Map - Activity |
Potential Failure Mode |
Potential Failure Effects |
SEV |
OCC |
Current Controls |
DET |
RPN |
|
10 |
Dialog Testing |
Access key validation isn’t automated for each dialog |
The hot keys are initially validated within development. If a developer makes a change that breaks a hot key assignment, it may not be immediately detected. |
3 |
2 |
Initial manual testing and follow up manual regression testing of changes for each dialog. General automated testing of access keys. |
5 |
30 |
|
Actions Recommended |
Responsibility |
Target End Date |
Actions Taken |
Actual End Date |
|
An evaluation will be done to determine if some automated testing can be performed |
JRoan (Test Architect) |
3/1/2011 |
Automated monitoring of dialog file to detect changes in assignments. |
2/15/2011 |
|
Revised metrics |
|||
|
SEV |
OCC |
DET |
RPN |
|
3 |
2 |
1 |
6 |
1) 프로세스 맵 - 활동에 각 공정 단계, 기능 또는 활동 유형을 입력합니다. 위의 예에서는 기능 수준의 대화상자 테스트입니다.
2) 잠재적 실패 모드에 각 활동에서 발생할 수 있는 프로세스 실패를 추가합니다. 여러 가지 고장 모드가 존재할 수 있습니다. 위 예에서는 각 대화상자의 모든 액세스 키 기능을 확인하기 위한 검정 스크립트가 실행되지 않았습니다.
3) 잠재적 고장의 영향에 각 고장 모드에 대해 가능한 고장의 영향을 입력합니다. 모든 고장 모드에는 여러 가지 고장의 영향이 있을 수 있습니다. 위 예에서 가능한 고장은 개발자가 (대화상자 확인 후) 수행한 변경 사항이 액세스 키를 무효화하면 고장이 감지되지 않을 수 있다는 것입니다.
4) SEV(Severity Rating, 심각도 점수)에서 각 고장 영향의 심각도를 추정합니다. 1~10의 점수를 부여합니다. 10은 높은 심각도를, 1은 낮은 심각도를 나타냅니다. 이러한 점수는 상대적으로 할당해야 합니다. 현실에서 액세스 키는 예컨대 통계 결과나 그래픽 결과보다는 심각도가 낮을 것입니다. 따라서 액세스 키에는 3의 심각도 점수를 부여했습니다.
5) OCC(Occurrence Rating, 발생 점수)에서 원인의 발생 확률을 추정합니다. 1~10의 점수를 부여합니다. 10은 높은 빈도(지속적 문제 발생이 확실시됨)를, 1은 낮은 빈도(발생할 가능성이 거의 없음)를 나타냅니다. 이 예에서는 최초 할당 후 액세스 키를 변경할 확률이 낮지만 불가능하지는 않습니다. 따라서 발생 점수를 2로 정했습니다.
6) 현재 관리에서 고장 원인/모드가 감지되거나 제어되는 방식을 입력합니다. 대화상자 검정에서는 수동으로 각 액세스 키를 확인하고, 액세스 키의 일반 확인을 자동화하고 빠른 검정을 실시합니다.
7) DET(Detection Raiting, 감지 점수)에서 각 제어장치가 고장 원인/모드를 감지하거나 제어할 수 있는 역량을 평가합니다. 1~10의 점수를 부여합니다. 10은 감지/제어력 낮음(고객이 잘못된 결과를 받을 가능성이 거의 확실)을, 1은 감지/제어력 높음(거의 확실한 감지. 보통 고장 모드가 생성되기 전에 원인을 찾음)을 나타냅니다. 이 예에서는 문제 감지 확률이 높지 않으나, 수동으로 실시하는 검정을 통해 발견할 수는 있습니다. 따라서 감지 점수를 5로 정했습니다.
8) RPN 평가하기: RPN(Rist Priority Number, 위험 우선 순위 번호)은 SEV, OCC와 DET 점수를 활용하여 산정합니다. RPN은 모드/효과/원인을 조합하여 도출한 종합 점수입니다. RPN이 높을수록 가능한 문제가 더 심각하고 자주 발생하며 통제가 되지 않아 즉각적인 조치가 필요합니다. 이 예에서는 RPN이 30이며, 자동화를 수행할 수 있는지 평가하고 파악하기로 했습니다. 그 결과, Minitab의 검정 설계자가 감지 확률을 높일 수 있는 대체 솔루션을 파악했습니다.
9) 수정 조치를 취한 후에는 새로운 SEV, OCC 및 DET 값을 입력하여 수정된 RPN을 계산합니다. 이 예에서는 RPN이 허용 가능한 수준인 6으로 감소했습니다.
Minitab Engage의 FMEA 분석 도구는 위험 기반 평가와 이를 통한 검정 전략을 매우 효과적으로 분석하고 관리하며 전달할 수 있는 방법을 제공합니다. 위의 예에서는 파일의 변경 사항에 관한 QA를 알리기 위해 자동화된 시스템을 구축했습니다. 이는 현행 문제의 위험을 비용 효과적으로 완화하기 위한 전략입니다. FMEA는 팀이 분석 내용을 파악하고 이러한 결정의 이유를 문서화하기 위한 구조를 제공했습니다.
또한 FMEA는 이와 같은 유형의 의사결정에 대한 기록으로서 유지 관리되고 제공됩니다. 이를 통해 품질 전문가는 과거의 의사결정에 대해 이러쿵저러쿵 말이 나오는 것을 방지할 수 있죠. 제가 FMEA에 입문했던 20년 전에 Minitab Engage가 있었다면 얼마나 좋았을까요!