In agile development, do we need a test plan documents? Yes, this is an test plan sample with the traditional test plan template.

1. (Agile) Test Plan Sample
1. INTRODUCTION
1.1 Purpose
1.2 Project Overview
2. BASIC STRATEGY
2.1 Development Objectives
2.2 Test Objectives
2.3 Core Strategy (Risk-Based approach)
3. Test Strategy
3.1 Test Scope in Business domain (Sprint / Integration / System Test)
2.2 Test Scope in Architecture level
3. Test R&R
4. Levles of Testing
5. Test Schedules
6. Test Environment (draft version)
7. Details of each Test Levels
♣ SDET Activities in Sprint (Co-work plan)
8. TEST MANAGEMENT
8.1 Sprint period
8.1.1 Test, Bug, Issue LifeCycle
8.1.2 (Sub)Task, Bug, Issue Management
8.2 Integration/System Test period
9. TEST AUTOMATION Environment
1. INTRODUCTION
1.1 Purpose
This test plan describes the testing approach and overall framework of the XXX Product Version 0.9.
The document introduces:
Test Strategy : rules the test will be based on, including the givens of the project (e.g.: start / end dates, objectives, assumptions);
description of the process to set up a valid test (e.g.: entry / exit criteria, creation of test cases, specific tasks to
perform, scheduling, data strategy).
Execution Strategy : describes how the test will be performed and process to identify and report defects, and to fix and implement
fixes
Test Management : process to handle the logistics of the test and all the events that come up during execution
(e.g.: communications, escalation procedures, risk and mitigation, team roster)
※ Do we need test (plan) documents in agile?
Yes!! The document is an essential method to share one's thoughts to anothers and getting feedbacks.why not?
1.2 Project Overview
- DELETED -
2. BASIC STRATEGY
2.1 Development Objectives
This implements Digital Engagement platform based on Healthcare information
Our platform provides :
- DELETED -
2.2 Test Objectives

2. We only cover Phase 1 development scope.
The objective of the test is to verify that the functionality and Non-Functionality of XXX according to the specifications.
Whole Test strategy is based on RISK BASED TEST STRATEGY (We only have limited resouce, so we focus on some area important,
ex) Mobile client)
Server Internally, Spec based test approach will be applied and will be automated.
Web UI and Mobile app UI will be tested based on Interfaces and Test Scenarios(Integration and Acceptace Level)
System must provide proper error messages, when users make unexpected behavior.
Not authorized user must not accessed or granted and the proper message should be provided.
UX/UI, Intuitive UI should be provided and any user should be able to use easily.
Non-functional - Performance, Security, etc - requirements must be tested to check product meets the expectiation
Also Cloud, Mobile specific test will be performed
If certain speciaized tests are required, the detail test plan will be established at the time needed
2.3 Core Strategy (Risk-Based approach)
- DELETED -
. Risk 1 : Sprint / Integration / System all
. Risk 2 : Integration / System
. Risk 3 : Integration
. Risk 4 : Not covered
3. Test Strategy
3.1 Test Scope in Business domain (Sprint / Integration / System Test)

3. 2.2 Test Scope in Architecture level
- DELETED -
3. Test R&R
Role Responsibility Owner
Product Owner,
Business Analyst
비즈니스 워크플로우 상 의사결정이 필요한 사항에 대해 이해관계자와 협의하고
영향 정도를 고려하여 결정한다
사용자 스토리에 대한 종료 조건을 검토하고 피드백을 준다
통합 테스트 시나리오에 대해 리뷰한다
가
Developers 사용자 스토리에 대한 테스트의 완료 조건을 SDET과 협의하여 정의한다
SDET과 짝테스트/프로그래밍을 수행한다
등록된 결함에 대해 리뷰하고 조치한다
개별 API의 성능 이슈가 있는 경우 원인을 파악하고 조치한다
통합 테스트 시나리오에 대해 리뷰한다
SDET Common 사용자스토리에 대한 을 정의하고 관리한다완료 조건(AC)
결함 발생 시 결함 등록 및 조치 여부를 확인 한다
개발자와 짝 테스트를 수행 한다
통합 테스트 시나리오를 작성하고 개발팀과 같이 리뷰한다
Jenkins를 이용하여 자동화된 테스트 환경을 구성하고 모니터링 한다
테스트 환경(개발 및 테스트 서버, 자동화 테스트 수행 서버)를 구축하고 유지한다
테스트 자동화 결과를 리포팅하고 관련 툴과의 연계를 검토한다
A,
B
REST API Functional SDET 에 대응하는 테스트 케이스 작성 및 API에 대한AC 또는 REST API 스펙
테스트 자동화 스크립트를 작성한다
테스트를 수행하고 그에 대한 결과를 관리한다
API에 대한 보안 테스트 케이스를 도출하고 수행한다
A
REST API Performance SDET 개별 API에 대한 JMeter 성능 테스트 스크립트를 작성/수행한다
수행 결과가 실패(결과 오류, 특정 API의 수행시간이 과도하게 오래 걸리는 경우)인
경우
개발자와 같이 원인을 파악하고 재테스트한다
B
4. Levles of Testing
Test Level Name Description Target Method period Owner

