테스트 계획 - 소프트웨어 테스팅

테스트 계획은 소프트웨어 테스트 영역과 활동을 설명하는 자세한 문서입니다. 여기에는 테스트 전략, 목표, 테스트 일정, 필요한 리소스(인적 자원, 소프트웨어 및 하드웨어), 테스트 추정 및 테스트 결과물이 간략하게 설명되어 있습니다.

테스트 계획은 모든 소프트웨어 테스트의 기초입니다. 이는 계획된 활동의 모든 목록을 적절한 순서로 가용성을 보장하는 가장 중요한 활동입니다.

테스트 계획은 테스트 관리자가 완전히 모니터링하고 제어하는 정의된 프로세스로 소프트웨어 테스트 활동을 수행하기 위한 템플릿입니다. 테스트 계획은 테스트 리드(60%), 테스트 관리자(20%) 및 테스트 엔지니어(20%)가 준비합니다.

문자를 문자열로 변환 자바

테스트 계획 유형

테스트 계획에는 세 가지 유형이 있습니다.

마스터 테스트 계획
단계 테스트 계획
테스트 유형별 테스트 계획

마스터 테스트 계획

마스터 테스트 계획은 여러 수준의 테스트를 포함하는 일종의 테스트 계획입니다. 여기에는 완전한 테스트 전략이 포함됩니다.

단계 테스트 계획

단계 테스트 계획은 테스트 전략의 한 단계를 다루는 테스트 계획 유형입니다. 예를 들어 도구 목록, 테스트 사례 목록 등이 있습니다.

특정 테스트 계획

보안 테스트, 로드 테스트, 성능 테스트 등과 같은 주요 유형의 테스트를 위해 설계된 특정 테스트 계획. 즉, 비기능 테스트를 위해 설계된 특정 테스트 계획입니다.

테스트 계획을 작성하는 방법

테스트 계획을 세우는 것은 테스트 관리 프로세스에서 가장 중요한 작업입니다. IEEE 829에 따라 다음 7단계에 따라 테스트 계획을 준비하십시오.

먼저 제품 구조와 아키텍처를 분석합니다.
이제 테스트 전략을 설계하십시오.
모든 테스트 목표를 정의합니다.
테스트 영역을 정의합니다.
사용 가능한 모든 리소스를 정의합니다.
모든 활동을 적절한 방식으로 계획하십시오.
모든 테스트 결과물을 결정합니다.

테스트 계획 구성요소 또는 속성

테스트 계획은 전체 테스트 활동을 도출하는 데 도움이 되는 다양한 부분으로 구성됩니다.

목표: 애플리케이션의 목적을 나타내는 모듈, 기능, 테스트 데이터 등에 대한 정보로 구성되며 이는 애플리케이션의 동작, 목표 등을 의미합니다.

범위: 여기에는 각 응용 프로그램에서 테스트해야 하는 정보가 포함되어 있습니다. 범위는 다음 두 부분으로 더 나눌 수 있습니다.

범위 내
범위 밖

범위 내: 이는 엄격하게(자세히) 테스트해야 하는 모듈입니다.

범위 밖: 이는 엄격하게 테스트할 필요가 없는 모듈입니다.

예를 들어 , 테스트할 Gmail 애플리케이션이 있다고 가정합니다. 테스트할 기능 ~와 같은 메일 작성, 보낸 편지함, 받은 편지함, 임시 보관함 그리고 테스트되지 않은 기능 ~와 같은 돕다 , 등등 이는 계획 단계에서 제품에 주어진 시간 제한에 따라 어떤 기능을 확인해야 할지 여부를 결정한다는 것을 의미합니다.

지금 테스트하지 않을 기능을 어떻게 결정합니까?

테스트하지 않을 기능을 결정할 수 있는 측면은 다음과 같습니다.

