test management tutorial
이것은 소프트웨어 테스팅을위한 테스트 관리 튜토리얼입니다. 여기에는 테스트 관리 단계, 도구 및 테스트 관리 대 조직 구조가 포함됩니다.
최고의 무료 이메일 계정은 무엇입니까
테스트 관리는 모든 테스트 관련 활동, 문서 및 기타 관련 작업을 관리하는 프로세스입니다. 조직 구조는 특정 프로젝트에서 작업하는 팀 또는 직원의 계층 구조를 나타냅니다.
조직 구조가 테스트 관리에 영향을 미친다고 생각하십니까?
귀하의 대답이 아니오 인 경우 이유를 알 수 있습니다. 그렇다면 그것이 어떤 영향을 미치는지 봅시다. 이 둘 사이의 관계를 찾으려면이 주제를 명확하게 이해 한 다음 테스트 관리와 조직 구조 간의 관계를 탐색해야합니다.
학습 내용 :
테스트 관리 소개
테스트 관리는 특정 프로젝트에 대한 소프트웨어 테스트의 전체 프로세스를 관리하는 것을 의미합니다. 테스트 관리 프로세스는 전체 소프트웨어 개발 수명주기에 적용됩니다. 따라서 이상적으로는 소프트웨어 개발 프로세스가 시작되는 즉시 테스트 관리 프로세스도 시작되어야합니다.
테스트 관리자는 다음과 같은 책임이 있습니다.
- 테스트 관리자는 이러한 작업 제품의 일관성과 품질을 보장해야합니다.
- Test Analyst 및 Technical Test Analyst와 협력하여 적절한 템플릿을 선택하고 사용자 지정합니다.
- 테스트 분석가 및 기술 테스트 분석가와 협력하여 세부 수준과 같은 이러한 제품의 표준을 설정합니다.
- 적절한 기술을 사용하여 산출물을 검토하십시오.
테스트 관리 구성 요소
테스트 관리는 더 나은 이해를 위해 5 개 부분으로 나뉩니다.
- 테스트 문서
- 테스트 추정
- 테스트 지표
- 테스트 진행 상황 측정
- 테스트 수명주기 모니터링을위한 메트릭
# 1) 테스트 문서
아래에 나열된 세 가지 유형의 테스트 문서가 있습니다.
- 테스트 정책
- 테스트 전략
- 마스터 테스트 계획
# 1) 테스트 정책 :
- 조직이 테스트를 통해 얻는 가치를 요약합니다.
- 테스트 정책을 정의합니다.
- 테스트의 효과를 평가하는 방법을 설명합니다.
- 테스트 프로세스를 설명합니다.
- 조직이 테스트 프로세스를 개선하는 방법을 지정합니까?
# 2) 테스트 전략 :
- 프로젝트 및 제품 위험을 관리하는 데 사용되는 일반적인 테스트 방법을 설명합니다.
- 분석 전략 : 위험 기반 테스트와 같습니다.
- 모델 기반 전략 : 테스트 팀이 환경, 입력 및 조건의 실제 및 수용된 상황을 기반으로 모델을 개발하는 운영 프로필과 같습니다.
- 방법 론적 전략 : 테스트 팀이 일련의 테스트 조건, 체크리스트 또는 일반화 된 논리적 테스트 모음을 사용하는 품질 특성.
- 프로세스 또는 표준 준수 기술 : SCRUM / Agile과 같은 일련의 프로세스를 따릅니다.
- 대응 전략 : 탐색 테스트와 같은 결함 기반 공격을 사용합니다.
- 컨설팅 전략 : 테스트 팀이 아웃소싱 호환성 테스트와 같은 테스트 조건을 결정하기 위해 하나 이상의 이해 관계자의 입력에 의존하는 사용자 지시 테스트와 유사합니다.
- 또한 다음을 설명합니다.
- 통합 절차
- 테스트 사양 기술
- 테스트의 독립성
- 필수 및 선택 표준
- 테스트 환경
- 도구
- 소프트웨어 제품의 재사용 성
- 재시험 및 회귀.
# 3) 마스터 테스트 계획 :
- 수행해야하는 모든 테스트 작업을 다룹니다.
- 테스트가 테스트 전략 및 정책을 구현하는 방법에 대해 설명합니다.
- 설명되지 않은 것이 있으면 테스트 계획에 이유와 이에 대한 완화 계획을 설명해야합니다.
- 테스트 계획의 내용은 다음과 같습니다.
- 테스트 할 항목
- 테스트 할 품질 특성.
- 시간표
- 실행주기
- 결함 변수
- 범위의 테스트 항목
- 종료 기준
- 프로젝트 위험
- 테스트 노력의 전반적인 거버넌스,
- 역할과 책임
- 입력과 출력
# 2) 테스트 추정
일반 사항 :
- 관리 활동입니다
- 경험을 바탕으로합니다.
- 비용, 자원, 작업 및 사람의 구체적이고 상세한 카탈로그를 제공합니다.
- 일단 준비된 견적은 정당성과 함께 경영진에게 전달되어야합니다.
- 최종 추정치는 조직 및 프로젝트 목표의 가능한 최상의 균형을 나타냅니다.
- 추정치는 당시 이용 가능한 정보를 바탕으로 작성되었습니다.
- 정확한 상태를 유지하려면 새 정보 및 변경된 정보를 반영하도록 견적을 업데이트해야합니다.
테스트 추정에 영향을 미치는 요인 :
- 요구되는 품질 수준
- 시스템의 크기
- 역사적 데이터
- 전략, 개발 및 라이프 사이클과 같은 프로세스 요소
- 테스트 환경, 자동화, 도구 및 데이터와 같은 중요한 요소
- 사람 요인
- 프로세스의 복잡성
- 교육 및 KT (지식 이전)
- 새로운 도구와 기술, 프로세스 또는 기술의 동화 및 개발.
- 상세한 테스트 사양의 더 높은 수준의 요구 사항입니다.
- 부품 도착시기
- 테스트 데이터.
추측 :
- 작업 분할 구조
- 팀 추정 세션
- 테스터 – 개발자 비율
- 조직 역사
- 기능 포인트 분석, LOC.
테스트 추정은 자습서의 뒷부분에서 자세히 설명합니다.
# 3) 테스트 지표
- 측정되는 것은 완료된 것으로 간주됩니까?
- 측정하지 않는 것은 무시되기 쉽습니다.
- 제한된 유용한 메트릭 집합을 정의해야합니다.
- 모든 사람이 해석에 동의 한 메트릭 만 정의해야합니다.
- 메트릭보고 및 병합은 자동화되어야합니다.
- 관리자는 메트릭의 정보를 검증해야합니다.
프로젝트 지표 : 통과 비율, 실패 실행 등
제품 메트릭 :
- 제품의 특성
- 결함 밀도
프로세스 메트릭 : 결함 비율과 같은 테스트 능력을 측정합니다.
사람들: 개인의 능력.
테스트 진행 메트릭 :
- 계획된 대 실행 된 테스트 조건 / 케이스의 수입니다.
- 심각도, 우선 순위, 현재 상태 및 영향 하위 시스템별로 분류 된 총 결함.
- 필수, 수락, 빌드 및 테스트 된 변경의 수입니다.
- 계획된 비용과 실제 비용.
- 계획 및 실제 기간
- 계획된 대 실제 테스트 이정표.
- 제품 품질 위험 상태
- 테스트 노력, 비용 또는 시간의 % 손실.
# 4) 테스트 진행 상황 측정
제품 위험 :
- 보장되는 위험의 %.
- 실패 테스트에 대한 위험 비율
- % 개인이 식별 한 위험.
결함 :
- 발견 된 결함 수와 제출 된 결함 수.
- 평균 고장 도착률
- 특정 테스트 항목의 결함.
- RCA (Root Cause Analysis) 탐지
- 결함은 테스트 릴리스입니다.
- 단계적 결함
- 우선 순위 및 심각도
- 거부 대 중복보고
- 해결하는 데 걸리는 시간
- 기존 결함 수정으로 인해 새로 도입 된 결함 수입니다.
테스트:
- 테스트 통과, 실패, 러너, 차단의 총 수
- 회귀 테스트 케이스의 총 수입니다.
적용 범위:
- 요구 사항 및 설계 범위
- 위험 범위
- 환경 구성 범위
- 코드 커버리지
# 5) 테스트 수명주기 모니터링을위한 메트릭
테스트 계획 모니터링
- 위험 및 요구 사항 수
- 결함 발견
- 계획 대 실제 노력.
테스트 설계 모니터링
- 설계 중에 발견 된 결함 수입니다.
테스트 분석 모니터링
- 조건 수
- 분석의 결함 수
테스트 구현 모니터링
- 환경 구성 비율
- 테스트 사례의 %가 자동화되었습니다.
실행 모니터링
- 통과, 실패, 실행 안 함, 차단 된 테스트 케이스의 비율
- 적용되는 테스트 사례 비율
- 계획된 결함과 실제 결함이 해결됨
- 계획 대비 실제 적용 비율
모니터 폐쇄
- 테스트 케이스의 % 통과, 문제
- 재사용 가능한 범주에 체크인 된 테스트 케이스 비율
- 테스트 사례의 %가 자동화되었습니다.
- 해결 된 / 해결되지 않은 결함 수입니다.
- 테스트 작업 제품의 %
아래에서 설명하는 테스트 모니터링 및 제어 단계에서이 항목에 대해 자세히 설명합니다.
테스트 관리 단계
테스트 관리 과정에서 다음 사항을 고려해야합니다. 즉, 다음은 테스트 관리 프로세스의 여러 단계입니다.
- 위험도 분석
- 테스트 추정
- 테스트 계획
- 테스트 조직
- 테스트 모니터링 및 제어
- 이슈 관리
- 시험 보고서
처음 네 단계는 계획에 관한 것이고 나머지 세 단계는 실행에 관한 것임을 알 수 있습니다. 따라서 전체 테스트 관리 프로세스를 계획과 실행의 두 부분으로 나눌 수 있습니다.
다양한 테스트 관리 단계를 자세히 살펴 보겠습니다.
# 1) 위험 분석
이 단계에는 위험 요소와 가능한 솔루션을 찾는 것이 포함됩니다. 위험 분석을 철저히 수행하면 향후 실패를 방지하거나 최소한 어떤 종류의 솔루션을 사용할 수 있습니다.
위험은 발생하거나 발생하지 않을 수있는 것입니다. 그러나 그것이 발생하면 그 영향은 무엇입니까? 소프트웨어의 품질, 회사의 평판 등에 악영향을 미칠 수 있습니다.
이러한 나쁜 영향을 피하려면 위험 요소를 찾아야합니다. 위험 요소를 찾기 위해 위험 분석을 수행해야합니다. 위험에는 프로젝트 위험과 제품 위험의 두 가지 유형이 있습니다. 프로젝트 위험은 작업 프로세스와 관련된 위험이고 제품 위험은 개발 된 제품과 관련된 위험입니다.
# 2) 테스트 추정
테스트 추정은 각 테스트 활동 / 단계에 필요한 시간을 예측하는 것입니다. 이것은 추정치이므로 정확할 수 없습니다. 더 나은 테스트 평가를 위해 회사의 과거 프로젝트를 연구하거나 해당 작업 또는 테스트 단계를 담당 할 팀원과 상담 할 수 있습니다.
# 3) 테스트 계획
테스트 계획 자체는 긴 프로세스입니다. 여기에는 테스트 목표, 테스트 범위, 테스트 전략, 시간 일정, 리소스, 커뮤니케이션 접근 방식 등의 정의가 포함됩니다. 요구 사항은 테스트 목표 및 범위를 정의하기 위해 매우 명확해야합니다. 테스트 계획은 테스터, 사용자 및 프로젝트 팀 구성원을위한 것입니다.
테스트 계획은 프로젝트에서 테스트의 역할을 설명합니다. 테스트 계획에는 역할과 책임, 테스트 할 예정이지만 테스트하지 않을 기능 목록, 테스트 환경, 도구 목록 및 가정 (있는 경우)도 포함됩니다.
# 4) 테스트 조직
테스트 계획 단계에서 테스트에 대해 가능한 모든 것을 계획했습니다.
모뎀과 라우터는 어떻게 생겼습니까?
따라서이 계획을 실행하거나 계획을 성공적으로 수행하려면 숙련 된 팀원이 필요합니다. 테스트 조직은 성공적인 프로젝트를위한 완벽한 테스트 팀을 구성하는 것입니다.
# 5) 테스트 모니터링 및 제어
테스트 작업이 진행 중이거나 테스터가 테스트 계획을 실행하는 동안 이러한 모든 작업 진행 상황을 모니터링해야합니다. 이 모든 테스트 작업을 추적해야합니다. 테스트 모니터링이 완료되면 테스트 팀과 테스트 관리자가 테스트 진행 상황에 대한 피드백을 받게됩니까?
이 피드백을 사용하여 테스트 관리자는 팀 구성원이 추가 테스트 작업의 품질을 개선하도록 안내 할 수 있습니다. 테스트 모니터링의 도움으로 프로젝트 팀은 테스트 결과에 대한 가시성을 얻을 수 있습니다. 또한 테스트 범위에 대해 아는 데 도움이됩니다.
대규모 프로젝트의 경우 데이터 수집이 더 쉬워 지므로 자동화 된 도구를 사용하여 테스트 모니터링이 수행됩니다. 소규모 프로젝트의 경우 한 사람이 테스트 진행과 관련된 모든 데이터 또는 문서를 수집합니다. 테스트 진행 정보를 수집하기 위해 IEEE 829 테스트 로그 템플릿의 도움을받을 수 있습니다. 이것은 테스트 모니터링에 관한 것입니다.
테스트 컨트롤이 무엇인지 봅시다. 프로젝트 작업이 항상 우리가 계획 한대로 진행되는 것은 아닙니다. 계획과 실제 작업간에 약간의 차이가있을 수 있습니다. 이러한 차이를 최소화하거나 제거하려면 몇 가지 변경이 필요하며 이것이 테스트 작업을 제어하는 방법입니다.
# 6) 이슈 관리
문제는 소프트웨어 개발 및 테스트 프로세스 중에 발생하는 모든 문제 일 수 있습니다. 그것은 우리가 양질의 제품을 개발 / 제공 할 수없는 가장 작은 이유 일 수 있습니다. 일부 문제는 눈을 뗄 수없는 문제입니다. 즉, 해당 문제를 해결하지 않으면 추가 프로세스를 진행할 수 없습니다.
문제 관리는 이러한 문제 / 문제를 처리하는 방법에 관한 것입니다. 사고 관리라고 부를 수도 있습니다. 문제 관리에는 문제 해결 프로세스에 대한 더 나은 계획이 필요합니다. 더 나은 문제 관리는 테스트 관리자의 기술과 경험에 달려 있습니다.
이러한 문제는 어떻게 발생합니까?
문제가 발생하는 데는 여러 가지 이유가있을 수 있습니다. 일부 문제는 전략과 관련이 있고 일부는 정의, HR, 일정 등과 관련이 있습니다.
전략 문제 :
예 :
- 프로젝트에 자금이 부족합니다.
- 프로젝트 커뮤니케이션 불량.
- 프로젝트 관리 프로세스가 명시된 표준을 따르지 않습니다.
정의 문제 : 요구 사항과 관련된 문제.
예 : 불분명 한 요구 사항. 불분명 한 요구 사항으로 인해 많은 문제가 발생할 수 있습니다.
일정 문제 : 이것은 가장 일반적인 유형의 문제입니다. 직원들은 마감일을 맞추기 위해 고군분투해야합니다.
HR 문제 :
C ++ 버블 정렬 배열
예 :
- 팀의 기술이 부족합니다.
- 업무에 대한 잘못된 직원 매핑.
더 많은 유형의 문제가있을 수 있으며 여기에서 모두 언급 할 수는 없습니다. 따라서 문제 관리는 문제를 로깅, 추적 및 해결하는 것입니다.
# 7) 테스트 보고서
테스트 보고서는 테스트 범위, 개발 된 제품의 품질 및 필요한 프로세스 개선을 식별하는 데 도움이됩니다. '얼마나 많은 테스트가 필요한가요?'를 결정할 수 있습니다.
충분한 테스트가 완료되면이 테스트 보고서를 이해 관계자 또는 고객에게 제출할 수 있습니다. 그래서 그들은 또한 제품의 품질을 알고 제품에 대해 얼마나 많은 테스트가 수행되는지에 대한 아이디어를 얻습니다.
테스트 관리 도구
소프트웨어 개발 프로세스를 진행하면서 테스트 관리가 복잡해지며, 이것이 오늘날 많은 테스트 관리 도구를 사용할 수있는 주요 이유 중 하나입니다.
이러한 도구는 테스트 관리 프로세스의 마지막 4 단계 (테스트 조직, 테스트 모니터링 및 제어, 문제 관리 및 테스트 보고서)를 지원합니다. 이러한 도구는 테스트 관리의 중요한 단계에 도움이되므로 프로젝트에서 가장 먼저 고려해야합니다.
다음은 가장 인기있는 테스트 관리 도구입니다.
- qTest
- PractiTest
- 미풍
- 공동 작업 테스트
- JIRA 용 TestFLO
- XQual
- Xray – 최첨단 테스트 관리
- TestRail
- QAC
- Jira (RTM)에 대한 요구 사항 및 테스트 관리
- Inflectra의 SPIRATEST
- Kualitee
- 아쿠아
- 테스트 패드
- JunoOne
=> TOP 테스트 관리 도구에 대한 자세한 리뷰를 보려면 여기를 클릭하십시오.
조직 구조
다양한 조직 구조를 살펴 보겠습니다.
조직 구조에 대한 특정 규칙이 있거나 이상적인 구조가있을 수 있지만 모든 조직이 그 구조를 가질 수 있다는 것과 관계없이. 조직 구조가 너무 많고 각각 장단점이 있습니다.
여기서 우리는 그들 중 일부를 논의 할 것입니다.
먼저 소규모 프로젝트에 사용되는 가장 간단한 조직 구조를 살펴 보겠습니다.
이 구조에서 테스터와 프로그래머는 모두 개발 관리자에게보고합니다.
- 개발 관리자는 프로젝트 활동을 잘 제어합니다.
- 테스트 팀과 개발 팀 간의 의사 소통 격차 가능성이 줄어들 것입니다.
- 또한 회의에서 테스트 및 개발 작업에 대한 완전한 지식을 보유하고 있기 때문에 개발 관리자의 기한을 결정하는 것이 좋습니다.
- 최소한의 레이어로 인해 팀워크가 효율적입니다.
이 구조의 단점은 다음과 같습니다.
- 테스팅 매니저가 없기 때문에 프로젝트 후반에 테스팅이 고려 될 가능성이 있습니다.
- 테스트가 프로젝트에서 덜 중요해질 가능성이 있습니다. 프로젝트 후반에 고려할 수 있습니다.
일반적으로 소규모 프로젝트를위한 소규모 조직에서는 개발 팀이 언급 한 것보다 더 많은 시간이 걸리고 테스트 팀이 고통을 겪어야합니다. 제품.
이 구조에서 프로젝트를 성공적으로 완료하기 위해 개발 관리자는 자신의 목표가 프로젝트를 완료하는 것이 아니라 양질의 소프트웨어를 개발하는 것임을 염두에 두어야합니다.
두 번째로 가장 일반적으로 사용되는 조직 구조 :
이것은 가장 일반적인 유형의 조직 구조입니다. 이 구조에서 테스터는 테스트 관리자에게보고하고 개발자는 개발 관리자에게보고합니다. 테스트 관리자와 개발 관리자 모두 프로젝트 관리자에게보고합니다.
테스트 관리자는 모든 테스트 관련 활동을 담당하며 개발할 소프트웨어를 확보하는 것은 개발 관리자의 책임입니다. 프로젝트 관리자는 테스트 및 개발 활동을 모두 제어합니다.
장점 :
- 이전 구조와 달리 여기이 구조에는 테스트 및 개발을위한 다른 관리자가 있으므로 둘 다 자신의 작업에 집중할 수 있습니다. 그들은 자신의 일에 전념하고 산만 함이 줄어들 것입니다.
- 이 구조에서는 테스트 활동을 무시하거나 프로젝트 후반에 고려할 수 없습니다. 즉, 테스트와 개발 모두 동일한 중요성을 갖게됩니다.
- 중요한 결정을 내릴 때 유리하게는 테스트 팀이 독립적입니다.
단점 :
- 여러 단계로 인해 의사 소통에 차이가있을 수 있습니다.
테스트 관리 대 조직 구조
조직 구조는 테스트 관리에 직접적인 영향을 미칩니다. 다른 조직 구조는 테스트 관리에 다른 영향을 미치므로 테스트 관리는 테스트 관리자의 기술과 경험뿐만 아니라 조직 구조에서 테스트 관리자의 위치에 따라 다릅니다.
여기서 두 가지 조직 구조를 보았습니다. 첫 번째 구조에서 개발 관리자와 테스트 관리자는 동일한 사람이므로 테스트 관리에 영향을줍니다. 개발 관리자는 소프트웨어 개발을 목표로하고 있으며이를 수행하는 동안 테스트 작업도 살펴 봐야합니다.
따라서 때때로 그는 편견 된 의견을 제시 할 수 있습니다. 그 / 그녀는 문제를 간과하고 진행할 수 있습니다. 이렇게하면 테스트 관리에 영향을 미칠 수 있습니다. 독립 테스트 관리자는 더 많은 정의를 제공 할 수 있으며 테스트 관리는 독립 테스트 관리자와 함께 더 나아질 것입니다.
결론
우리는 테스트 관리와 조직 구조를 개별적으로 그리고이 둘 사이의 관계와 함께 두 가지 주제를 모두 보았습니다. 조직 구조가 테스트 관리에 영향을 미친다는 결론을 내릴 수 있습니다.
위에서 언급 한 두 구조를 비교하면서 두 번째 구조에서는 테스트 관리가 첫 번째 구조보다 더 잘 처리됩니다. 그 이유는 전담 테스트 관리자 때문일 수 있습니다.
조직 구조는 조직마다 다릅니다. 테스트 관리를위한 몇 가지 정의 된 프로세스가 있지만 (또는 팀이 테스트 관리 도구를 사용할 수 있음) 테스트 관리는 조직 구조, 테스트 관리자, 테스트 관리자의 기술 및 경험이 다르기 때문에 다릅니다.
추천 도서
- TestLink 튜토리얼 : TestLink 테스트 관리 도구에 대한 평신도 가이드 (튜토리얼 # 1)
- Bugzilla 튜토리얼 : 결함 관리 도구 실습 튜토리얼
- SVN 튜토리얼 : Subversion을 사용한 소스 코드 관리
- TestLodge 튜토리얼-TestLodge 테스트 관리 도구를 사용하여 소프트웨어 테스트 프로젝트를 구성하는 방법
- 기능 테스트 대 비 기능 테스트
- Ultimate Test Management Tool의 추가 필수 기능 4 가지
- JIRA Tutorial : A Complete Hands-on How-To-Use JIRA Guide
- VersionOne 자습서 : 올인원 민첩한 프로젝트 관리 도구 가이드