4. Sprint Test Server Internal Test 서버 내부 개별 모듈에 대한 테스트 서버 Java 코드 JUnit 스프린트 개발자
REST API Functional
Test
개별 API 단위로 스펙 기반 기능 검증 each REST API Rest-Assured
or
SoapUI
스프린트 개발자,
SDET
REST API Performance
Test
개별 API 단위로 약식으로 동시 호출
테스트 수행
each REST API JMeter 스프린트 SDET,
개발자
Mobile UI Test 사용자스토리 단위로 구현된 모바일 UI 및
기능에 대한 테스트 수행
기능/업무 단위
모바일 UI
매뉴얼 테스트 스프린트 개발자,
SDET
Web UI Test 사용자스토리 단위로 구현된 웹 UI 및 기능에
대한 테스트 수행
기능/업무 단위
웹 UI
매뉴얼 테스트 스프린트 개발자
Integration
1st
Internal Integration
Test
내부 시스템간의 연동을 포함하여 사전에 정의한
통합 테스트 시나리오 기반으로 테스트를 수행한다
테스트 시나리오
(내부 통합)
매뉴얼 테스트 통합테스트
1차
개발팀,
SDET
Integration
2nd
External Integration
Test
외부 시스템 연동을 포함하여, 실제 운영 환경에서
사전에 정의한 통합 테스트 시나리오 기반으로
테스트를 수행한다
테스트 시나리오
(전체 통합)
매뉴얼 테스트 통합테스트
2차
개발팀,
SDET
System Test Performance Test 실제 운영 환경에서 정의한 성능 여건을 만족하는지
확인하는 성능 테스트를 수행한다. 주요 성능 요건은
모바일 어플리케이션이 요청하는 API호출 영역이며,
클라우드 환경을 포함한 전체 환경에 대한 테스트를
진행한다
성능 테스트
시나리오
별도 수행 계획에
따라 수행
시스템테스트 별도 성능
전담 인력
Mobile compatibility
Test
OS 종류/버전 및 다양한 해상도에서 모바일
어플리케이션의 UI 및 기능이 정상 동작하는지를
검증한다
모바일
어플리케이션
mTworks 시스템테스트 수행
시점
정의
Mobile Non-Functional
Test
모바일 어플리케이션에 대해
배터리 소모량,
CPU/메모리 사용률,
발생 트래픽, Front-end 반응 속도
등에 대해
검증 필요성을 검토하여 수행한다
모바일
어플리케이션
mTworks 시스템테스트 수행
시점
정의
Server Security Test . 접속 및 권한이 제한된 기능에 대한 호출,
. 악의적인 반복호출 공격 등
사전에 보안 관련 테스트 시나리오를 작성하고
해당 내용에 따라 테스트를 수행한다
보안 테스트 대상 매뉴얼 테스트 등 시스템
테스트 기간
- SDET
리소스
논의
필요-
개발팀
5. Test Schedules

5. 6. Test Environment (draft version)

7. 7. Details of each Test Levels
-DELETED-
♣ SDET Activities in Sprint (Co-work plan)
8. TEST MANAGEMENT
8.1 Sprint period
8.1.1 Test, Bug, Issue LifeCycle
User story will be the main item to manage dev lifecycle. Testing and defects will be connected with user-story in JIRA system

8. 8.1.2 (Sub)Task, Bug, Issue Management
8.2 Integration/System Test period
-deleted-
9. TEST AUTOMATION Environment
-deleted-