위에서 보듯이 돕다 기능은 기술 작성자가 작성 및 개발하고 다른 전문 작성자가 검토하므로 테스트되지 않습니다.
다음과 같은 애플리케이션이 하나 있다고 가정해 보겠습니다. P, Q, R, S 요구사항에 따라 개발해야 하는 기능입니다. 하지만 여기서 S 기능은 이미 다른 회사에서 설계하여 사용하고 있습니다. 그래서 개발팀은 그 회사로부터 S를 구입해 P, Q, R 등 추가 기능을 통합할 예정이다.

이제 S 기능은 이미 실시간으로 사용되었기 때문에 기능 테스트를 진행하지 않겠습니다. 그러나 아래 이미지에서 볼 수 있듯이 새로운 기능이 S 기능과 올바르게 작동하지 않을 수 있으므로 P, Q, R 및 S 기능 간의 통합 테스트 및 시스템 테스트를 수행합니다.

제품의 첫 번째 릴리스에서 다음과 같이 개발된 요소가 있다고 가정해 보겠습니다. P, Q, R, S, T, U, V, W…..X, Y, Z . 이제 클라이언트는 두 번째 릴리스에서 제품을 개선하는 새로운 기능에 대한 요구 사항을 제공하며 새로운 기능은 다음과 같습니다. A1, B2, C3, D4, E5.

그 후 테스트 계획 중 범위를 다음과 같이 작성합니다.

범위

테스트할 기능

A1, B2, C3, D4, E5(새로운 기능)

피, Q, R, 에스, 티

테스트할 수 없는 기능

W…..X, Y, Z

따라서 새로운 기능을 먼저 확인한 다음 이전 기능을 계속 사용할 것입니다. 새로운 기능을 추가한 후에 영향을 받을 수 있기 때문입니다. 즉, 영향 영역에도 영향을 미치게 되므로 P, Q에 대해 1회 회귀 테스트를 수행합니다. , R…, T 기능.

테스트 방법:

여기에는 애플리케이션에서 기능 테스트, 통합 테스트, 시스템 테스트 등과 같은 다양한 종류의 테스트를 수행하는 방법에 대한 정보가 포함되어 있습니다. 여기서는 어떤 유형의 테스트를 할지 결정할 것입니다. 우리는 애플리케이션 요구 사항에 따라 다양한 기능을 수행합니다. 그리고 여기서는 테스트 용어가 표준이 아니기 때문에 경영진, 개발팀, 테스트팀 등 모두가 쉽게 이해할 수 있도록 테스트 방법론에서 어떤 종류의 테스트를 사용할 것인지 정의해야 합니다.

예를 들어, 다음과 같은 독립형 애플리케이션의 경우 어도비 포토샵 , 다음 유형의 테스트를 수행합니다.

스모크 테스트→ 기능 테스트 → 통합 테스트 → 시스템 테스트 → 임시 테스트 → 호환성 테스트 → 회귀 테스트→ 세계화 테스트 → 접근성 테스트 → 사용성 테스트 → 신뢰성 테스트 → 복구 테스트 → 설치 또는 제거 테스트

그리고 우리가 https://www.jeevansathi.com/ 응용 프로그램이므로 다음 유형의 테스트를 수행합니다.

연기 테스트	기능 테스트	통합 테스트
시스템 테스트	임시 테스트	호환성 테스트
회귀 테스트	세계화 테스트	접근성 테스트
유용성 테스트	성능 시험

접근하다

이 속성은 테스트를 수행하는 동안 애플리케이션의 흐름을 설명하고 향후 참조를 위해 사용됩니다.

우리는 아래 측면의 도움으로 애플리케이션의 흐름을 이해할 수 있습니다.

높은 수준의 시나리오를 작성하여 흐름 그래프를 작성하여

높은 수준의 시나리오를 작성하여

예를 들어 , 우리가 지메일 애플리케이션:

Gmail에 로그인 - 이메일을 보내고 보낸 편지함 페이지에 있는지 확인하세요.
에 로그인 ......
……
......

