brunch

You can make anything
by writing

C.S.Lewis

by Ruth Hyojin Nam Feb 20. 2024

제품의 품질에 영향을 미치는 요소 관리

Software Test Recipe

QA는 제품 설계 단계부터 출시 이후까지 제품에 영향을 미치는 모든 요소를 발견하고 제어하며 차단하고 예방하는 활동을 수행합니다. 여기서 ‘제품의 품질에 영향을 미치는 요소’는 과연 무엇일까요? 

위 질문에 “‘소프트웨어에 존재하는 기능적 결함’으로 소프트웨어가 제대로 작동하지 않는 것” 라고 답해봅시다. 이 답은 맞기도 하고 틀리기도 합니다. 


                                  품질에 영향을 미치는 요소 = 위험요소 = 리스크Risk


소프트웨어 기능상 결함 범위를 벗어난 상황을 예시로 설명해보겠습니다. 


완성도가 높은 기획 명세와 개발 설계서가 준비되었고 테스터A에게 테스트 케이스 설계를 요청했습니다. [테스터A의 특징은 어떤 소프트웨어를 테스트하든 오탈자와 디자인UI의 깨짐을 가장 중요시하고 우선순위에 두고 테스트를 수행합니다.] 테스터A는 테스트 케이스의 70% 이상을 UI확인에 중점을 두고 테스트를 설계하였습니다. 이후 테스트 케이스 설계 범위와 계획을 프로젝트 구성원에 공유하지 않았고 테스트 조직이나 리더도 테스트 케이스 리뷰 활동을 누락하게됩니다. 그리고 테스트A는 준비된 테스트 케이스로 테스트를 수행합니다. 테스터A가 작성한 테스트 케이스의 성공률이 100%에 도달하였고 테스트 리더는 성공률만 확인하고 오픈이 가능한 상태로 의견을 전달합니다. 고객에게 제품이 출시된 이후 ‘품질을 검증하지 못한 영역에서’ 너무 많은 결함의 발생으로 제품에 대한 신뢰도는 끝없이 하락하였고 고객은 제품 사용을 포기하기에 이릅니다. 고객들은 제품을 떠나는 것에 그치지 않고 제품을 만든 회사에 대한 신뢰까지 버렸습니다. 소프트웨어의 실패로 회사의 명성도 위험에 이르게됩니다. 


위 예시 상황에서 위험 요소를 찾아보면,  

    테스트 인력의 역량과 경험 부족, 좁은 시야로 체계적인 테스팅을 준비하지 못함  

    개발자에 의해 개발 범위 내에서 테스팅이 수행되지 않음  

    테스트 케이스 리뷰 누락 및 테스트 계획(품질 수준, 품질 특성, 전략 등)에 대한 공유 누락  

    리스크와 우선 순위 분석을 통한 테스트 범위 설정을 하지 않음  

    테스트 설계 기법을 적용한 테스트 케이스 설계가 이뤄지지 않음  

    테스트 완료 조건 평가와 품질 목표 기준 설정이 없음  

    테스트 제어 활동 누락  

대략만 살펴보아도 소프트웨어 기능상 결함 범위를 벗어난 위험요소 7가지가 확인됩니다. 


이처럼 제품에 영향을 미치는 위험 요소는 기능적 결함으로만 존재하지 않습니다. 투입 인력, 일정, 프로세스, 리스크 관리, 제어 활동 등 제품의 결과물이 나오기까지 영향을 미치는 모든 요소들이 위험 요소가 될 수 있습니다. 


위험요소Risk List  

    작동되지 않는 소프트웨어   

    발생 빈도가 높고 영향력이 높은 오류를 품고있는 소프트웨어  

    부족한 인력   

    타이트한 일정  

    비용 증가 요소  

    고객 요구사항의 잦은 변경  

    테스팅 중요성의 인식 부족으로 테스트 조직 또는 테스트 활동 부재   

    개발 프로세스 내 테스팅 절차 누락  

    리스크 관리와 우선 순위 결정 누락  

     투입 인력의 전문성/역량/기술/경험 부족   

     직무별 단위 프로세스 및 협업 프로세스 부재   

     개발/QA 작업에 대한 제어 및 감사 활동을 진행할 컨트롤타워 부재  


테스터 또는 테스트 리더는 발생될 수 있는 모든 위험요소(리스크)를 이해하고 식별할 수 있어야 하며 리스크를 완화하고 컨트롤 할 수 있는 전략과 기술을 이용해 위험에 대비할 수 있는 방책을 마련함으로써 제품의 품질에 영향을 미치는 모든 요소를 제어하고 차단하고 예방하는 활동을 수행해야 합니다. 


리스크 관리

제품의 목표 달성을 위해 리스크 요인을 식별하고 이를 처리하여 잠재적으로 발생할 수 있는 결과를 파악하여 대책을 마련해야 합니다. 프로젝트 또는 조직이 새로운 리스크를 식별하고 해결한 과정을 문서화하여 프로세스내에 리스크를 관리하는 계획을 포함합니다. 

리스크를 예방하기 위해 때로는 위험 요소를 차단하는 절차나 규정을 만들어 강제화 하기도 합니다. 또는 리스크 관리 프레임워크를 활용하여 체계적인 리스크 관리를 수행합니다. 소프트웨어에 위험 요소가 되는 목록을 만들어 발생시 미치게 될 영향력에 따라 우선순위를 설정하고 프로젝트의 작업 단계별로 위험 요소가 발생할 수 있는 경로를 확인하여 확인되는 문제를 해결하고 재발을 방지하기 위한 보안 강화 등의 대책을 마련하도록 합니다. 

                    


테스터는 리스크 요인으로 발생된 이슈 사례와 위험 요소 리스트를 활용하여 별도의 리스크 검증을 위한 체크리스트를 생성하고 프로젝트 구성원에 공유합니다. 기능 테스트나 자동화를 적용하여 확인할 수 있는 위험 요소는 테스트 프로세스 안에 테스트 수행 절차를 도입하여 품질을 확보할 수 있도록 합니다. 테스팅 범위를 벗어난 개발 설계, 시스템 구조와 관련된 요소는 협업 프로세스 안에 절차를 마련하여 담당 작업자가 체크리스트를 확인하고 결과를 공유할 수 있도록 프로세스화 합니다. 테스트 중 새롭게 발견된 리스크는 체크리스트로 기록하고 지속적으로 관리될 수 있도록 규칙을 적용합니다. 


[리스크 검증을 위한 체크리스트 예시]


작가의 이전글 소프트웨어 품질 관리자(QA) 채용시 면접 질문 프레임
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari