test plan tutorial guide write software test plan document from scratch
소프트웨어 테스트 계획 문서에 대한 궁극적 인 가이드 :
이 튜토리얼은 소프트웨어 테스트 계획 문서에 대한 모든 것을 설명하고 처음부터 자세한 소프트웨어 테스트 계획을 작성 / 작성하는 방법을 안내합니다. 테스트 계획과 테스트 실행의 차이점.
라이브 프로젝트 QA 교육 3 일차 – 독자들에게 우리의 라이브 애플리케이션을 소개 한 후 무료 온라인 소프트웨어 테스트 교육 , 우리는 알게되었습니다 SRS를 검토하고 테스트 시나리오를 작성하는 방법 . 이제는 소프트웨어 테스트 수명주기의 가장 중요한 부분, 즉 테스트 계획 .
이 시리즈의 모든 자습서 목록 :
테스트 계획 문서 :
튜토리얼 # 1 : 테스트 계획 문서 작성 방법 (이 튜토리얼)
튜토리얼 # 2 : 간단한 테스트 계획 템플릿 내용
튜토리얼 # 3 : 소프트웨어 테스트 계획 예
튜토리얼 # 4 : 테스트 계획과 테스트 전략의 차이점
튜토리얼 # 5 : 테스트 전략 문서 작성 방법
테스트 계획 팁 :
튜토리얼 # 6 : 테스트 계획 중 위험 관리
튜토리얼 # 7 : 테스트 할 시간이 충분하지 않은 경우 수행 할 작업
튜토리얼 # 8 : 테스트 프로젝트를 효과적으로 계획하고 관리하는 방법
STLC의 여러 단계에서 테스트 계획 :
튜토리얼 # 9 : 회귀 테스트 계획
튜토리얼 # 10 : UAT 테스트 계획
튜토리얼 # 11 : 수락 테스트 계획
테스트 자동화 계획 :
튜토리얼 # 12 : 자동화 테스트 계획
튜토리얼 # 13 : ERP 애플리케이션 테스트 계획
튜토리얼 # 14 : HP ALM 테스트 계획
튜토리얼 # 15 : 마인드 맵 테스트 계획
튜토리얼 # 16 : JMeter 테스트 계획 및 WorkBench
학습 내용 :
토렌트 파일 여는 방법
테스트 계획 생성 – 테스트의 가장 중요한 단계
이 유익한 튜토리얼은 테스트 계획 문서 작성과 관련된 방법과 절차를 설명합니다.
이 튜토리얼의 끝에서 우리는 19 페이지의 포괄적 인 테스트 계획 문서 라이브 프로젝트 OrangeHRM을 위해 특별히 제작되었습니다. QA 교육 시리즈
테스트 계획이란?
테스트 계획은 동적 문서입니다. . 테스트 프로젝트의 성공 여부는 항상 최신의 잘 작성된 테스트 계획 문서에 달려 있습니다. 테스트 계획은 다소 비슷합니다. 테스트 활동이 어떻게 진행되고 있는지에 대한 청사진 프로젝트에서 발생합니다.
다음은 테스트 계획에 대한 몇 가지 지침입니다.
#1) 테스트 계획은 참조 지점 역할을하는 문서이며 해당 테스트를 기반으로 만 QA 팀 내에서 수행됩니다.
#두) 또한 비즈니스 분석가, 프로젝트 관리자, 개발 팀 및 기타 팀과 공유하는 문서입니다. 이는 QA 팀 작업의 외부 팀에 대한 투명성 수준을 향상시키는 데 도움이됩니다.
#삼) QA 팀 구성원의 입력을 기반으로 QA 관리자 / QA 리드가 문서화합니다.
# 4) 테스트 계획은 일반적으로 1/3로 할당됩니다.rd전체 QA 참여에 걸리는 시간입니다. 다른 1/3rd테스트 설계 용이고 나머지는 테스트 실행 용입니다.
# 5) 이 계획은 정적이 아니며 필요에 따라 업데이트됩니다.
# 6) 계획이 더 상세하고 포괄적 일수록 테스트 활동이 더 성공적 일 것입니다.
STLC 프로세스
우리는 이제 라이브 프로젝트 시리즈의 중간에 있습니다. 따라서 애플리케이션에서 한 걸음 물러나 소프트웨어 테스트 수명주기 (STLC) 프로세스를 살펴 보겠습니다.
STLC는 크게 세 부분으로 나눌 수 있습니다.
- 테스트 계획
- 테스트 디자인
- 테스트 실행
이전 튜토리얼에서 실제 QA 프로젝트에서 SRS 검토 및 테스트 시나리오 작성으로 시작했다는 사실을 알게되었습니다. 이는 실제로 STLC 프로세스의 2 단계입니다. 테스트 디자인에는 테스트 대상과 테스트 방법에 대한 세부 정보가 포함됩니다.
테스트 계획을 시작하지 않은 이유는 무엇입니까?
계획은 실제로 모든 테스트 프로젝트에서 발생하는 첫 번째이자 가장 중요한 활동입니다.
SDLC 단계에서 테스트 계획
SDLC 단계 | 테스트 계획 활동 |
---|---|
일정 => | 테스트 시나리오 준비 |
시작 | 이상적으로 QA 팀은 비즈니스 요구 사항의 형태로 고객 / 클라이언트로부터 프로젝트 범위를 수집하는 동안 참여해야합니다. 그러나 현실 세계에서는 그렇지 않습니다. 실용적인 관점에서 QA 팀의 참여는 NIL입니다. 이 단계가 끝나면 BRD가 완료되고 기본 프로젝트 계획이 작성됩니다. |
밝히다 | SRS는 BRD에서 생성됩니다. 테스트 계획의 초기 초안이 생성됩니다. 이 시점에서 QA 팀은 SRS 검토를 완료하지 않았기 때문에 테스트 범위가 명확하지 않습니다. 따라서이 단계의 TP에는 테스트가 발생할시기, 프로젝트 정보 및 팀 정보 (있는 경우)에 대한 정보 만 포함됩니다. |
디자인 | SRS 검토가 수행되고 테스트 범위가 식별됩니다. 우리는 무엇을 테스트할지에 대한 더 많은 정보와 우리가 얻을 수있는 테스트 케이스의 수 등에 대한 좋은 추정치를 가지고 있습니다. 테스트 계획의 두 번째 버전은이 모든 정보를 통합하여 만들어집니다. |
위의 표에서 테스트 계획은 한 번에 모두 만들어서 사용할 수있는 문서가 아님이 분명합니다.
계획 문서의 구성 요소
테스트 계획 템플릿의 항목 | 무엇이 포함되어 있습니까? |
---|---|
범위 => | 검증 될 테스트 시나리오 / 테스트 목표. |
범위 외 => | 다루지 않을 내용에 대한 명확성 향상 |
가정 => | 우리가 성공적으로 진행할 수 있도록 충족해야하는 모든 조건 |
테스트 문서-테스트 케이스 / 테스트 데이터 / 환경 설정 | |
테스트 실행 | |
테스트주기-얼마나 많은주기 | |
주기의 시작 및 종료 날짜 | |
역할 및 책임 => | 팀원이 나열됩니다. |
누가 무엇을 할 것인가 | |
모듈 소유자 및 연락처 정보가 나열됩니다. | |
결과물 => | 어떤 문서 (테스트 아티팩트)가 어떤 시간 프레임에 생성됩니까? |
각 문서에서 무엇을 기대할 수 있습니까? | |
환경 => | 어떤 종류의 환경 요구 사항이 있습니까? |
누가 책임자가 될까요? | |
문제가 발생하면 어떻게해야합니까? | |
도구 => | 예를 들어, 버그 추적을위한 JIRA |
로그인 | |
JIRA를 사용하는 방법? | |
결함 관리 => | 누구에게 결함을보고 할 것인가? |
어떻게보고할까요? | |
예상되는 것은 무엇입니까? 스크린 샷을 제공합니까? | |
위험 및 위험 관리 => | 위험이 나열됩니다. |
위험 분석-가능성 및 영향 문서화 | |
위험 완화 계획을 수립합니다. | |
종료 기준 => | 언제 테스트를 중지해야합니까? |
위에서 언급 한 모든 정보가 가장 중요한 정보이므로 QA 프로젝트의 일상적인 작업 , 계획 문서를 수시로 업데이트하는 것이 중요합니다.
라이브 프로젝트를위한 샘플 테스트 계획 문서
샘플 테스트 계획 템플릿 문서는 ' ORANGEHRM 버전 3.0 – 내 정보 모듈” 프로젝트 및 아래 첨부. 좀 봐주세요. 섹션을 설명하기 위해 문서에 추가 주석이 빨간색으로 추가되었습니다.
이 테스트 계획은 기능 및 UAT 단계 모두에 적용됩니다. 또한 HP ALM 도구를 사용하는 테스트 관리 프로세스에 대해서도 설명합니다.
테스트 계획 샘플 다운로드 :
문서 형식 => 문서 형식으로 테스트 계획을 다운로드하려면 여기를 클릭하십시오. 이것은 우리가 OragngeHRM 라이브 프로젝트를 위해 만든 것이고 우리는 소프트웨어 테스팅 집중 과정에도 이것을 사용하고 있습니다.
PDF 형식 => pdf 파일 형식으로 테스트 계획을 다운로드하려면 여기를 클릭하십시오. .
위의 doc / pdf 버전에서 참조 된 워크 시트 (.xls) 파일 => 다운로드 참조 된 XLS 파일 위의 테스트 계획에서
위의 템플릿은 매우 포괄적이고 상세합니다. 따라서 최상의 결과를 위해 철저히 읽으십시오.
계획이 작성되고 잘 설명되었으므로 SDLC와 STLC의 다음 단계로 넘어가겠습니다.
SDLC의 코드 :
나머지 프로젝트는 TDD 생성에 시간을 할애하는 동안 QA는 테스트 범위 (테스트 시나리오)를 확인하고 신뢰할 수있는 첫 번째 테스트 계획 초안을 작성했습니다. SDLC의 다음 단계는 코딩이 발생하는시기를 확인하는 것입니다.
네트워크 보안 키는 무엇을 의미합니까
개발자는이 단계에서 전체 팀의 주요 초점입니다. QA 팀은 또한 가장 중요한 작업에 빠져 있습니다. “테스트 케이스 생성” .
테스트 시나리오가 '테스트 대상'이면 테스트 케이스는 '테스트 방법'을 다룹니다. 테스트 케이스 생성은 STLC의 테스트 설계 단계에서 가장 중요한 부분입니다. 테스트 케이스 작성 활동에 대한 입력은 테스트 시나리오 및 SRS 문서입니다.
우리와 같은 테스터에게는 테스트 케이스 진짜 거래 야 – 그것은 우리가 대부분의 시간을 보내는 것들입니다. 우리는 그것들을 만들고, 검토하고, 실행하고, 유지하고, 자동화합니다. 우리가 아무리 경험이 많고 프로젝트에서 우리가 어떤 역할을하더라도 테스트 케이스를 가지고 작업 할 것입니다.
테스트 계획 대 테스트 실행
소프트웨어 테스트 계획은 상대적으로 훨씬 더 나은 범위를 예약합니다. STLC 단계 . 품질 소프트웨어의 제공은 테스트 팀에 의해 보장됩니다. 그리고 테스트에서 수행해야하는 작업은 실제로 테스트 계획 단계에서 결정됩니다.
이 섹션에서는 전체 개요를 제공하고 테스트 계획의 중요성과 실행 단계 . 이 글을 읽고 나면 실행 단계와 비교했을 때 계획 단계의 중요성을 이해할 수있을 것입니다. 일러스트레이션에 대한 라이브 예제 및 사례 연구 .
테스트 계획
다음은 계획 중주의해야 할 몇 가지 필수 사항입니다.
테스트 계획은 테스트주기에서 가장 중요한 부분입니다. 테스트 단계의 결과는 테스트를 위해 수행 된 계획의 품질과 범위에 따라 결정됩니다.
테스트 계획은 일반적으로 모든 관련 당사자의 상호 합의에 따라 테스트 실행 리드 타임을 절약하기 위해 개발 단계에서 발생합니다.
주목해야 할 몇 가지 중요한 사실은 다음과 같습니다.
- 요구 사항이 동결 된 경우 계획은 개발과 병행하여 시작해야합니다.
- 설계자, 개발자, 클라이언트 및 테스터와 같은 모든 이해 관계자가 계획을 완료하는 동안 참여해야합니다.
- 확인되지 않았거나 승인되지 않은 비즈니스 요구에 대해서는 계획을 수립 할 수 없습니다.
- 유사한 테스트 계획이 비즈니스에 필요한 새로운 요구 사항에 적용될 것입니다.
예 1
개발 팀은 클라이언트로부터 몇 가지 요구 사항을받은 후 소프트웨어 XYZ를 작업하고 있습니다. 테스트 팀은 테스트 정의 또는 계획 단계에 대한 준비를 거의 시작했습니다. 테스트 계획은 클라이언트가 인용 한 초기 요구 사항을 해결하도록 설계되어야합니다. 이것은 테스트 팀에 의해 수행되었습니다.
이 단계에는 다른 이해 관계자가 관여하지 않았으며 계획이 동결되었습니다.
이제 개발 팀은 클라이언트의 승인을 받아 작업의 몇 가지 문제를 해결하기 위해 비즈니스 흐름을 일부 변경했습니다. 이제 소프트웨어가 테스트를 위해 테스트 팀에 왔습니다. 이전 비즈니스 흐름에 따른 테스트 계획으로 테스트 팀은 테스트 라운드를 시작했습니다. 이것은 수정 된 비즈니스 흐름이 테스트 팀과 공유되지 않았기 때문에 많은 지연과 함께 테스트 결과물에 영향을 미쳤습니다.
예 1의 관찰 :
위의 예에서 특정 관찰이 있습니다.
그들은:
- 새로운 비즈니스 흐름을 이해하는 데 많은 시간이 소요되었습니다.
- 프로젝트 결과물의 지연.
- 계획 및 단계의 다른 작업에 대한 재 작업.
이러한 모든 관찰은 효과적인 테스트 결과물을위한 필수 요구 사항으로 변환되어야합니다.
계획 단계의 주요 구성 요소
다음은 계획 단계에 관련된 주요 구성 요소입니다.
- 테스트 전략 : 이것은 테스트하는 동안 사용될 전략을 설명 할 수있는 가장 중요한 섹션 중 하나입니다.
- 테스트 범위 : 이것은 본질적으로 필수이며 전체 소프트웨어가 테스트되었는지 여부를 확인할 수 있도록 비즈니스 요구와 테스트 케이스의 적합성 매핑을 수행합니다.
- 테스트주기 및 기간 : 이것은 개발 라운드와 각 라운드를 완료하는 데 걸리는 시간에 따라 매우 중요해질 수 있습니다.
- 합격 / 불합격 기준 : 합격 및 불합격 기준이 정의 된 필수 항목입니다. 이것은 또한 클라이언트에 의해 몇 번 정의됩니다.
- 비즈니스 및 기술 요구 사항 : 소프트웨어의 필요성과 그들이 제공하는 목적은 낮은 수준의 설명과 함께 명확하게 정의됩니다.
한계
소프트웨어 테스트 단계, 특히 계획 단계를 실제로 제어 할 수있는 것은 거의 없습니다.
다음은 그러한 몇 가지 영역입니다.
- 테스트 할 기능과 테스트하지 않을 기능 : 이것은 무엇을 테스트해야하고 무엇을하지 말아야하는지 명확하게 지적 할 것입니다.
- 정지 기준 및 재개 요건 : 이것은 개발 된 소프트웨어에 대한 의사 결정자이며 테스트를 일시 중단하거나 테스트를 재개하기 위해 정의 된 기준입니다.
- 책임: 테스터는 테스트중인 소프트웨어의 문제, 버그 및 결함을 확인하는 데 여러 책임이 있습니다. 또한 버그를 수정하려면 개발자와 함께 유효성을 검사해야합니다.
- 위험 및 우발 사항 : 테스트 중 관련된 위험을 명확하게 언급하고 해당 기간 동안 적절한 우발 상황을 매우 명확하게 정의해야합니다.
사례 연구 # 1
포트 트리거링 vs. 포트 포워딩
개발팀 예 1 XYZ 소프트웨어를 2 단계로 출시 할 계획입니다. 1 단계에는 테스트 할 기능이 많고 테스트하지 않을 기능은 거의 없습니다. 다시 테스트 팀에 아직 개발되지 않은 기능에 대한 정보를 제공하지 않고 테스트를 위해 소프트웨어가 릴리스되었습니다.
이제 테스트 팀은 이미 작업 한 테스트 계획에 따라 실행을 시작합니다. 그들은 많은 수의 버그를 가지고 있습니다. 그리고 개발 팀의 확인 후 대부분 무효화됩니다.
위 사례 연구의 관찰 :
- 릴리스 정보 및 요구 사항 커버리지 정보 (릴리스 정보)와 함께 소프트웨어를 테스트 팀에 릴리스하는 개발 팀.
- 테스트 할 기능과 테스트하지 않을 기능은 테스트하기 전에 출시 된 소프트웨어를 기준으로 요소를 고려해야합니다.
- 테스트를위한 일시 중지 및 재개 기준은 적절하게 정의되어야합니다.
- 소프트웨어의 비 가용성에 대한 위험 및 비상 계획을 완벽하게 파악해야합니다.
또한 읽으십시오=> 테스트 계획 단계에서 위험을 관리하는 방법
테스트 실행 계획
테스트 케이스의 실행은 STLC 단계의 단계 중 하나입니다. 이것은 이전에 계획된 계획에 따라 수행되어야합니다. 따라서 계획은 항상 전체 테스트 단계를 지배합니다. 다음은 테스트 계획의 변경으로 인해 테스트 팀이 영향을받는 예입니다.
예제 # 2
소프트웨어 A 테스트는 팀에서 계획 한 1을 기반으로 시작되었습니다. 나중에 비즈니스 요구 사항과 변경 사항으로 인해 테스트 계획에 약간의 변경이 필요했습니다. 이로 인해 테스트 케이스 또는 실행이 변경되었습니다.
관찰 :
- 테스트 계획은 테스트 케이스 실행을 결정합니다.
- 실행 부분은 계획에 따라 다릅니다.
- 계획과 요구 사항이 유효한 한 테스트 케이스도 유효합니다.
실행 중 문제를 극복하는 방법
테스터는 테스트 실행을 수행하는 동안 더 자주 다양한 시나리오를 접하게됩니다. 이것은 테스터가 문제를 해결하는 방법을 이해하고 알고 있거나 적어도 문제에 대한 해결 방법을 찾아야 할 때입니다.
예 # 3
소프트웨어 B의 테스트 케이스 실행 중에 테스트 팀은 여러 문제에 직면합니다. 그들 중 일부는 쇼 스토퍼입니다. 개발자가 문제를 극복하도록 도와야합니다. 이것은 여러 번 발생했으며 그 결과 결과물 테스트가 지연되었습니다.
관찰 :
- 환경 문제와 문제를 극복하기위한 의존성이 있습니다.
- 테스터는 환경에 대한 적절한 이해가 필요합니다.
- 자주 발생하는 문제와 알려진 문제를 문서화하여 향후 문제를 해결해야합니다.
버전 제어 및 관리
버전 제어 적시에 결과물을 보여주기 위해서는 테스트 계획과 테스트 케이스의 관리가 정말 중요합니다. 이것은 더 중요하며 종종 버전 관리 도구의 도움으로 수행됩니다.
버전 제어 도구는 테스트 계획을 제어하는 데 도움이 될뿐만 아니라 결함 관리도 지원합니다. 여러주기와 릴리스가있는 테스트 프로젝트가있는 경우 이러한 도구는 테스트 결과물을 지원하기위한 메트릭을 낮추는 데 많은 도움이 될 수 있습니다.
또한 읽기=> 테스트 실행 단계에서 위험 관리
테스트 계획과 테스트 실행의 차이점
다음은 계획이 테스트 실행 단계와 어떻게 다른지 보여주는 몇 가지 중요한 영역입니다.
비교 영역 | 테스트 계획 | 테스트 실행 |
---|---|---|
제공 가능한 포지셔닝 | 테스트 계획은 테스트 활동에 대한 주요 결과물로 간주됩니다. 이것은 테스트 프로세스의 첫 번째 단계로 수행됩니다. | 이것은 테스트 단계의 마지막 벤치 멤버로 올 것입니다. 실행 후 테스트 케이스 실행 상태와 함께 결함 / 버그 상태가 테스트 결과물 중 하나로 공유됩니다. |
책임있는 사람 | 테스트 관리자는 테스트 계획을 준비하고 검토를 위해 모든 이해 관계자들에게 공유 할 것입니다. | 이 작업은 일반적으로 준비된 테스트 케이스가 승인되고 서명되었음을 염두에두고 테스터가 수행합니다. |
주요 초점 | 테스트 계획의 초점 영역은 테스트 수행 방법, 고려해야 할 사항 및 고려 사항, 사용할 수있는 환경, 테스트 일정 등입니다. | 테스트 실행은 주로 소프트웨어에서 테스트하기 위해 제공된 테스트 케이스의 실행에 중점을 둡니다. |
반복 또는 반복 모드 | 이것은 일회성 활동입니다. 소프트웨어의 향후 릴리스를 위해 수정이 필요할 수도 있고 필요하지 않을 수도 있습니다. | 반복에 대해 이야기 할 때이 영역에는 세 부분이 있습니다. 1. 기능 테스트. 2. 회귀 테스트. 3. 재시험. |
입력 | 테스트 계획 작성을위한 입력은 실제로 필요하며 비즈니스 분석가, 설계자, 클라이언트 등이 제공해야합니다. | 테스트 케이스 문서는 주요 입력입니다. |
시작할 수있는 기간 | 효과적인 결과를 얻고 시간을 절약하려면 개발주기와 함께 시작해야합니다. 그러나 낙수 모델과 같은 모델은 개발 단계가 완료된 후에 만 테스트 단계가 시작됩니다. | 실행은 소프트웨어 개발이 완료된 후에 엄격하게 시작되어야합니다. |
폐쇄 기간 | 테스트 계획에는 그러한 마감 기간이 없습니다. 일반적으로 소프트웨어에 대한 모든 이해 당사자의 승인이 제공됩니다. | 특정 릴리스 또는주기에 대한 실행은 모든 테스트 케이스가 소프트웨어에 대해 실행 된 경우 종료 된 것으로 간주됩니다. |
도구 사용법 | 계획 활동이 더 많은 논의와 문서화가 될 것이므로 많은 도구가 사용되지 않을 것입니다. 계획의 변경 사항을 추적하기 위해 테스트 관리자는 일반적으로 VSS 또는 다른 것과 같은 버전 제어 도구를 사용합니다. | 실행 모드에 따라 다릅니다. 수동의 경우 도구가 실행에 사용되지 않습니다. 그러나 결함을 기록하고 관리하기 위해 일부 도구가 사용됩니다. 자동화 테스트의 경우 QTP, SELENIUM 등과 같은 도구를 사용하여 실행됩니다. |
결과물에 미치는 영향 | 이는 모든 테스트 단계에 더 큰 영향을 미칩니다. | 이는 테스트 할 후속주기 또는 릴리스에 영향을줍니다. |
위의 그림은 테스트 실행보다 테스트 계획 활동의 중요성을 더 잘 설명했을 수 있습니다. 어떤 의미에서 실행 단계는 테스트 계획의 일부입니다.
테스트 전략, 접근 방식 및 기타 사항을 기반으로 테스트 계획이 변경 될 여지를 제공하기 위해 수정 될 가능성이 더 높습니다. 테스트 실행이 테스트 케이스에 의존한다는 것은 확실한 것입니다. 테스트 케이스는 계획을 기반으로합니다. 따라서 계획의 변경은 테스트 케이스의 변경을 보장합니다.
그러나 반대로 테스트 케이스의 변경 사항은 반드시 변경 사항을 찾을 필요가 없습니다. 이것이 테스트 실행 단계에 비해 계획이 유지되는 주된 이유 중 하나입니다.
다가오는 자습서에서 테스트 사례를 만드는 방법에 대해 자세히 설명 할 것입니다. 그들은 무엇인가? 그리고 테스트 케이스와 관련된 다양한 다른 측면과 함께 어떻게 우리를 위해 작동하도록 할 수 있는지.
NEXT 튜토리얼=> QA 교육 일 -4 : SRS 문서에서 테스트 케이스 작성
테스트 계획 문서 작성의 전문가입니까? 그러면 다가오는 테스터를위한 개선을위한 귀중한 팁을 공유 할 수있는 올바른 장소입니다. 아래 댓글란에 자유롭게 의견을 남겨주세요 !!