우리는 제품을 테스트하고 높은 수준의 시나리오를 작성할 중요한 기능에 대해서만 취해야 하는 접근 방식을 설명하기 위해 이 글을 쓰고 있습니다. 어떤 기능을 테스트해야 하는지 여부는 특정 테스트 엔지니어가 결정할 수 있으므로 여기서는 모든 시나리오를 다루는 데 집중하지 않을 것입니다.

흐름 그래프를 작성하여

아래 이미지에서 볼 수 있듯이 상위 수준 시나리오를 작성하는 데는 약간의 시간이 소요되기 때문에 흐름 그래프가 작성됩니다.

우리는 다음과 같은 이점을 얻기 위해 흐름 그래프를 만들고 있습니다.

취재가 용이하다
병합은 쉽습니다

접근 방식은 다음과 같이 두 부분으로 분류될 수 있습니다.

위에서 아래로 접근
아래에서 위로 접근

추정

여기에는 테스트 과정에서 발생할 수 있는 문제에 대한 정보가 포함되어 있으며 테스트 계획을 작성할 때 리소스 및 기술 등과 같은 확실한 가정이 이루어집니다.

위험

이는 현재 릴리스에서 애플리케이션을 테스트하기 위해 직면해야 하는 과제이며, 가정이 실패하면 위험이 따릅니다.

예를 들어, 애플리케이션의 효과로 인해 출시일이 연기됩니다.

완화 계획 또는 비상 계획

위험이나 문제를 극복하기 위해 준비한 백업 계획입니다.

가정, 위험 및 비상 계획은 서로 상호 관련되어 있으므로 함께 한 가지 예를 살펴보겠습니다.

어느 제품이든, 추정 우리는 제품이 완성될 때까지 3명의 테스트 엔지니어가 모두 거기에 있고 그들 각각에게 P, Q, R과 같은 서로 다른 모듈이 할당되도록 할 것입니다. 이 특정 시나리오에서는 위험 테스트 엔지니어가 프로젝트 도중에 떠났다면 그럴 수도 있습니다.

그러므로, 비상 계획 각 기능에 기본 소유자와 하위 소유자가 할당됩니다. 따라서 한 테스트 엔지니어가 떠나면 하위 소유자가 해당 특정 기능을 인수하고 새로운 테스트 엔지니어도 도와주므로 해당 엔지니어가 할당된 모듈을 이해할 수 있습니다.

가정, 위험, 완화 또는 비상 계획은 항상 제품 자체에 정확합니다. 다양한 유형의 위험은 다음과 같습니다.

고객 관점
자원 접근 방식
기술적 의견

역할과 책임

이는 전체 테스트 팀이 수행해야 하는 전체 작업을 정의합니다. 큰 프로젝트가 나오면 테스트 관리자 테스트 계획을 작성하는 사람입니다. 3-4개의 소규모 프로젝트가 있는 경우 테스트 관리자는 각 프로젝트를 각 테스트 리드에 할당합니다. 그리고 테스트 리드는 자신에게 할당된 프로젝트에 대한 테스트 계획을 작성합니다.

테스트 관리자, 테스트 리드 및 테스트 엔지니어의 역할과 책임을 이해하는 한 가지 예를 살펴보겠습니다.

역할: 테스트 관리자

이름: 라이언

책임:

테스트 계획 준비(작성 및 검토)
개발팀과 회의 진행
테스트 팀과 회의 진행
고객과의 미팅을 진행합니다
월 1회 스탠드업 미팅 실시
로그아웃 릴리스 노트
에스컬레이션 및 문제 처리

역할: 테스트 리드

이름: 하비

책임:

테스트 계획 준비(작성 및 검토)
매일 스탠드업 미팅 실시
테스트 케이스 검토 및 승인
RTM 및 보고서 준비
모듈 할당
처리일정

역할: 테스트 엔지니어 1, 테스트 엔지니어 2 및 테스트 엔지니어 3

