소프트웨어 테스트를 위한 테스트 관리 자습서입니다. 여기에는 테스트 관리 단계,도구 및 테스트 관리 대 조직 구조가 포함됩니다.
테스트 관리는 모든 테스트 관련 활동,문서 및 기타 관련 작업을 관리하는 프로세스입니다. 조직 구조는 특정 프로젝트에서 작업하는 팀 또는 직원의 계층 구조를 나타냅니다.
조직 구조가 테스트 관리에 영향을 미친다고 생각하십니까?
당신의 대답이 아니오라면,우리는 왜 볼 것인가? 그렇다면 그것이 어떻게 영향을 미치는지 보자. 이 둘 사이의 관계를 찾으려면 이러한 주제를 명확하게 이해 한 다음 테스트 관리와 조직 구조 간의 관계를 탐색해야합니다.
테스트 관리 소개
테스트 관리는 특정 프로젝트에 대한 소프트웨어 테스팅의 전체 프로세스를 관리하는 것을 의미합니다. 테스트 관리 프로세스는 전체 소프트웨어 개발 라이프 사이클에 적용됩니다. 따라서 이상적으로 소프트웨어 개발 프로세스가 시작 되 자마자 테스트 관리 프로세스가 시작되어야합니다.
테스트 관리자는 다음과 같은 책임을 맡았습니다-
- 테스트 관리자는 이러한 작업 제품의 일관성과 품질을 보장해야합니다.
- 테스트 분석가 및 기술 테스트 분석가와 협력하여 적절한 템플릿을 선택하고 사용자 정의합니다.
- 테스트 분석가 및 기술 테스트 분석가와 협력하여 세부 수준의 수준과 같이 이러한 제품의 표준을 수립합니다.
- 적절한 기술을 사용하여 작업 제품을 검토하십시오.
테스트 관리 구성 요소
테스트 관리는 더 나은 이해를 위해 5 부분으로 나뉩니다:
- 테스트 문서
- 테스트 추정
- 테스트 메트릭
- 테스트 진행률 측정
- 테스트 라이프사이클 모니터링을 위한 메트릭
#1) 테스트 문서
아래에 나열된 세 가지 유형의 테스트 문서가 있습니다:
- 테스트 정책
- 테스트 전략
- 마스터 테스트 계획
#1) 테스트 정책:
- 조직에서 테스트에서 파생된 값을 요약합니다.
- 테스트 정책을 정의합니다.
- 은 테스트의 효과를 평가하는 방법을 설명합니다.
- 는 시험 과정을 개설합니다.
- 조직에서 테스트 프로세스를 개선하는 방법을 지정합니까?
#2) 테스트 전략:
- 프로젝트 및 제품 위험을 관리하는 데 사용되는 일반적인 테스트 방법론을 설명합니다.
- 분석 전략:위험 기반 테스트와 같습니다.
- 모델 기반 전략: 테스트 팀이 환경,입력 및 조건의 실제 및 허용 된 상황을 기반으로 모델을 개발하는 운영 프로필과 같습니다.
- 방법론 전략:테스트 팀이 일련의 테스트 조건,체크리스트 또는 일반화 된 논리적 테스트 모음을 사용하는 품질 특성.
- 프로세스 또는 표준 준수 기술:스크럼/애자일과 같은 일련의 프로세스를 따릅니다.
- 반응 전략:예비 테스트와 같은 결함 기반 공격 사용.
- 자문 전략: 테스트 팀이 아웃소싱 호환성 테스트와 같은 테스트 조건을 결정하기 위해 하나 이상의 이해 관계자의 입력에 의존하는 사용자 주도 테스트와 같습니다.
- 통합 절차
- 테스트 사양 기술
- 테스트 독립성
- 필수 및 선택적 표준
- 테스트 환경
- 도구
- 소프트웨어 제품의 재사용성
- 재시험 및 회귀.
#3) 마스터 테스트 계획:
- 수행해야 할 모든 테스트 작업을 다룹니다.
- 테스트에서 테스트 전략 및 정책을 구현하는 방법에 대해 설명합니다.
- 설명되지 않은 것이 있으면 테스트 계획에서 그 이유와 완화 계획을 설명해야 합니다.
- 테스트 계획의 내용은 다음과 같습니다:
- 테스트 할 항목
- 테스트 할 품질 특성.
- 일정
- 실행 주기
- 결함 변수
- 범위의 테스트 항목
- 종료 기준
- 프로젝트 위험
- 테스트 노력의 전반적인 거버넌스,
- 역할과 책임
- 입력 및 출력
#2) 시험 추정
일반 포인트:
- 관리 활동
- 그것은 경험을 기반으로합니다.
- 비용,자원,작업 및 사람에 대한 구체적이고 상세한 카탈로그를 제공합니다.
- 추정이 준비되면 정당화와 함께 경영진에게 전달되어야 한다.
- 최종 견적은 조직과 프로젝트 목표의 최상의 균형을 나타냅니다.
- 추정치는 당시 이용 가능한 정보를 바탕으로 작성하였다.
- 정확한 상태를 유지하기 위해서는 새로운 정보와 변경된 정보를 반영하여 추정치를 업데이트해야 한다.
시험 추정에 영향을 미치는 요인:
- 요구 품질 수준
- 시스템의 크기
- 역사 데이터
- 전략,개발 및 라이프 사이클과 같은 프로세스 요소
- 테스트 환경,자동화,도구 및 데이터와 같은 재료 요소
- 사람 요인
- 프로세스의 복잡성
- 교육 및 케이티(지식 이전)
- 새로운 도구 및 기술,프로세스 또는 기술의 동화 및 개발.
- 상세한 시험 명세의 고차의 필요조건.
- 부품 도착 타이밍
- 테스트 데이터.
추측:
- 작업 분류 구조
- 팀 추정 세션
- 테스터–개발자 비율
- 조직 이력
- 기능 포인트 분석,위치.
테스트 추정은 튜토리얼의 뒷부분에서 더 설명된다.
#3)테스트 메트릭
- 측정되는 것은 완료된 것으로 간주됩니까?
- 측정하지 않는 것은 무시하기 쉽다?
- 제한된 유용한 메트릭 집합을 정의해야 합니다.
- 모든 사람이 해석에 동의한 지표만 정의해야 한다.
- 메트릭의 보고 및 병합을 자동화해야 합니다.
- 관리자는 메트릭에서 정보를 검증해야 합니다.
프로젝트 메트릭:합격률,실패 실행 등
제품 메트릭:
- 제품의 속성
- 결함 밀도
프로세스 메트릭:결함의%와 같은 테스트 기능을 측정합니다.
사람:개인의 능력.
테스트 진행률 메트릭:
- 테스트 조건/사례의 수(계획 대 실행)입니다.
- 총 결함은 심각도,우선 순위,현재 상태 및 효과 하위 시스템별로 분류됩니다.
- 요구,수락,빌드 및 테스트된 변경 수입니다.
- 계획 대 실제 비용.
- 계획 대 실제 기간
- 계획 대 실제 테스트 마일스톤.
- 제품 품질 위험 상태
- %테스트 노력,비용 또는 시간의 손실.
#4) 테스트 진행률 측정
제품 위험:
- % 위험이 덮여 있습니다.
- 실패 테스트 위험의%
- %개인이 식별 한 위험.
결함:
- 발견된 결함의 수와 제출된 결함의 수입니다.
- 실패 도착 속도의 평균 시간
- 특정 테스트 항목의 결함.
- 결함은 테스트 릴리스입니다.
- 단계의 결함
- 우선 순위 및 심각도
- 보고서 거부 대 중복
- 이전 결함의 수정으로 인해 도입 된 새로운 결함의 수를 해결하는 데 시간이 걸렸습니다.
테스트:
- 테스트 통과,실패,러너,차단된
- 총 회귀 테스트 사례 수입니다.
적용:
- 요구사항 및 설계 적용 범위
- 위험 적용 범위
- 환경 구성 적용 범위
- 코드 적용 범위
#5) 테스트 수명 주기 모니터링을 위한 메트릭
테스트 계획 모니터링
- 위험 및 요구 사항 수
- 결함 발견
- 계획 대 실제 노력.
모니터 테스트 디자인
- 설계 중에 발견 된 결함의 수입니다.
모니터 테스트 분석
- 조건 수
- 분석의 결함 수
모니터 테스트 구현
- % 환경 구성
- %의 테스트 케이스가 자동화되었습니다.
모니터 실행
- %
- %테스트 사례 적용
- 계획 대 실제 결함 해결
- 계획의%대 실제 적용
모니터 폐쇄
- % 테스트 케이스 합격,테스트 케이스의
- %자동 테스트 케이스의 재사용 가능한 카테고리
- %로 확인.
- 결함의 수는 해결/해결되지.
- 테스트 작업 제품의%
아래에서 논의된 테스트 모니터링 및 제어 단계는 이 주제를 더 자세히 설명합니다.
테스트 관리 단계
테스트 관리 프로세스 중에 다음 사항을 고려해야 합니다. 즉,테스트 관리 프로세스의 여러 단계는 다음과 같습니다:
- 위험 분석
- 테스트 추정
- 테스트 계획
- 테스트 조직
- 테스트 모니터링 및 제어
- 문제 관리
- 테스트 보고서
처음 네 단계는 계획에 관한 것이고 나머지 세 단계는 실행에 관한 것입니다. 따라서 전체 테스트 관리 프로세스를 계획 및 실행의 두 부분으로 나눌 수 있습니다.
다양한 테스트 관리 단계를 자세히 살펴 보겠습니다.
#1)위험 분석
이 단계에는 위험 요소와 가능한 해결책을 찾는 것이 포함됩니다. 위험 분석이 철저히 수행되면 미래의 실패를 피할 수 있거나 적어도 어떤 종류의 솔루션을 사용할 수 있습니다.
위험은 일어날 수도 있고 일어나지 않을 수도 있습니다. 그러나 그것이 일어난다면 그 영향은 무엇입니까? 그것은 심하게 소프트웨어의 품질,회사의 명성 및 훨씬 더에 영향을 미칠 수 있습니다.
이 나쁜 영향을 피하기 위해 위험 요소를 찾아야합니다. 위험 요인을 찾기 위해 위험 분석을 수행해야합니다. 두 가지 유형의 위험이 있습니다. 프로젝트 위험 및 제품 위험. 프로젝트 위험은 작업 프로세스와 관련된 위험이며 제품 위험은 개발 된 제품과 관련된 위험입니다.
#2)시험 추정
시험 추정은 각 시험 활동/위상에 필요한 시간의 예측에 관한 것이다. 이 추정치는 정확할 수 없습니다. 더 나은 테스트 추정을 위해 우리는 우리 회사의 과거 프로젝트를 연구 할 수 있습니다 또는 우리는 그 작업 또는 테스트 단계에 대한 책임을 질 것입니다 팀 구성원과 상담 할 수 있습니다.
#3)테스트 계획
테스트 계획 자체는 긴 프로세스입니다. 여기에는 테스트 목표,테스트 범위,테스트 전략,시간 스케줄링,리소스,커뮤니케이션 접근법 등을 정의하는 것이 포함됩니다. 테스트 목표 및 범위를 정의하기위한 요구 사항은 매우 명확해야합니다. 테스트 계획은 테스터,사용자 및 프로젝트 팀 구성원을 위한 것입니다.
테스트 계획은 프로젝트에서 테스트의 역할을 설명합니다. 또한 테스트 계획에는 역할 및 책임,테스트할 기능 목록 및 테스트하지 않을 기능 목록,테스트 환경,도구 목록 및 가정(있는 경우)이 포함됩니다.
#4)테스트 조직
테스트 계획 단계에서 테스트에 대한 모든 가능한 사항을 계획했습니다.
따라서 우리는이 계획을 실행하거나 계획을 성공적으로 만들기 위해 숙련 된 팀원이 필요합니다. 테스트 조직은 성공적인 프로젝트를 위한 완벽한 테스트 팀을 구축하는 것입니다.
#5)테스트 모니터링 및 제어
테스트 작업이 진행 중이거나 테스터가 테스트 계획을 실행하는 동안 이러한 모든 작업 진행 상황을 모니터링해야 합니다. 이 모든 테스트 작업을 추적해야합니다. 테스트 모니터링이 완료되면 테스트 팀 및 테스트 관리자는 테스트 진행 상황에 대한 피드백을 얻을 수 있습니까?
이 피드백을 사용하여 테스트 관리자는 팀 구성원에게 추가 테스트 작업의 품질을 개선하도록 안내 할 수 있습니다. 테스트 모니터링의 도움으로,프로젝트 팀은 테스트 결과에 대한 가시성을 얻을 것이다. 또한 테스트 범위에 대해 알 수 있습니다.
대규모 프로젝트의 경우 데이터 수집이 더 쉽기 때문에 자동화 된 도구를 사용하여 테스트 모니터링을 수행합니다. 소규모 프로젝트의 경우 한 사람이 테스트 진행 상황과 관련된 모든 데이터 또는 문서를 수집합니다. 테스트 진행률 정보를 수집하기 위해 테스트 로그 템플릿의 도움을 받을 수 있습니다. 이것은 모두 테스트 모니터링에 관한 것이 었습니다.
테스트 컨트롤이 무엇인지 보자. 프로젝트 작업은 항상 우리가 계획 한대로 진행되지는 않습니다. 계획과 실제 작업 사이에 약간의 차이가있을 수 있습니다. 이러한 차이를 최소화하거나 제거하려면 몇 가지 변경 사항을 수행해야하며 이것이 테스트 작업을 제어하는 방법입니다.
#6)문제 관리
문제는 소프트웨어 개발 및 테스트 과정에서 발생하는 모든 문제가 될 수 있습니다. 그것은 우리가 품질의 제품을 개발/제공 할 수 없기 때문에 가장 작은 이유가 될 수 있습니다. 일부 문제는 쇼 스토퍼 즉,그 문제를 해결하지 않고 우리는 추가 프로세스를 진행 할 수 없습니다.
문제 관리는 이러한 문제/문제를 처리하는 방법에 관한 것입니다. 우리는 또한 사고 관리로 호출 할 수 있습니다. 문제 관리는 문제를 해결하는 과정에 대한 더 나은 계획이 필요합니다. 더 나은 문제 관리는 테스트 관리자의 기술과 경험에 달려 있습니다.
이러한 문제는 어떻게 발생합니까?
문제가 발생하는 데는 여러 가지 이유가 있을 수 있습니다. 일부 문제는 전략과 관련이 있으며 일부는 정의,인사,스케줄링 등과 관련이 있습니다.
전략 문제:
예:
- 이 프로젝트는 자금이 부족합니다.
- 프로젝트 통신 불량.
- 프로젝트 관리 프로세스는 명시된 기준에 따르지 않습니다.
정의 문제:요구 사항과 관련된 문제입니다.
예:불분명 한 요구 사항. 불분명 한 요구 사항으로 인해 많은 문제가 발생할 수 있습니다.
스케줄링 문제:가장 일반적인 문제 유형입니다. 직원은 마감일을 맞추기 위해 투쟁해야합니다.
인사 문제:
예:
- 팀에 기술이 부족하다.
- 작업에 대한 잘못된 직원 매핑.
더 많은 유형의 문제가있을 수 있으며 여기에서 모두 언급 할 수는 없습니다. 따라서 문제 관리는 로깅,추적 및 문제 해결에 관한 것입니다.
#7)테스트 보고서
테스트 보고서는 테스트 범위,개발 된 제품의 품질 및 필요한 프로세스 개선을 식별하는 데 도움이됩니다. 우리는 얼마나 많은 테스트가 필요한지 결정할 수 있습니다.’
충분한 테스트가 완료되면 이 테스트 보고서를 이해 관계자 또는 고객에게 제출할 수 있습니다. 그래서 그들은 또한 제품의 품질을 알고 제품에 얼마나 많은 테스트를 수행 하는 아이디어를 얻을 것 이다.
테스트 관리 도구
소프트웨어 개발 프로세스를 진행하면서 테스트 관리가 복잡해지며,이것이 오늘날 많은 테스트 관리 도구를 사용할 수 있는 주요 이유 중 하나입니다.
이러한 도구는 테스트 관리 프로세스의 마지막 4 단계(테스트 조직,테스트 모니터링&제어,문제 관리 및 테스트 보고서)에 도움이됩니다. 이러한 도구는 테스트 관리의 중요한 단계에 도움이 되므로 프로젝트에서 먼저 고려해야 합니다.
아래는 가장 인기있는 테스트 관리 도구입니다:2340>
=> 상위 테스트 관리 도구에 대한 자세한 리뷰를 보려면 여기를 클릭하십시오
조직 구조
의 다른 조직 구조를 보자.
조직 구조에 대한 특정 규칙이 있거나 이상적인 구조가있을 수 있지만 관계없이 모든 조직은 구조를 가질 수 있습니다. 이렇게 많은 조직 구조 있고 각자에는 그들의 이점 및 불리가 있는다.
여기서 우리는 그 중 일부를 논의 할 것입니다.
먼저 우리는 작은 프로젝트에 사용되는 가장 간단한 조직 구조를 볼 수 있습니다.
이 구조에서 테스터와 프로그래머 모두 개발 관리자에게보고하고 있습니다.
- 개발 관리자는 프로젝트 활동을 잘 제어 할 수 있습니다.
- 테스트 팀과 개발 팀 간의 커뮤니케이션 격차가 줄어들 것입니다.
- 또한 회의에서는 테스트 및 개발 작업에 대한 완전한 지식을 가지고 있기 때문에 개발 관리자의 마감일을 결정하는 것이 좋습니다.
- 팀워크는 최소한의 계층으로 인해 효율적입니다.
이 구조의 단점은 다음과 같습니다:
- 테스트 관리자가 없기 때문에 테스트가 프로젝트에서 늦게 고려 될 가능성이 있습니다.
- 테스트가 프로젝트에 덜 중요해질 가능성이 있습니다. 그것은 프로젝트에 늦게 간주 될 수 있습니다.
일반적으로 소규모 프로젝트의 소규모 조직에서는 개발 팀이 언급 한 것보다 더 많은 시간이 걸리고 테스트 팀이 어려움을 겪어야합니다.
이 구조에서 프로젝트를 성공적으로 완료하기 위해 개발 관리자는 자신의 목표는 프로젝트를 완료하는 것이 아니라 양질의 소프트웨어를 개발하는 것임을 명심해야합니다.
두 번째로 가장 일반적으로 사용되는 조직 구조:
이것은 가장 일반적인 유형의 조직 구조입니다. 이 구조에서 테스터는 테스트 관리자에게보고하고 개발자는 개발 관리자에게보고하고 있습니다. 테스트 관리자와 개발 관리자 모두 프로젝트 관리자에게 보고하고 있습니다.
테스트 관리자는 모든 테스트 관련 활동에 대한 책임이 있으며 개발 관리자는 소프트웨어를 개발할 책임이 있습니다. 프로젝트 관리자는 테스트 및 개발 활동을 모두 제어합니다.
장점:
- 이전 구조와 달리이 구조에는 테스트 및 개발을위한 다른 관리자가 있으므로 둘 다 작업에 집중할 수 있습니다. 그들은 그들의 일에 전념 할 것이고 그들을 위해 산만 함이 줄어들 것입니다.
- 이 구조에서는 테스트 활동을 소홀히 할 수 없거나 프로젝트에서 늦게 간주 할 수 없습니다. 즉,테스트와 개발 모두 동일한 중요성을 갖습니다.
- 중요한 결정을 내릴 때 테스트 팀은 독립성을 갖습니다.
단점:
- 때문에 여러 수준의 통신 갭의 가능성이있다.
테스트 관리 대 조직 구조
조직 구조는 테스트 관리에 직접적인 영향을 미칩니다. 다른 조직 구조는 테스트 관리에 다른 영향을 미칠,따라서 테스트 관리는 테스트 관리자의 기술과 경험에 따라뿐만 아니라 조직 구조에서 테스트 관리자의 위치에 따라 달라집니다.
우리는 여기서 두 가지 조직 구조를 보았습니다. 첫 번째 구조에서 개발 관리자와 테스트 관리자는 동일한 사람이므로 테스트 관리에 영향을 미칩니다. 개발 관리자는 소프트웨어 개발의 목적을 가지고 있으며,이 일을하는 동안 그/그녀는 테스트 작업뿐만 아니라보고있다.
따라서 때때로 그/그녀는 편향된 의견을 줄 수 있습니다. 그/그녀는 단지 문제를 간과하고 앞으로 나아갈 수 있습니다. 이렇게하면 테스트 관리에 영향을 줄 수 있습니다. 독립적 인 테스트 관리자는 독립적 인 테스트 관리자와 더 나은 것입니다 더 정의와 테스트 관리를 제공 할 수있을 것입니다.
결론
우리는 테스트 관리 및 조직 구조와 같은 주제를 개별적으로 그리고 이들 둘 사이의 관계와 함께 보았다. 조직 구조가 테스트 관리에 영향을 미친다는 결론을 내릴 수 있습니다.
위에서 언급한 두 구조를 비교하는 동안 두 번째 구조에서는 첫 번째 구조보다 테스트 관리가 더 잘 처리됩니다. 그 이유는 전용 테스트 관리자 일 수 있습니다.
조직 구조는 조직마다 다릅니다. 테스트 관리를 위해 정의 된 프로세스가 있지만(또는 팀이 테스트 관리 도구를 사용 중일 수 있음)테스트 관리는 조직 구조,테스트 관리자,테스트 관리자의 기술 및 경험이 다르기 때문에 다릅니다.