가장 최근의 테스트 평가 요약 점검
목적:
|
테스트 팀이 식별한 제품 품질 문제에 대한 현재의 요약 평가 이해
|
우선 테스트 팀이 준비한 테스트 평가 요약을 점검하십시오. 평가 정보를 반복을 위한 테스트 계획과 비교하여 계획된 작업 맥락에서 요약을 이해하십시오. 요약을 준비한 테스트 팀 구성원과 함께 모호성과 관심사항을
다루고 이를 해결하십시오.
이 단계와 정보를 수집하고 소프트웨어 품질을 평가하는 후속 단계의 경우, 객관적 척도와 주관적 척도를 둘 다 통합하는 균형 잡힌 시각을 확보하십시오. 객관적 숫자는 그림의 일부만 제공하므로 현재의 프로젝트
"환경"에 맞는 내용으로 설명되고 뒷받침되어야 합니다. 반대로, 소프트웨어 품질에 대한 평판과 주관적 추측에 전적으로 의존하지 말고 이를 뒷받침하는 객관적 증거를 찾도록 하십시오. 팀의 리더 또는 가능한 경우 개별
팀 구성원과의 논의를 통해 주관적 평가를 수집하고 객관적 데이터에 어느 정도의 신뢰를 불어 넣을 수 있는지 가늠하여 객관적 데이터를 보충하는 것이 좋습니다.
|
추가 컨텍스트에 대해 선택한 테스트 결과 점검
목적:
|
제품 품질에 대한 현재의 요약 평가를 지원하는 테스트 결과를 보다 심층적으로 이해
|
테스트 평가 요약을 기반으로 추가 컨텍스트에 대해 선택한 테스트 결과를 점검하십시오. 테스트 평가 요약에서 식별된 중요한 문제를 이해한다는 확신이 들도록 결과를 연구하십시오.
또한 직접 데이터를 검토하고 테스트 결과 데이터에서 누락되었을 수도 있는 중요한 상태동향을 명확히 찾으십시오. 일반적으로, 절대 숫자를 보는 것보다 데이터의 상대 상태동향이 무엇을 표시하고 있는지 식별해야 합니다.
한 영역에서의 장애가 다른 영역에서의 장애와 관련되는 등의 표시를 주시하십시오.
|
주요 변경 요청 점검
목적:
|
가장 중요한 두드러진 문제와 가능한 솔루션을 효과적으로 논의할 수 있도록 배경 조성
|
이 연습을 가장 시급한 문제 및 연관된 변경 요청으로 제한하는 것이 좋습니다. 보다 적은 수의 문제에 보다 많은 에너지를 쏟을 수 있게 되며, 이런 문제가 제품 품질에 가장 큰 영향을 미치는 경우가 많습니다. 주요
문제가 많을 경우, 상대적 우선순위를 기반으로 적절한 노력을 기울이는 것이 좋습니다. 아주 사소한 문제에 집착하여 자원을 낭비하지 마십시오. 그러나 우선순위가 현저히 낮은 상당수의 변경 요청이 우선순위가 높은
소수의 변경만큼 제품 품질에 매우 중요할 수 있습니다. 품질 위험성을 기반으로 우선순위가 낮은 변경 요청을 품질의 논리적 측면으로 그룹화하십시오. 이렇게 하면 품질에 미치는 결합된 영향력을 명확히 표현하고 지지할
수 있습니다.
일반 변경 요청 데이터에서 중요한 상태동향을 분명히 식별하십시오. 일반적으로, 절대 숫자를 보는 것보다 데이터의 상대 상태동향이 무엇을 표시하고 있는지 식별해야 합니다. 긍정적인 신호(예: 안정적이면서 지속적인
결함 해결율, 또는 시간의 경과에 따라 해결율이 점진적으로 증가했다가 차후에 감소)를 찾으십시오. 개발 팀의 생산성을 감소시키는 프로세스, 환경적, 정치적 또는 기타 문제점을 표시하는 해결율의 정점과 저점을
주시하십시오.
참고: 연관된 변경 요청의 명료성을 개선하여 모호성과 정서적 언어 및 추론을 없애려고 할 수도 있습니다. 이런 변경을 직접 수행할 경우, 원래 이 중간 산출물를 작성한 개인과 개선사항을 논의하여 개선이 중요한
이유를 이해할 수 있도록 하십시오.
|
품질 차이 식별 및 연관된 영향과 위험성 평가
목적:
|
제품 품질에 대한 위험과 소프트웨어 개발 프로젝트 성공에 제기된 위험에 관하여 주요 문제에 대한 이해를 공식화
|
품질의 각 차이를 식별하고 차이를 만들어 내는 각 문제의 연관된 영향과 위험성을 평가하십시오. 완화 및 비상사태 전략을 고려하고, 이에 대한 초기 개념을 공식화한 후 다른 팀 구성원과 이를 논의하십시오.
"완벽한" 품질은 어떤 면에서는 실현 불가능한 개념입니다. 품질을 평가하고 품질 차이를 식별할 때 현실적이면서 달성 가능한 "품질 기준(quality bar)"을 사용하도록 유의하십시오. 기법: 제품 품질을 참조하십시오.
|
품질 차이를 해결하기 위한 본질적인 조치 식별
목적:
|
주요 문제를 만족스럽게 해결하는 데 필요한 조치의 현실적인 최소 목록 생성
|
각각의 주요 품질 차이에 대해 잠재적 완화 및 비상사태 전략을 고려하십시오. 이에 대한 초기 개념을 공식화한 후 다른 팀 구성원과 이를 비공식적으로 논의하여 통찰력을 높이고 생각에 대한 유효성을 검증하십시오.
솔루션의 경우, 옵션을 갖는 것이 좋습니다. 옵션은 절충을 비교하여 생각하고 주어진 맥락에서 최상의 솔루션을 받아들이도록 돕습니다.
프로젝트 팀이 각 품질 차이를 적절히 해결할 수 있도록 돕는 일련의 유용한 후보 솔루션 및 제안을 지향하여 작업하십시오. 이를 수행하여 테스트 노력이 단지 문제점을 보고하는 것이 아니라 문제점 해결에 기여하도록
해야 합니다. 이는 테스트 팀의 가치를 옹호하고 다른 팀 구성원으로부터 존경과 협조를 받는 중요한 측면입니다.
|
주요 문제 해결을 위해 챔피언 식별 및 참여
목적:
|
주요 문제 해결을 위한 지원을 비공식적으로 수집하고 허용 가능성이 높은 제안에 대한 이해 얻기
|
성공 가망성이 없는 일을 수행하는 것은 재미없는 일입니다. 프로젝트 팀이 달성을 위해 후원, 허용 및 집중할 가능성이 높은 문제점에 대한 솔루션을 식별하는 것이 일반적으로 보다 효과적인 접근 방식입니다. 주요 의사
결정자와 긴밀한 관계를 유지하고 일 대 일 논의를 통해 이런 주요 문제를 비공식적으로 드러내십시오. 지원을 확보하고 도달 가능한 솔루션을 찾는 것이 아주 좋은 방법입니다.
개발 팀에 인기가 없는 솔루션을 지원할 수 밖에 없는 경우가 있습니다. 이런 경우, 지원을 기대할 수 있는 사람을 알고 가능한 확실히 가치를 제공하는 솔루션을 판매하거나 문제점을 해결하지 못해 발생하는 잘못된
상황을 설명하는 방법을 찾는 것이 훨씬 중요합니다.
|
작업 우선순위 협상
목적:
|
필수 품질에 악영향을 미치지 않는 허용 가능한 시간 프레임에서 해당 솔루션이 작동할 수 있도록 중재
|
개발 팀에게 양보하면서도 제품 품질을 크게 저하시키지 않는 적합한 솔루션을 협상할 수 있게 하는 것이 품질 중재의 요점입니다. 대부분의 경우 테스트 팀은 주로 품질에 대한 조언자이므로 해결책을 받아들이도록 요구하지
않아야 합니다.
그러나 테스트 팀은 품질 중재자로서 직무를 훌륭하게 수행하며 때로는 프로젝트 팀이 듣기 싫어하는 내용을 전해야 합니다. 이는 우수한 테스트 팀이 문제점, 잠재적 솔루션에 대한 탁월한 통찰력, 가능한 각 선택의
절충에 대한 이해를 통해 개발 노력을 제공하는 경우입니다. 제품의 최후 고객에 대한 에이전트로서 어느 정도 역할을 수행하고 최상의 이익을 제공할 솔루션 협상을 도와야 합니다.
|
작업 진행상태 모니터
목적:
|
문제 해결 시 진행상태를 알고 이를 지원하고 관여
|
기본 제품 개발 및 기능 확장을 진행하면서 결함 및 기타 변경 요청이 유실되는 경우가 있습니다. 이는 부분적으로는 개발자가 버그가 있는 이전 코드를 수정하는 것보다 "신제품(new stuff)" 개발을 하는 것이
보다 매력적이기 때문이며, 부분적으로는 손상된 사항을 수정하는 것보다 새로운 것을 추가하는 것에 비즈니스 가치를 보다 명백히 부여할 수 있기 때문입니다. 품질 중재자로서 테스트 팀은 프로젝트가 완료될 때까지 중요한
결함 수정사항을 파악할 수 있도록 도와야 합니다.
성공적인 소프트웨어 팀은 결함 해결을 통한 점진적 품질 개선과 기능 확장 간에 최상의 밸런스를 찾습니다. 테스트 팀은 별로 도움이 되지 않고 보다 대립적인 "품질 관리단(quality police)"의 역할을
가지기 보다는 점진적 품질 개선을 고무하고 지원할 수 있는 방법을 찾아 프로젝트 팀을 지원할 수 있습니다.
|
주요 문제에 대한 해당 해결책 확인
목적:
|
주요 문제에 대한 해결책이 중대한 부작용을 초래하지 않고 효과적으로 문제를 해결하는지 확인
|
개발 팀이 품질 문제를 해결하기 위해 어떤 해결책을 결정하건 해결책은 궁극적으로 품질을 개선해야 합니다. 주어진 해결책으로 인해 발생한 품질 개선을 평가할 시간을 가져야 하며, 해결책은 원래 문제를 해결할 뿐만
아니라 다른 방법으로 품질에 악영향을 미치지 않아야 합니다.
자체적으로 일부 위험성 레벨을 지닌 솔루션의 경우, 해결책을 따라 결론에 이르기까지 너무 많은 시간과 노력을 들이기 전에 초기 릴리스 후보에 대한 몇 가지 테스트를 수행하는 것이 유용할 수 있습니다.
|
결과 평가 및 확인
목적:
|
타스크가 적절히 완료되었는지 및 그에 따른 중간 산출물이 허용 가능한지 확인
|
작업을 완료했으므로 작업이 충분한 가치가 있었는지, 방대한 양의 종이만 소비한 것이 아닌지 확인하는 것이 좋습니다. 작업 품질이 적합한지 여부 및 차후에 이를 작업의 입력으로 사용할 해당 팀 구성원에게 유용할
정도로 완전한지를 평가해야 합니다. 가능하면 RUP에 제공된 체크리스트를 사용하여 품질 및 완성도가 "충분"한지 확인하십시오.
다운스트림 타스크 수행 시 해당 작업을 입력으로 사용할 인원들이 중간 작업 검토에 참여하도록 하십시오. 이들의 관심사항을 다루는 조치를 취할 시간 여유가 있으면 이를 수행하십시오. 또한 작업을 주요 입력 중간
산출물과 비교 평가하여 이를 정확하고 충분하게 표시했는지 확인해야 합니다. 입력 중간 산출물 작성자가 이를 기반으로 작업을 검토하도록 하는 것이 유용할 수 있습니다.
RUP는 반복적 전달 프로세스이며 중간 산출물은 시간이 경과하면서 발전하는 경우가 많다는 사실을 기억하십시오. 그러므로 부분적으로만 사용되거나 직후 작업에서 전혀 사용되지 않을 중간 산출물을 완전히 형식화하는 것은
거의 불필요합니다(또한 보통 비생산적임). 이는 중간 산출물이 사용되기 전에 중간 산출물을 둘러싼 상황이 변경되고 중간 산출물이 작성되었을 때의 가정이 잘못되었다고 증명되어 결과적으로 노력이 수포가 되고 비용을
들여 다시 작업해야 하는 가능성이 높기 때문입니다. 또한 프리젠테이션 주기가 너무 많아 컨텐츠 가치가 손상되는 함정에 빠지지 않도록 하십시오. 프리젠테이션이 프로젝트 인도물로서 중요성과 경제적 가치를 지니는
프로젝트 환경에서는 관리 자원을 사용하여 프리젠테이션 타스크를 수행할 수 있습니다.
|
|