이름: 루이스, 제시카, 도나

모듈 할당: M1, M2 및 M3

책임:

테스트 케이스와 테스트 시나리오로 구성된 테스트 문서를 작성, 검토, 실행합니다.
요구 사항을 읽고, 검토하고, 이해하고 분석합니다.
애플리케이션의 흐름을 작성하세요.
테스트 케이스 실행
각 모듈에 대한 RTM
결함 추적
테스트 실행 보고서를 준비하고 이를 테스트 리드에게 전달합니다.

일정

작업 타이밍을 설명하는 데 사용됩니다. 수행해야 하는 작업 또는 이 속성은 각 테스트 활동이 정확히 언제 시작되고 종료되어야 하는지를 다룹니다. 그리고 특정 날짜의 모든 테스트 활동에 대한 정확한 데이터도 언급됩니다.

따라서 아래 이미지에서 볼 수 있듯이 특정 활동에는 시작 날짜와 종료 날짜가 있습니다. 특정 빌드에 대한 각 테스트에는 지정된 날짜가 있습니다.

예를 들어

테스트 케이스 작성
실행과정

결함 추적

각 버그의 상태를 수동으로 추적할 수 없기 때문에 일반적으로 도구를 사용하여 수행됩니다. 그리고 테스트 과정에서 발견된 버그에 대해 어떻게 소통하고 이를 개발팀에 다시 보내는지, 그리고 개발팀에서는 어떻게 답변할지에 대해서도 언급합니다. 여기서는 높음, 중간, 낮음과 같은 버그의 우선순위도 언급합니다.

다음은 결함 추적의 다양한 측면입니다.

차단제 또는 쇼스토퍼

예를 들어

비판적인

주요한

미성년자

높은 P1

중간-P2

낮은 P3

따라서 높음, 중간, 낮음과 같은 버그의 우선순위에 따라 P1, P2, P3, P4로 분류합니다.

내 모니터 크기 어떻게 알아?

테스트 환경

이는 애플리케이션을 테스트할 환경이며 여기에는 두 가지 유형의 환경이 있습니다. 소프트웨어 그리고 하드웨어 구성.

그만큼 소프트웨어 구성 다양한 세부정보를 의미합니다. 운영체제 ~와 같은 윈도우, 리눅스, 유닉스, 맥 그리고 다양한 브라우저 좋다 구글 크롬, 파이어폭스, 오페라, 인터넷 익스플로러 , 등등.

그리고 하드웨어 구성 다양한 크기에 대한 정보를 의미합니다. RAM, ROM 및 프로세서 .

예를 들어

그만큼 소프트웨어 다음이 포함됩니다:

섬기는 사람

운영 체제	리눅스
웹 서버	아파치 톰캣
애플리케이션 서버	웹스피어
데이터베이스 서버	Oracle 또는 MS-SQL 서버

참고: 위 서버는 테스트 팀에서 애플리케이션을 테스트하는 데 사용하는 서버입니다.

고객

운영 체제	윈도우 XP, 비스타 7
브라우저	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 및 Internet Explorer 8

참고: 위의 세부 정보는 테스트 팀이 애플리케이션을 테스트할 다양한 운영 체제와 브라우저를 제공합니다.

그만큼 하드웨어 다음이 포함됩니다:

섬기는 사람 : 썬 스타캣 1500

이 특정 서버는 테스트 팀에서 애플리케이션을 테스트하는 데 사용할 수 있습니다.

고객:

다음과 같은 구성을 가지고 있습니다.

프로세서	내부2GHz
램	2GB
….	….

참고: 테스트 팀인 테스트 엔지니어의 시스템 구성을 제공합니다.

개발팀은 소프트웨어 설치 방법에 대한 구성을 제공합니다. 개발팀이 아직 프로세스를 제공하지 않을 경우 테스트 계획에 이를 작업 기반 개발(TBD)로 작성할 것입니다.

