목적
  • 소프트웨어 품질에 악영향을 미치는 결함의 해결책을 식별하고 이를 제시합니다.
  • 소프트웨어 품질을 필요한 레벨까지 향상시키는 변경의 진행을 모니터하고 적절히 완성되도록 지원합니다.
  • 테스트 노력을 방해하거나 약화시키는 결함에 대한 시기적절한 해결책을 제시합니다.
역할:  테스트 관리자 
빈도:  일반적으로 이 활동은 한 번 반복될 때마다 여러 번 수행됩니다. 
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

가장 최근 테스트 평가 요약 조사 페이지 맨 위

목적:  테스트 팀이 식별한 제품 품질 문제에 대한 현재 평가 요약을 이해합니다.  

테스트 팀이 준비한 테스트 평가 요약 조사를 시작하십시오. 반복에 대한 테스트 계획과 평가 정보를 비교하여 계획된 작업의 컨텍스트에 있는 요약을 이해하십시오. 요약을 준비한 테스트 팀 구성원과 함께 모호한 사항이나 관심있는 사항을 찾아내 이를 해결하십시오.

정보 수집 및 소프트웨어 품질 평가를 처리하는 현재 및 후속 단계를 통해 객관적 및 주관적 방법을 모두 합친 균형있는 관점을 가져보십시오. 객관적인 수치만 그림의 일부로 수록되고 현재 프로젝트 "환경"에서 지원되고 설명되어야 하는 점을 기억하십시오. 반대로, 소프트웨어 품질에 대해 전해들은 말이나 주관적인 추측에 전적으로 의존하지 마십시오. 뒷받침하는 객관적인 증거를 찾으십시오. 주관적인 평가를 수집하고 객관적인 데이터를 어느 정도 신뢰할 수 있는지 측정하기 위해 테스트 지도부 또는 가능한 개별 팀 구성원과 논의하여 객관적인 데이터를 보완하는 것이 바람직합니다.

추가 컨텍스트용으로 선택한 테스트 결과 조사 페이지 맨 위

목적:  제품 품질에 대한 현재 평가 요약을 지원하는 테스트 결과를 더욱 깊이 있게 이해합니다.  

테스트 평가 요약에 기초하여 추가 컨텍스트에 대해 선택된 테스트 결과를 조사하십시오. 테스트 평가 요약에서 식별된 중요한 문제를 이해한다고 확신할 수 있을 만큼 충분히 결과를 조사하십시오.

또한 데이터를 스스로 검토하고 테스트 결과 데이터에서 누락될 수 있는 분명하게 나타나는 중요한 경향을 찾으십시오. 일반적으로, 절대 숫자를 찾기보다는 데이터의 상대적인 경향이 나타내는 것을 식별하는 것이 더 중요합니다. 한 영역에서의 실패가 다른 영역에서의 실패와 관련이 있는 것과 같은 표시에 주의하십시오.

주요 변경 요청 조사 페이지 맨 위

목적:  가장 중요한 미해결 문제와 가능한 솔루션에 대해 효과적으로 논의할 수 있도록 배경 지식을 얻습니다.  

이 실습을 가장 긴급한 문제 및 관련 변경 요청으로 제한하는 것이 바람직합니다. 좀 더 적은 문제에 더 많은 에너지를 집중할 수 있으며, 대개의 경우 이러한 문제가 제품 품질에 가장 많은 영향을 끼치게 됩니다. 주요 문제가 더 길게 나열될 수록, 상대적인 우선순위에 따라 이러한 문제점에 적절한 노력을 기울이는 것이 좋습니다. 중요하지 않은 문제를 부각시켜 자원을 낭비하지 마십시오. 그러나 하위 우선순위의 미해결 변경 요청이 상당 수 있으면 제품 품질에 대한 평가서를 소수의 상위 우선순위 변경과 같이 중요한 것으로 작성할 수 있습니다. 하위 우선순위 변경 요청을 나타나는 품질 위험에 기초한 논리적인 품질 양상으로 그룹화하십시오. 그러면 품질에 대해 결합된 효과를 더욱 명백하게 연관시키고 지지할 수 있습니다.

일반 변경 요청 데이터에서 분명하게 나타나는 중요한 경향을 식별하십시오. 일반적으로, 절대 숫자를 찾기보다는 데이터의 상대적인 경향이 표시하는 것을 식별하는 것이 더 중요합니다. 안정적이며 지속적인 결함 해결 비율과 같은 긍정적인 조짐이나 점진적으로 증가하고 시간이 흐른 후 감소하는 해결 비율을 찾아보십시오. 개발 팀에 생산성을 감소시키는 프로세스, 환경, 정치 또는 기타 문제점이 발생할 수 있음을 나타내는 최대 및 최저 해상 비율을 주의하십시오.

