how create requirements traceability matrix
소프트웨어 테스팅의 RTM (Requirements Traceability Matrix)이란 무엇입니까? 예제 및 샘플 템플릿을 사용하여 추적 가능성 매트릭스를 생성하는 단계별 가이드
오늘의 자습서는 중요한 QC 도구에 관한 것입니다. 즉, 지나치게 단순화되거나 (간과 됨) 지나치게 강조됩니다. 추적 성 매트릭스 (TM).
대부분의 경우 추적 가능성 매트릭스의 작성, 검토 또는 공유는 주요 QA 프로세스 결과물 중 하나가 아니므로 크게 집중되지 않아 강조가 부족합니다. 반대로 일부 고객은 TM이 자신의 제품 (테스트 중)에 대한 지극히 큰 측면을 드러 낼 것으로 기대하고 실망합니다.
'올바르게 사용하면 추적 성 매트릭스가 QA 여정을위한 GPS가 될 수 있습니다.'
일반적으로 STH , 우리는이 기사에서 초월 명상의“무엇”과“어떻게”측면을 볼 것입니다.
학습 내용 :
요구 사항 추적 성 매트릭스 란 무엇입니까?
요구 사항 추적 성 매트릭스 또는 RTM에서 우리는 클라이언트가 제안한 사용자 요구 사항과 구축중인 시스템 간의 링크를 문서화하는 프로세스를 설정했습니다. 요컨대 사용자 요구 사항을 테스트 사례와 매핑하고 추적하여 각각의 모든 요구 사항에 대해 적절한 수준의 테스트가 이루어지고 있는지 확인하는 고수준 문서입니다.
요구 사항에 대해 정의 된 모든 테스트 케이스를 검토하는 프로세스를 추적 가능성이라고합니다. 추적 가능성을 통해 테스트 프로세스 중에 가장 많은 수의 결함을 유발 한 요구 사항을 확인할 수 있습니다.
모든 테스트 계약의 초점은 최대 테스트 범위이며 그 범위 여야합니다. 적용 범위는 단순히 테스트 할 모든 것을 테스트해야 함을 의미합니다. 모든 테스트 프로젝트의 목표는 100 % 테스트 범위 여야합니다.
요구 사항 추적 성 매트릭스는 커버리지 측면을 확인하는 방법을 설정합니다. 커버리지 갭을 식별하기 위해 스냅 샷을 만드는 데 도움이됩니다. 요컨대, 모든 요구 사항에 대해 실행, 통과, 실패 또는 차단 된 테스트 케이스의 수를 결정하는 메트릭이라고도합니다.
요구 사항 추적 성이 필요한 이유는 무엇입니까?
요구 사항 추적 성 매트릭스는 요구 사항을 연결하는 데 도움이됩니다. 테스트 케이스 , 그리고 결함을 정확하게. 전체 애플리케이션은 요구 사항 추적 성 ( 종단 간 테스트 응용 프로그램의 달성).
xml 파일을 word로 보는 방법
요구 사항 추적 기능은 모든 기능이 테스트되므로 애플리케이션의 우수한 '품질'을 보장합니다. 품질 관리 최소한의 결함과 모든 기능적 및 비 기능적 요구 사항이 충족되는 예기치 않은 시나리오에 대해 소프트웨어가 테스트되므로 달성 할 수 있습니다.
요구 사항 추적 성 매트릭스는 소프트웨어 응용 프로그램이 규정 된 기간 내에 테스트되는 데 도움이되며 프로젝트 범위가 잘 결정되어 있으며 고객 요구 사항 및 요구 사항에 따라 구현이 이루어지며 프로젝트 비용이 잘 통제됩니다.
애플리케이션 전체가 요구 사항을 테스트하므로 결함 누출이 방지됩니다.
추적 성 매트릭스의 유형
순방향 추적 성
테스트 케이스에 대한 'Forward Traceability'요구 사항. 프로젝트가 원하는 방향으로 진행되고 모든 요구 사항이 철저하게 테스트되도록 보장합니다.
역추 적성
테스트 케이스는 '역방향 추적 성'의 요구 사항과 매핑됩니다. 주요 목적은 현재 개발중인 제품이 올바른 방향으로 진행되고 있는지 확인하는 것입니다. 또한 지정되지 않은 추가 기능이 추가되지 않았으므로 프로젝트 범위가 영향을 받는지 확인하는 데 도움이됩니다.
양방향 추적 성
(앞으로 + 뒤로) : Good Traceability 매트릭스에는 테스트 케이스에서 요구 사항으로 또는 그 반대로 참조 (테스트 케이스에 대한 요구 사항)가 있습니다. 이를 '양방향'추적 성이라고합니다. 모든 테스트 케이스를 요구 사항으로 추적 할 수 있고 지정된 각각의 모든 요구 사항에 정확하고 유효한 테스트 케이스가 있는지 확인합니다.
RTM의 예
# 1) 비즈니스 요구 사항
BR1 : 이메일 쓰기 옵션을 사용할 수 있어야합니다.
BR1에 대한 테스트 시나리오 (기술 사양)
TS1 : 편지 쓰기 옵션이 제공됩니다.
테스트 케이스 :
테스트 사례 1 (TS1.TC1) : 메일 작성 옵션이 활성화되고 성공적으로 작동합니다.
테스트 사례 2 (TS1.TC2) : 편지 쓰기 옵션이 비활성화됩니다.
# 2) 결함
테스트 케이스를 실행 한 후 결함이 발견되면 비즈니스 요구 사항, 테스트 시나리오 및 테스트 케이스와 함께 나열되고 맵핑 될 수 있습니다.
예를 들어, TS1.TC1이 실패하는 경우 (예 : 메일 작성 옵션이 활성화되었지만 제대로 작동하지 않는 경우) 결함이 기록 될 수 있습니다. 자동 생성되거나 수동으로 할당 된 결함 ID 번호가 D01이라고 가정하면 BR1, TS1 및 TS1.TC1 번호와 매핑 할 수 있습니다.
따라서 모든 요구 사항은 테이블 형식으로 표시 될 수 있습니다.
| 비즈니스 요구 사항 # | 테스트 시나리오 # | 테스트 사례 # | 결함 # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | 무 |
테스트 범위 및 요구 사항 추적 성
테스트 범위는 무엇입니까?
Test Coverage는 테스트 단계가 시작될 때 고객의 요구 사항을 확인해야하는 것을 나타냅니다. 테스트 커버리지는 최소 또는 NIL 결함이보고되는 방식으로 소프트웨어 애플리케이션을 완전히 테스트하기 위해 테스트 케이스가 작성되고 실행되는지 여부를 결정하는 용어입니다.
테스트 커버리지를 달성하는 방법은 무엇입니까?
우수한 '요구 사항 추적 성'을 설정하여 최대 테스트 범위를 달성 할 수 있습니다.
- 모든 내부 결함을 설계된 테스트 케이스에 매핑
- 향후 회귀 테스트 스위트를 위해 모든 CRD (고객보고 결함)를 개별 테스트 케이스에 매핑
요구 사항 사양 유형
# 1) 비즈니스 요구 사항
실제 고객의 요구 사항은 다음과 같은 문서에 나열되어 있습니다. 비즈니스 요구 사항 문서 (BRS) . 이 BRS는 클라이언트와의 간단한 상호 작용 후 세부적으로 파생 된 상위 수준 요구 사항 목록입니다.
일반적으로 '비즈니스 분석가'또는 프로젝트 '설계자'가 준비합니다 (조직 또는 프로젝트 구조에 따라 다름). '소프트웨어 요구 사항 사양'(SRS) 문서는 BRS에서 파생되었습니다.
# 2) 소프트웨어 요구 사항 사양 문서 (SRS)
모든 기능 및 비 기능 요구 사항에 대한 모든 세심한 세부 사항이 포함 된 자세한 문서입니다. 이 SRS는 소프트웨어 응용 프로그램을 설계하고 개발하기위한 기준입니다.
# 3) 프로젝트 요구 사항 문서 (PRD)
PRD는 프로젝트의 모든 팀원이 제품이 무엇을해야하는지 정확히 알려주는 참조 문서입니다. 제품의 목적, 제품 기능, 출시 기준, 프로젝트 예산 및 일정과 같은 섹션으로 나눌 수 있습니다.
# 4) 사용 사례 문서
비즈니스 요구에 따라 소프트웨어를 설계하고 구현하는 데 도움이되는 문서입니다. 목표를 달성하기 위해 수행해야하는 역할과 함께 배우와 이벤트 간의 상호 작용을 매핑합니다. 작업을 수행해야하는 방법에 대한 자세한 단계별 설명입니다.
예를 들어,
배우: 고객
역할: 게임 다운로드
게임 다운로드에 성공했습니다.
사용 사례는 조직의 작업 프로세스에 따라 SRS 문서에 포함될 수도 있습니다.
# 5) 결함 확인 문서
결함과 관련된 모든 세부 정보를 포함하여 문서화됩니다. 팀은 결함을 수정하고 다시 테스트하기 위해 '결함 확인'문서를 유지할 수 있습니다. 테스터는 '결함 확인'문서를 참조하여 결함이 수정되었는지 여부를 확인하고 다른 OS, 장치, 다른 시스템 구성 등에서 결함을 다시 테스트 할 수 있습니다.
'결함 확인'문서는 전용 결함 수정 및 확인 단계가있을 때 편리하고 중요합니다.
# 6) 사용자 스토리
사용자 스토리는 주로 최종 사용자 관점에서 소프트웨어 기능을 설명하기 위해 'Agile'개발에 사용됩니다. 사용자 스토리는 사용자 유형과 특정 기능을 원하는 방식과 이유를 정의합니다. 사용자 스토리를 생성하면 요구 사항이 단순화됩니다.
현재 모든 소프트웨어 산업은 요구 사항을 기록하기 위해 사용자 스토리와 애자일 개발 및 해당 소프트웨어 도구를 사용하는 방향으로 이동하고 있습니다.
요구 사항 수집에 대한 과제
#1) 수집 된 요구 사항은 상세하고, 모호하지 않으며, 정확하고 잘 지정되어야합니다. 하지만 거기에는 하지 마라 요구 사항 수집에 필요한 이러한 세부 사항, 명확성, 정확성 및 잘 정의 된 사양을 계산하기위한 적절한 측정.
#두) 요구 사항 정보를 제공하는 '비즈니스 분석가'또는 '제품 소유자'의 해석이 중요합니다. 마찬가지로 정보를받는 팀은 이해 관계자의 기대치를 이해하기 위해 적절한 설명을해야합니다.
이해는 비즈니스 요구 사항과 애플리케이션 구현에 필요한 실제 노력과 일치해야합니다.
#삼) 정보는 또한 최종 사용자의 관점에서 파생되어야합니다.
# 4) 이해 관계자의 상태가 서로 다른시기에 요구 사항을 상충하거나 모순합니다.
# 5) 최종 사용자의 관점은 여러 가지 이유로 고려되지 않으며 추가 이해 관계자는 일반적으로 그렇지 않은 제품에 필요한 것이 무엇인지 '완전히'이해한다고 생각합니다.
# 6) 개발 된 응용 프로그램에 대한 기술이 부족한 리소스.
# 7) 응용 프로그램의 잦은 '범위'변경 또는 모듈의 우선 순위 변경.
# 8) 누락, 암시 적 또는 문서화되지 않은 요구 사항.
# 9) 고객이 결정한 일관되지 않거나 모호한 요구 사항.
# 10) 위에서 언급 한 모든 요소의 결론은 프로젝트의 '성공'또는 '실패'가 요구 사항에 따라 크게 좌우된다는 것입니다.
화이트 박스 테스트 예제 테스트 케이스
요구 사항 추적이 도움이되는 방법
# 1) 요구 사항은 어디에서 구현됩니까?
예를 들어,
요구 사항 : 메일 애플리케이션에서 '메일 작성'기능을 구현합니다.
이행: 메인 페이지에서‘메일 작성’버튼을 배치하고 액세스해야합니다.
# 2) 요구 사항이 필요합니까?
예를 들어,
요구 사항 : 특정 사용자에게만 메일 애플리케이션의 '메일 작성'기능을 구현합니다.
이행: 사용자 액세스 권한에 따라 이메일받은 편지함이 '읽기 전용'인 경우이 경우 '메일 작성'버튼이 필요하지 않습니다.
# 3) 요구 사항을 어떻게 해석합니까?
예를 들어,
요구 사항 : 글꼴 및 첨부 파일이있는 메일 응용 프로그램의 '메일 작성'기능.
이행: '메일 작성'을 클릭하면 어떤 기능을 제공해야합니까?
- 이메일을 작성하고 다양한 글꼴 유형으로 편집하고 굵은 기울임 꼴로 밑줄을 긋는 텍스트 본문
- 첨부 파일 유형 (이미지, 문서, 기타 이메일 등)
- 첨부 파일 크기 (최대 허용 크기)
따라서 요구 사항은 하위 요구 사항으로 분류됩니다.
# 4) 요구 사항 구현에 영향을 미치는 설계 결정은 무엇입니까?
예를 들어,
요구 사항 : '받은 편지함', '보낸 편지함', '임시 보관함', '스팸 함', '휴지통'등의 모든 요소가 명확하게 표시되어야합니다.
이행: 표시 할 요소는 '트리'형식 또는 '탭'형식으로 표시되어야합니다.
# 5) 모든 요구 사항이 할당되어 있습니까?
예를 들어,
요구 사항 : '휴지통'메일 옵션이 제공됩니다.
이행: '휴지통'메일 옵션이 제공된 경우 '삭제'메일 옵션 (요구 사항)이 초기에 구현되어야하며 정확하게 작동해야합니다. '삭제'메일 옵션이 제대로 작동하면 삭제 된 이메일 만 '휴지통'에 수집되며 '휴지통'메일 옵션 (필수 사항)을 구현하면 유용합니다 (유용함).
RTM 및 테스트 범위의 장점
#1) 개발 및 테스트 된 빌드에는 '고객'/ '사용자'요구와 기대를 충족하는 필수 기능이 있습니다. 고객은 그가 원하는 것을 얻어야합니다. 예상 한 작업을 수행하지 않는 응용 프로그램으로 고객을 놀라게하는 것은 누구에게나 만족스러운 경험이 아닙니다.
#두) 고객에게 개발 및 제공되는 최종 제품 (소프트웨어 응용 프로그램)에는 필요하고 예상되는 기능 만 포함되어야합니다. 소프트웨어 응용 프로그램에서 제공되는 추가 기능은 시간, 비용 및 개발 노력의 오버 헤드가있을 때까지 처음에는 매력적으로 보일 수 있습니다.
추가 기능은 설치 후 고객에게 문제를 일으킬 수있는 결함의 원인이 될 수도 있습니다.
#삼) 개발자의 초기 작업은 고객 요구 사항에 따라 우선 순위가 높은 요구 사항을 구현하기 위해 먼저 작업 할 때 명확하게 정의됩니다. 고객의 우선 순위가 높은 요구 사항이 명확하게 지정되면 해당 코드 구성 요소를 최우선 순위로 개발하고 구현할 수 있습니다.
따라서 최종 제품이 고객에게 배송 될 가능성은 최상위 요구 사항에 따라 일정대로 유지됩니다.
# 4) 테스터는 먼저 개발자가 구현 한 가장 중요한 기능을 확인합니다. 우선 순위 소프트웨어 구성 요소의 검증 (테스트)이 먼저 수행되므로 시스템의 첫 번째 버전이 출시 될 준비가 된시기와 여부를 결정하는 데 도움이됩니다.
# 5) 정확한 테스트 계획, 테스트 케이스가 작성 및 실행되어 모든 애플리케이션 요구 사항이 올바르게 구현되었는지 확인합니다. 요구 사항과 매핑 된 테스트 케이스는 주요 결함이 누락되지 않도록하는 데 도움이됩니다. 또한 고객의 기대에 따라 고품질 제품을 구현하는 데 도움이됩니다.
# 6) 클라이언트의 '변경 요청'이있는 경우 변경 요청의 영향을받는 모든 응용 프로그램 구성 요소가 수정되고 아무것도 간과되지 않습니다. 이를 통해 변경 요청이 소프트웨어 응용 프로그램에 미치는 영향을 평가할 때 더욱 향상됩니다.
# 7) 단순 해 보이는 변경 요청은 응용 프로그램의 여러 부분에 대해 수행해야하는 수정을 포함 할 수 있습니다. 변경에 동의하기 전에 얼마나 많은 노력이 필요한지에 대한 결론을 도출하는 것이 좋습니다.
테스트 커버리지의 과제
# 1) 좋은 소통 채널
제안 된 변경 사항이있는 경우 이해 관계자 , 같은 내용이 초기 개발 단계에서 개발 및 테스트 팀에 전달되어야합니다. 이것없이 정시에 애플리케이션 개발, 테스트 및 결함 포착 / 수정은 보장 할 수 없습니다.
# 2) 테스트 시나리오의 우선 순위를 지정하는 것이 중요합니다.
우선 순위가 높고 복잡하며 중요한 테스트 시나리오를 식별하는 것은 어려운 작업입니다. 모든 것을 테스트하려고 테스트 시나리오 거의 달성 할 수없는 작업입니다. 시나리오 테스트의 목표는 비즈니스 및 최종 사용자의 관점에서 매우 명확해야합니다.
# 3) 프로세스 구현
테스트 프로세스는 기술 인프라 및 구현, 팀 기술, 과거 경험, 조직 구조 및 후속 프로세스, 비용, 시간 및 리소스와 관련된 프로젝트 추정, 시간대에 따른 팀 위치 등을 고려하여 명확하게 정의되어야합니다.
언급 된 요소를 고려한 일관된 프로세스 구현은 프로젝트와 관련된 모든 개인이 동일한 페이지에 있도록 보장합니다. 이는 애플리케이션 개발과 관련된 모든 프로세스의 원활한 흐름을 돕습니다.
# 4) 자원 가용성
리소스에는 숙련 된 도메인 별 테스터와 테스터가 사용하는 테스트 도구의 두 가지 유형이 있습니다. 테스터가 도메인에 대한 적절한 지식을 가지고 있다면 효과적인 테스트 시나리오와 스크립트를 작성하고 구현할 수 있습니다. 이러한 시나리오와 스크립트를 구현하려면 테스터가 적절한 '테스트 도구'를 갖추고 있어야합니다.
유일하게 숙련 된 테스터와 적절한 테스트 도구를 통해 애플리케이션을 제대로 구현하고 고객에게 적시에 제공 할 수 있습니다.
# 5) 효과적인 테스트 전략 구현
' Test Strategy '자체는 크고 별도의 토론 주제입니다. 그러나 여기서 '테스트 범위'의 경우 효과적인 테스트 전략 구현은 ' 품질' 응용 프로그램의 좋은 그리고 그건 유지 모든 곳에서 일정 기간 동안.
효과적인 '테스트 전략'은 모든 종류의 중요한 과제를 미리 계획하는 데 중요한 역할을하므로 더 나은 애플리케이션을 개발하는 데 도움이됩니다.
요구 사항 추적 성 매트릭스를 만드는 방법
함께하기 위해서는 추적하거나 추적해야하는 것이 무엇인지 정확히 알아야합니다.
테스터는 테스트 시나리오 / 목표를 작성하기 시작하고 결국에는 일부 입력 문서 (비즈니스 요구 사항 문서, 기능 사양 문서 및 기술 설계 문서 (선택 사항).
다음이 BRD (비즈니스 요구 사항 문서)라고 가정 해 보겠습니다. 이 샘플 BRD를 Excel 형식으로 다운로드 )
MP3 비디오 변환 도구로 YouTube
(확대하려면 이미지를 클릭하십시오)
다음은 BRD (비즈니스 요구 사항 문서)의 해석과 컴퓨터 응용 프로그램에 대한 적응을 기반으로 한 FSD (기능 사양 문서)입니다. 이상적으로는 FSD의 모든 측면이 BRD에서 다루어 져야합니다. 하지만 간단하게하기 위해 포인트 1과 2 만 사용했습니다.
BRD 위의 샘플 FSD : ( 이 샘플 FSD를 Excel 형식으로 다운로드 )
노트 : BRD 및 FSD는 QA 팀에서 문서화하지 않습니다. 우리는 다른 프로젝트 팀과 함께 문서의 소비자 일뿐입니다.
위의 두 입력 문서를 기반으로 QA 팀은 테스트 할 상위 수준 시나리오 목록을 아래에 제시했습니다.
위 BRD 및 FSD의 샘플 테스트 시나리오 : ( 이 샘플 테스트 시나리오 파일 다운로드 )
여기에 도착하면 지금이 요구 사항 추적 성 매트릭스 작성을 시작하기에 좋은시기입니다.
저는 개인적으로 추적하려는 각 문서에 대한 열이있는 매우 간단한 엑셀 시트를 선호합니다. 비즈니스 요구 사항 및 기능 요구 사항은 고유하게 번호가 지정되지 않으므로 문서의 섹션 번호를 사용하여 추적 할 것입니다.
(특히 사례에 가장 적합한 항목에 따라 줄 번호 또는 글 머리 기호 번호 등을 기준으로 추적하도록 선택할 수 있습니다.)
다음은 간단한 추적 가능성 매트릭스가 예제를 찾는 방법입니다.
위의 문서는 BRD에서 FSD로, 그리고 최종적으로 테스트 시나리오 사이에 추적을 설정합니다. 이와 같은 문서를 작성하면 테스트 팀이 테스트 스위트를 작성하기 위해 초기 요구 사항의 모든 측면을 고려했는지 확인할 수 있습니다.
이 방법으로 남겨 둘 수 있습니다. 그러나 더 쉽게 읽을 수 있도록 섹션 이름을 포함하는 것을 선호합니다. 이렇게하면이 문서가 클라이언트 또는 다른 팀과 공유 될 때 이해가 향상됩니다.
결과는 다음과 같습니다.
다시 말하지만, 이전 형식을 사용하거나 나중에 사용할 수있는 선택은 귀하의 것입니다.
이것은 귀하의 TM의 예비 버전이지만 일반적으로 여기서 중지 할 때 그 목적에 부합하지 않습니다. 결함까지 외삽하면 최대의 이점을 얻을 수 있습니다.
방법을 살펴 보겠습니다.
당신이 생각 해낸 각 테스트 시나리오에 대해 적어도 하나 이상의 테스트 케이스가있을 것입니다. 따라서 거기에 도착하면 다른 열을 포함하고 아래와 같이 테스트 케이스 ID를 작성하십시오.
이 단계에서 추적 가능성 매트릭스를 사용하여 간격을 찾을 수 있습니다. 예를 들어, 위의 추적 가능성 매트릭스에서 FSD 섹션 1.2에 대해 작성된 테스트 케이스가 없음을 알 수 있습니다.
일반적으로 추적 가능성 매트릭스의 빈 공간은 조사 할 수있는 잠재적 영역입니다. 따라서 이와 같은 차이는 다음 두 가지 중 하나를 의미 할 수 있습니다.
- 테스트 팀은 '기존 사용자'기능을 고려하여 어떻게 든 놓쳤습니다.
- '기존 사용자'기능은 나중에 연기되거나 응용 프로그램의 기능 요구 사항에서 제거되었습니다. 이 경우 TM은 FSD 또는 BRD에서 불일치를 표시합니다. 이는 FSD 및 / 또는 BRD 문서에 대한 업데이트가 수행되어야 함을 의미합니다.
시나리오 1 인 경우 테스트 팀이 100 % 적용 범위를 보장하기 위해 좀 더 작업해야하는 위치를 나타냅니다.
시나리오 2에서 TM은 즉각적인 수정이 필요한 잘못된 문서를 가리키는 간격을 보여줄뿐만 아니라
이제 TM을 확장하여 테스트 케이스 실행 상태 및 결함을 포함하겠습니다.
아래 버전의 추적 가능성 매트릭스는 일반적으로 테스트 실행 중 또는 후에 준비됩니다.
요구 사항 추적 성 매트릭스 템플릿 다운로드 :
=> Excel 형식의 추적 성 매트릭스 템플릿
참고할 중요한 사항
다음은이 버전의 추적 가능성 매트릭스에 대해 유의해야 할 중요한 사항입니다.
#1) 실행 상태도 표시됩니다. 실행 중에 작업 진행 방식에 대한 통합 스냅 샷을 제공합니다.
# 2) 결함 : 이 열을 사용하여 역방향 추적 가능성을 설정하면 '새 사용자'기능이 가장 결함이 있음을 알 수 있습니다. 테스트 사례가 실패했다고보고하는 대신 TM은 대부분의 결함이있는 비즈니스 요구 사항에 대한 투명성을 제공하여 고객이 원하는 측면에서 품질을 보여줍니다.
#삼) 추가 단계로 결함 ID를 색상으로 구분하여 상태를 나타낼 수 있습니다. 예를 들어, 빨간색으로 표시된 결함 ID는 아직 열려 있음을 의미하고 녹색으로 표시되면 닫혀 있음을 의미합니다. 이 작업이 완료되면 TM은 특정 BRD 또는 FSD 기능에 해당하는 결함의 상태를 표시하는 상태 확인 보고서로 작동합니다.
# 4) 추적하려는 기술 설계 문서, 사용 사례 또는 기타 아티팩트가있는 경우 언제든지 추가 열을 추가하여 필요에 맞게 위에서 만든 문서를 확장 할 수 있습니다.
요약하자면 RTM은 다음을 지원합니다.
- 100 % 테스트 커버리지 보장
- 요구 사항 / 문서 불일치 표시
- 비즈니스 요구 사항에 초점을 맞춘 전체적인 결함 / 실행 상태를 표시합니다.
- 특정 비즈니스 및 / 또는 기능 요구 사항이 변경되어야하는 경우 TM은 테스트 사례에 대한 재검토 / 재 작업 측면에서 QA 팀의 작업에 미치는 영향을 추정하거나 분석하는 데 도움이됩니다.
또한
- 추적 성 매트릭스는 수동 테스트 전용 도구가 아니며 자동화 프로젝트에도 사용할 수 있습니다. 자동화 프로젝트의 경우 테스트 케이스 ID는 자동화 테스트 스크립트 이름을 나타낼 수 있습니다.
- QA 만 사용할 수있는 도구도 아닙니다. 개발 팀은 동일한 방법을 사용하여 BRD / FSD 요구 사항을 모든 요구 사항이 개발되었는지 확인하기 위해 생성 된 코드의 블록 / 단위 / 조건에 매핑 할 수 있습니다.
- 다음과 같은 테스트 관리 도구 HP ALM 내장 추적 기능이 제공됩니다.
주목해야 할 중요한 점은추적 성 매트릭스를 유지하고 업데이트하는 방식에 따라 사용 효과가 결정됩니다. 자주 업데이트하지 않거나 잘못 업데이트하면 도구가 도움이되는 대신 부담이되고 도구 자체가 사용할 가치가 없다는 인상을줍니다.
결론
요구 사항 추적 성 매트릭스는 지도 및 추적 테스트 케이스 및 발견 된 결함과 함께 클라이언트의 모든 요구 사항. 이것은 단일 문서 이는 테스트 케이스가 누락되지 않고 애플리케이션의 모든 기능이 다루어지고 테스트된다는 주요 목적을 제공합니다.
미리 계획된 좋은 '테스트 커버리지'는 테스트 단계에서 반복적 인 작업과 결함 누출을 방지합니다. 결함 수가 많으면 테스트가 잘 수행되어 애플리케이션의 '품질'이 향상되고 있음을 나타냅니다. 마찬가지로 결함 수가 매우 적다는 것은 테스트가 기준까지 완료되지 않았 음을 나타내며 이는 부정적인 방식으로 애플리케이션의 '품질'을 저해합니다.
테스트 커버리지가 철저히 수행되면 낮은 결함 수가 정당화 될 수 있으며이 결함 수는 기본 통계가 아닌 지원 통계로 간주 될 수 있습니다. 테스트 커버리지가 최대화되고 결함 수가 최소화 될 때 애플리케이션의 품질을 '양호'또는 '만족'이라고합니다.
저자 정보 : STH 팀원 Urmila P.는 경험이 풍부한 QA 전문가입니다. 고품질 테스트 및 문제 추적 기술.
프로젝트에서 요구 사항 추적 성 매트릭스를 만들었습니까? 이 기사에서 만든 것과 얼마나 비슷하거나 다른가요? 귀하의 의견을 통해이 기사에 대한 귀하의 경험, 의견, 생각 및 피드백을 공유하십시오.