진입 및 퇴출 기준

이는 테스트 프로세스를 시작하고 중지하기 전에 충족되어야 하는 필요 조건입니다.

입학기준

참가 기준에는 다음 조건이 포함됩니다.

화이트박스 테스트가 완료되어야 합니다.
요구사항을 이해하고 분석하여 테스트 문서를 준비하거나 테스트 문서가 준비되면
테스트 데이터가 준비되어 있어야 합니다.
빌드 또는 애플리케이션을 준비해야 합니다.
모듈이나 기능은 다른 테스트 엔지니어에게 할당되어야 합니다.
필요한 리소스가 준비되어 있어야 합니다.

종료 기준

종료 기준에는 다음 조건이 포함됩니다.

모든 테스트 케이스가 실행될 때.
대부분의 테스트 케이스는 다음과 같아야 합니다. 합격 .
버그의 심각도에 따라 다릅니다. 즉, 방해 요소나 주요 버그가 없어야 하지만 일부 사소한 버그는 존재합니다.

기능 테스트를 시작하기 전에 위의 모든 사항을 입학기준 따라야합니다. 기능 테스트를 수행한 후 통합 테스트를 수행하기 전에 종료 기준 기능 테스트는 종료 기준의 %가 개발 및 테스트 관리자와의 회의에 의해 결정되기 때문에 따라야 합니다. 왜냐하면 그들의 협력이 백분율을 달성할 수 있기 때문입니다. 그러나 기능 테스트의 종료 기준을 따르지 않으면 더 이상 통합 테스트를 진행할 수 없습니다.

여기 심각도에 따라 버그가 있다는 것은 테스트 팀이 다음 단계를 더 진행하기로 결정했다는 것을 의미합니다.

테스트 자동화

이를 통해 우리는 다음을 결정할 것입니다.

자동화되어야 하는 기능과 자동화되어서는 안 되는 기능은 무엇입니까?
어떤 자동화 프레임워크에서 어떤 테스트 자동화 도구를 사용할 예정입니까?

우리는 첫 번째 릴리스 이후에만 테스트 사례를 자동화합니다.

여기서 어떤 근거로 그런 질문이 발생합니까? 우리 ~ 할 것이다 어떤 기능을 테스트해야 할지 결정하시겠습니까?

위 이미지에서 볼 수 있듯이 가장 일반적으로 사용되는 기능은 계속해서 테스트해야 합니다. 필수 기능이 있는 Gmail 애플리케이션을 확인해야 한다고 가정해 보겠습니다. 메일, 보낸 편지함, 받은 편지함 작성 . 수동으로 테스트를 진행하다 보면 시간이 더 걸리고 단조로운 작업이 되기 때문에 이러한 기능을 테스트해보겠습니다.

지금, 테스트하지 않을 기능을 어떻게 결정하나요?

가정하다 도움 Gmail 애플리케이션의 기능은 정기적으로 사용되지 않기 때문에 반복적으로 테스트하지 않으므로 자주 확인할 필요가 없습니다.

하지만 일부 기능이 불안정하고 버그가 많은 경우 , 이는 수동 테스트를 수행하는 동안 계속해서 테스트해야 하기 때문에 해당 기능을 테스트하지 않는다는 의미입니다.

만약에 자주 테스트해야 하는 기능이 있습니다 , 그러나 해당 기능에 대한 요구사항 변경이 예상되어 자동화 테스트 스크립트를 변경하는 것보다 수동 테스트 케이스를 변경하는 것이 더 편하기 때문에 확인하지 않습니다.

노력 추정

이를 통해 우리는 모든 팀원이 적용해야 할 노력을 계획할 것입니다.

테스트 결과물

이것은 우리가 제품과 함께 고객에게 전달한 테스트 팀의 결과물인 문서입니다. 여기에는 다음이 포함됩니다.