참고: 모호하고 감정적인 언어 및 추리를 제거하여 변경 요청을 더욱 명확하게 만드는 기회를 이용하려 할 수 있습니다. 사용자 스스로 변경하는 경우, 개선사항이 중요한 이유를 이해할 수 있도록 결과물을 처음 작성한 직원과 개선사항에 대한 검토를 하십시오.

품질 차이 식별 및 연관된 영향 및 위험 평가 페이지 맨 위

목적:  제품 품질에 나타나는 위험 및 소프트웨어 개발 프로젝트의 완료를 방해하는 관련 위험과 관련하여 주요 문제점에 대한 이해를 체계적으로 나타냅니다.  

모든 품질 차이를 식별하고 차이나게 만드는 각 문제점과 연관된 영향 및 위험을 평가하십시오. 완화 및 비상 전략을 고려하고 이에 대한 초기 계획을 체계화한 후 다른 팀 구성원과 검토하십시오.

"완벽한" 품질은 거의 가공의 개념으로 간주하십시오. 품질 평가 및 품질 차이 식별시 실제적이고 도달할 수 있는 "품질 막대"를 주의하여 사용하십시오. ../workflow/test/co_rqlty.htm -- This hyperlink in not present in this generated website개념: 제품 품질을 참조하십시오.

품질 차이를 처리하기 위한 기본 조치 식별 페이지 맨 위

목적:  주요 문제의 만족스러운 해결책을 협의하는 데 필요한 조치의 실제적인 최소 목록을 작성합니다.  

각 주요 품질 차이에 대해 가능한 완화 및 비상 전략을 고려하십시오. 이에 대한 초기 계획을 체계화하고 다른 팀 구성원과 비공식으로 논의하여 더 깊은 통찰력을 얻고 착상이 유효한지 확인하십시오. 솔루션의 경우, 절충안을 평가하여 주어진 컨텍스트에 가장 좋은 솔루션을 선택하는 데 도움을 주는 선택사항을 갖는 것이 바람직합니다.

각 품질 차이를 적절하게 처리하도록 프로젝트 팀을 돕는 유용한 후보 솔루션 및 제안 세트에 대해 작업하십시오. 이 작업을 수행하여 테스트 작업이 단지 문제점만 보고하기 보다는 문제점 해결에 유익하게 기여하는 것으로 인식되게 해야 합니다. 이는 테스트 팀의 가치를 지지하고 다른 팀 구성원의 존경과 협조를 얻을 수 있는 중요한 면입니다.

기본 발행에서 최우수품 식별 및 계약 페이지 맨 위

목적:  주요 문제점을 해결하기 위한 지원을 형식에 구애받지 않고 수집하며 채택 가능성이 있는 제안에 대한 이해를 얻습니다.  

승산없는 명분으로 돌아가는 것은 바람직하지 않습니다. 일반적으로 프로젝트 팀이 지지하고 승인하며 달성할 것을 커미트하는 것 같은 문제점에 대한 솔루션을 식별하는 것이 더 효과적인 방법입니다. 주요 결정자와 긴밀한 관계를 유지하고 1대 1 논의를 통해 이러한 주요 문제점을 비공식으로 드러내게 하면서 시작하는 방법을 고려하십시오. 대부분의 경우 지원을 얻어 달성할 수 있는 솔루션을 찾는 것이 가장 좋은 방법입니다.

때때로 선택사항이 없어서 개발 팀에게 평판이 좋지 못한 솔루션으로 다시 돌아가야 하기도 합니다. 이러한 경우에는 지원 양식을 기대할 수 있는 사람을 알고 그 가치를 가능한 명확히 나타내는 솔루션을 파는 방법을 찾거나 문제점을 해결하지 못할 때 발생하는 더 나쁜 상황을 확실히 설명해야 합니다.

작업 우선순위 협의 페이지 맨 위

목적:  필요한 품질에 불리하게 영향을 주지 않는 적절한 솔루션이 사용 가능한 시간 프레임에서 활동하도록 지지합니다.  

바로 이 점이 품질 지지의 요점으로, 개발 팀을 충족시키고 제품 품질을 크게 저하시키지 않는 적절한 솔루션을 협의할 수 있습니다. 대부분의 경우 주로 테스트 팀이 품질 조언자이므로 제공된 해결책을 수행하도록 요구하지 않도록 주의해야 합니다.