테스트 계획 테스트 케이스 테스트 스크립트 RTM(요구사항 추적성 매트릭스) 결함 보고서 테스트 실행 보고서 그래프 및 측정항목 릴리즈 노트

그래프 및 측정항목

그래프

이번 시간에는 종류에 대해 알아보겠습니다. 그래프 보내드리고, 각 그래프의 샘플도 제공해 드리겠습니다.

보시다시피 테스트 프로세스의 다양한 측면을 보여주는 5가지 그래프가 있습니다.

그래프1: 여기에서는 모든 모듈에서 얼마나 많은 결함이 식별되었으며 얼마나 많은 결함이 수정되었는지 보여줍니다.

그래프 2: 그림 1은 모든 모듈에서 식별된 중요, 주요 및 사소한 결함 수와 해당 모듈에서 수정된 결함 수를 보여줍니다.

그래프3: 이 특정 그래프에서 우리는 현명한 그래프 구축 이는 모든 빌드에서 모든 모듈에 대해 얼마나 많은 결함이 식별되고 수정되었는지를 의미합니다. 모듈을 기반으로 버그를 확인했습니다. 우리는 추가할 것이다 아르 자형 P와 Q의 결점 수를 표시하고 다음도 추가합니다. 에스 P, Q, R의 결함을 표시합니다.

그래프4: 테스트 리드는 다음을 설계합니다. 버그 동향 분석 매달 생성된 그래프를 경영진에게 전송합니다. 그리고 그것은 제품의 마지막에 이루어지는 예측과 같습니다. 여기서도 할 수 있습니다. 버그 수정을 평가해 주세요 우리가 그것을 관찰할 수 있듯이 호 가지고있다 상향 아래 이미지에서.

그래프5: 그만큼 테스트 관리자 이런 종류의 그래프를 디자인했습니다. 이 그래프는 버그 평가의 격차와 실제 발생한 버그를 이해하기 위한 것이며, 향후 버그 평가 개선에도 도움이 됩니다.

측정항목

위와 같이 그림 1과 같은 버그 분포 그래프를 생성하고 위에서 언급한 데이터의 도움을 받아 메트릭도 디자인합니다.

예를 들어

위 그림에서 우리는 특정 프로젝트의 모든 테스트 엔지니어의 기록과 식별 및 수정된 결함 수를 유지합니다. 또한 향후 분석을 위해 이 데이터를 사용할 수도 있습니다. 새로운 요구 사항이 생기면 위의 측정 기준에 따라 이전에 발견한 결함 수를 기반으로 테스트를 위한 까다로운 기능을 제공할 사람을 결정할 수 있습니다. 그리고 우리는 누가 문제가 있는 기능을 잘 처리하고 최대 결함 수를 찾을 수 있는지 더 나은 상황에 놓이게 될 것입니다.

릴리스 노트: 제품 출시 시 작성되어 테스트 매니저의 서명이 있는 문서입니다.

아래 이미지에서는 최종 제품이 개발되어 고객에게 배포되는 것을 볼 수 있으며, 최신 릴리스 이름은 다음과 같습니다. 베타 .

그만큼 릴리스 노트 다음으로 구성됩니다:

리눅스 변경 파일

사용자 매뉴얼.
보류 중인 결함 및 미결 결함 목록입니다.
추가, 수정, 삭제된 기능 목록입니다.
제품이 테스트되는 플랫폼(운영 체제, 하드웨어, 브라우저) 목록입니다.
제품이 테스트되지 않은 플랫폼입니다.
현재 릴리스에서 수정된 버그 목록과 이전 릴리스에서 수정된 버그 목록입니다.
설치 과정
소프트웨어 버전

예를 들어

한다고 가정 베타 첫 번째 릴리스에 이어 두 번째 응용 프로그램 릴리스입니다. 알파 공개되었다. 첫 번째 릴리스에서 일부 결함이 확인되어 이후 릴리스에서 수정되었습니다. 그리고 여기서는 알파 릴리즈부터 베타 릴리즈까지 새롭게 추가, 수정, 삭제된 기능 목록도 짚어보겠습니다.