그러나 테스트 팀이 품질 조언자로서의 임무를 잘 수행하며 종종 프로젝트 팀이 실제로 조언에 귀 기울이지 않을 것이라는 뉴스 전달자가 되기도 해야 합니다. 이러한 이유로 훌륭한 테스트 팀은 문제점에 대한 깊은 통찰력으로 개발에 노력을 기울이며 가능한 솔루션 및 가능한 경우 각각의 선택에 대한 절충과 같은 합의를 제공합니다. 사용자는 제품의 최종 고객을 위한 에이전트로서 어느 정도 활동해야 하며 고객의 최대 관심인 솔루션을 협의하는 데 도움을 주어야 합니다.

작업 진행 모니터 페이지 맨 위

목적:  문제점 해결의 진행에 협업하고 관여하며 진행 상태를 파악합니다.  

방대하게 진행 중인 기본 제품 개발 및 기능 확장 중에 결함이나 기타 변경 요청이 분실될 수 있습니다. 이는 일부는 개발자가 이전 코드 및 버그가 있는 코드를 수정하는 것보다 "새 제품"에서 작업하는 것을 더 선호하기 때문이며, 또 일부는 고장난 부분을 수정하는 것보다 새로운 것을 추가하는 것에 비즈니스적인 가치를 더 분명하게 가질 수 있기 때문입니다. 품질이 허용하는 한, 테스트 팀은 완료 시까지 프로젝트에서 중요한 결함 수정사항을 확인할 수 있도록 해야 합니다.

성공적인 소프트웨어 팀은 결함 해결을 통한 점진적인 품질 향상과 점진적인 기능 확장 간의 균형을 잘 맞춥니다. 테스트 팀은 도움이 되기는 커녕 오히려 더 적대적인 "품질 정책" 역할을 수행하기 보다는 점진적인 품질 향상을 촉진하고 지원하는 방법을 찾아서 프로젝트 팀에게 협조할 수 있습니다.

주요 문제의 적절한 해결책 확인 페이지 맨 위

목적:  주요 문제에 대한 해결책이 심각한 부작용 없이 문제를 효과적으로 해결하는지 확인합니다.  

개발 팀이 품질 문제를 해결하기 위해 어떤 솔루션을 정하든지 그 해결책은 궁극적으로 품질을 향상시켜야 합니다. 제공된 해결책으로 얻은 품질의 향상은 시간을 두고 천천히 평가해야 하며 원래 문제점을 처리하고 다른 방법으로 품질에 불리한 영향을 주지 않아야 합니다.

어느 정도의 위험을 수반하는 솔루션의 경우, 결론에 이르기까지 해결책을 따르는 데 너무 많은 시간과 노력을 소비하기 전에 초기 릴리즈 후보 테스트를 수행하는 것이 좋습니다.

결과 평가 및 확인 페이지 맨 위

목적:  활동이 제대로 완료되었는지 및 결과물이 승인 가능한지 확인합니다. 

이제 작업을 완료하여 작업이 충분한 가치가 있었는지, 단순히 서류 작업만 많이 한 것은 아닌지 확인하는 것이 좋습니다. 작업이 적정 품질을 유지하는지와 이를 팀 구성원이 계속해서 작업에 대한 입력으로 사용할 수 있을 만큼 완전한지 평가해야 합니다. 가능한 경우, 품질 및 완성도가 "만족"한지를 확인하려면 RUP에 제공된 점검 목록을 사용하십시오.

중간 작업 검토 중에 입력이 필요할 때 사용자가 작업에 의존하는 다운스트림 활동을 수행하게 하십시오. 문제점을 처리하기 위한 조치를 취할 수 있는 시간이 있을 때 이를 수행하십시오. 주요 입력물을 정확하고 충분히 기술했는지 확인하기 위해 주요 입력물에 대한 작업도 평가해야 합니다. 이를 토대로 입력물 작성자가 작업을 검토하게 하는 것이 유용할 수 있습니다.

해당 RUP는 반복 프로세스이므로 대부분의 경우 시간이 지나면 결과물이 변경됨을 유념하십시오. 이는 늘 필요한 것은 아니며 종종 부분적으로만 사용되고 바로 다음의 후속 작업에는 전혀 사용되지 않는 비생산적이고 완전한 양식의 결과물입니다. 이는 결과물의 주변 상황이 변경되어 결과물을 사용하기 전에 결과물 작성시 세웠던 가정이 올바르지 않다고 입증되어 노력을 허비하고 재작업 비용이 많이 들 가능성이 높기 때문입니다. 또한 프리젠테이션에 너무 많은 순환을 사용하여 내용 가치를 손상시키는 실수를 하지 않도록 하십시오. 프리젠테이션이 프로젝트를 실행할 수 있는 기능으로서의 중요하고 경제적인 가치를 갖는 프로젝트 환경에서 프리젠테이션 타스크를 수행하기 위해 관리 자원의 사용을 고려하고자 할 수 있습니다.



Rational Unified Process   2003.06.15