주형

이 부분에는 제품에 사용될 문서에 대한 모든 템플릿이 포함되어 있으며 모든 테스트 엔지니어는 제품의 일관성을 유지하기 위해 프로젝트에서 이러한 템플릿만 사용합니다. 여기에는 다음과 같이 전체 테스트 프로세스 중에 사용되는 다양한 유형의 템플릿이 있습니다.

테스트 케이스 템플릿
테스트 사례 검토 템플릿
RTM 템플릿
버그 보고서 템플릿
테스트 실행 보고서

테스트 계획 문서의 샘플을 하나 살펴보겠습니다.

페이지 1

페이지3-페이지18

페이지-20

In-Page 1에서는 기본적으로 버전, 작성자, 설명 및 검토자 입력란에 기재하고 관리자가 승인한 후 해당 내용을 승인자 및 승인 날짜 필드.

대부분 테스트 계획은 테스트 관리자가 승인하고 테스트 엔지니어는 이를 검토만 합니다. 그리고 새로운 기능이 나오면 테스트 계획을 수정하고 다음에서 필요한 수정을 수행할 것입니다. 버전 필드에 입력한 후 관리자의 추가 검토, 업데이트 및 승인을 위해 다시 전송됩니다. 변경 사항이 발생할 때마다 테스트 계획을 업데이트해야 합니다. 20페이지에서는 참고자료 테스트 계획 문서를 작성하는 데 사용할 모든 문서에 대한 세부 정보를 지정합니다.

메모:

테스트 계획은 누가 작성하나요?

테스트 리드→60%
테스트 관리자→20%
테스트 엔지니어→20%

따라서 위에서 볼 수 있듯이 제품의 60%에서 테스트 리드가 테스트 계획을 작성합니다.

테스트 계획은 누가 검토하나요?

테스트 리드
테스트 관리자
테스트 엔지니어
고객
개발팀

테스트 엔지니어는 모듈 관점에서 테스트 계획을 검토하고, 테스트 관리자는 고객 의견을 바탕으로 테스트 계획을 검토합니다.

테스트 계획은 누가 승인하나요?

고객
테스트 관리자

테스트 케이스는 누가 작성하나요?

테스트 리드
테스트 엔지니어

테스트 케이스를 검토하는 사람은 누구입니까?

테스트 엔지니어
테스트 리드
고객
개발팀

테스트 케이스는 누가 승인하나요?

테스트 관리자
테스트 리드
고객

테스트 계획 지침

테스트 계획을 접으세요.
중복 및 중복을 피하십시오.
위에서 이미 언급한 섹션이 필요하지 않다고 생각되면 해당 섹션을 삭제하고 계속 진행하세요.
구체적으로 말하세요. 예를 들어 소프트웨어 시스템을 테스트 환경의 일부로 지정하는 경우 이름만 언급하는 대신 소프트웨어 버전을 언급하세요.
긴 단락은 피하세요.
가능하면 목록과 표를 사용하세요.
필요할 때 계획을 업데이트하세요.
오래되고 사용되지 않은 문서를 사용하지 마십시오.

테스트 계획의 중요성

테스트 계획은 우리의 사고에 방향을 제시합니다. 이것은 반드시 따라야 할 규칙서와 같습니다.
테스트 계획은 테스트 중인 소프트웨어 애플리케이션의 품질을 검증하는 데 필요한 노력을 결정하는 데 도움이 됩니다.
테스트 계획은 개발자, 비즈니스 관리자, 고객 등 외부와 관련된 테스트 세부 사항을 이해하는 데 도움이 됩니다.
테스트 일정, 테스트 전략, 테스트 범위 등과 같은 중요한 측면은 테스트 계획에 문서화되어 관리 팀이 이를 검토하고 다른 유사한 프로젝트에 재사용할 수 있습니다.