Skip to content

Commit 26d7020

Browse files
TessFerrandezTessFerrandez
authored
Content on Test Planning (#1085)
* test planning * fix numbering
1 parent 54a285d commit 26d7020

File tree

1 file changed

+219
-0
lines changed

1 file changed

+219
-0
lines changed

‎docs/automated-testing/test-planning.md

+219
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,219 @@
1+
# Test planning
2+
3+
We should be intentional when we think about how to test our applications. One way to make sure that we are testing the right things is to build test plans for various scenarios and work out test cases at the design stage of a user story.
4+
5+
This content aims to show some ways we can think about planning and give some examples using a web site with a login portal as an example.
6+
7+
## Building test cases for a user story
8+
9+
As we design the code for a user story we can start by defining a set of test cases that will ensure that all acceptance criteria are met.
10+
11+
This can be done as an exercise that includes both the developers and other stakeholders. Some of the test cases may initially be manual, and some may be planned for automation, depending on the situation.
12+
13+
Going through this exercise doesn't only produce test cases, it also helps clarify the acceptance criteria and informs how we should build the solution.
14+
15+
1. Understand the Acceptance Criteria
16+
- Thoroughly read and understand the acceptance criteria for the story
17+
- Clarify any ambiguities with the product owner or stake holders
18+
19+
2. Identify Test Scenarios
20+
- Consider both positive and negative scenarios (happy paths, and error cases) to cover edge cases
21+
- Determine what is in and out of scope, i.e. do we only test functional requirements, or are non-functional requirements such as security, accessibility, reliability etc. in scope for testing?
22+
23+
3. Define Test Cases
24+
- For each test scenario, define detailed test cases
25+
- Each test case should be documented with
26+
- **TestCase Title:** What is being tested
27+
- **Preconditions:** Any setup or test data required before executing the test
28+
- **Test Steps:** Step-by-step instructions to execute the test
29+
- **Expected Result:** The expected outcome of the test
30+
31+
The test can be described in the Given-When-Then format to make it clear and concise:
32+
33+
**Given** the initial context or state, **When** the action or event, **Then** the precise outcome
34+
35+
4. Automate where Possible
36+
- If feasible, automate the test cases
37+
- Focus on automating hot paths, and critical areas
38+
39+
5. Review and Refine
40+
- Review the test cases with peers or stakeholders to ensure that we have covered everything we want to cover, and that expected outcomes are correct
41+
- Refine the test cases based on feedback
42+
43+
### Examples of Test Cases using the Given-When-Then Format
44+
45+
| User Login | (Positive Test Case) |
46+
| -- | -- |
47+
| **Title** | Verify user login with valid credentials |
48+
| **Preconditions** | User is on the login page |
49+
| **Test Steps** | **Given** the user is on the login page **When** the user enters valid credentials and clicks the login button **Then** the user should be redirected to the dashboard |
50+
| **Expected Result** | User is successfully logged in and redirected to the dashboard |
51+
52+
| User Login with Invalid Credentials | (Negative Test Case) |
53+
| -- | -- |
54+
| **Title** | Verify user login with invalid credentials |
55+
| **Preconditions** | User is on the login page |
56+
| **Test Steps** | **Given** the user is on the login page **When** the user enters invalid credentials and clicks the login button **Then** the user should se an error message indicating invalid username or password |
57+
| **Expected Result** | Error message is displayed and the user remains on the login page |
58+
59+
| Security Testing for Login Page | (Non-Functional Requirement) |
60+
| -- | -- |
61+
| **Title** | Verify that the login page is protected against SQL injection attacks |
62+
| **Preconditions** | User is on the login page |
63+
| **Test Steps** | **Given** the user is on the login page **When** the user enters a SQL injection string (e.g. ' OR '1'=1) in the username field and clicks the login button **Then** the system should not allow login and should display an error message |
64+
| **Expected Result** | The system prevents login and displays an error message |
65+
66+
| Usability Testing for Form Validation | (Non-Functional Requirement) |
67+
| -- | -- |
68+
| **Title** | Verify that the registration form provides clear error messages for invalid inputs |
69+
| **Preconditions** | User is on the registration page |
70+
| **Test Steps** | **Given** the user is on the registration page **When** the user enters invalid data (e.g. incorrect email format) and submits the form **Then** the system should display a clear and specific error message indicating the issue |
71+
| **Expected Result** | Clear and specific error message is displayed |
72+
73+
| Reliability Testing for System Uptime | (Non-Functional Requirement) |
74+
| -- | -- |
75+
| **Title** | Verify that the system maintains 99.9% uptime over a month |
76+
| **Preconditions** | System is monitored over a month |
77+
| **Test Steps** | **Given** the system is up and running **When** the system is monitored for uptime over a month **Then** the system should maintain 99.9% uptime |
78+
| **Expected Result** | System maintains 99.9% uptime over the monitored period |
79+
80+
## Grouping Test Cases into Test Plans
81+
82+
We can create different test plans, such as a full regression test plan, a smoke test plan, a functional test plan etc. and organize the test cases under these test plans.
83+
84+
A few benefits of creating test plans are:
85+
86+
- We can make sure that all aspects of the application are tested, including functional, non-functional and edge cases
87+
- They provide clear objectives and scope, which helps developers understand what needs to be tested
88+
- They help manage and execute tests systematically, i.e. we have a suite of tests to run validate integration etc.
89+
- By identifying and prioritizing test cases based on risk, test plans help us focus on the most critical areas of the application.
90+
- In some industries they are required for compliance with standards and regulation.
91+
- They help us understand what tests are most important to automate
92+
93+
### Common Test Plans
94+
95+
Here are some examples of test plans we may want to create for our systems:
96+
97+
#### Full Regression Test plan
98+
99+
**Purpose:** To verify that recent changes have not adversely affected existing functionality
100+
**Test Cases Included:**
101+
102+
- All functional test cases
103+
- All integration test cases
104+
- All system test cases
105+
- All previously reported bugs that have been fixed
106+
107+
**Example:**
108+
109+
- Test001: Verify user login with valid credentials
110+
- Test002: Verify user registration with valid details
111+
- Test003: Verify password reset functionality
112+
113+
#### Smoke Test plan
114+
115+
**Purpose:** To perform a quick check to ensure that the most critical functionalities of the application are working
116+
**Test Cases Included:**
117+
118+
- Basic functionality test cases
119+
- High-priority test cases that cover the core features
120+
121+
**Example:**
122+
123+
- Test001: Verify user login with valid credentials
124+
- Test004: Verify adding an item to the shopping cart
125+
- Test005: Verify search functionality with a valid keyword
126+
127+
#### Functional Test Plan
128+
129+
**Purpose:** To verify that each function of the software application conforms to the specification
130+
**Test Cases Included:**
131+
132+
- Test cases that validate specific functionality
133+
- Test cases that cover user interactions and business logic
134+
135+
**Example:**
136+
137+
- Test002: Verify user registration with valid details
138+
- Test006: Verify user login with invalid credentials
139+
- Test005: Verify user registration with missing requirement fields
140+
141+
#### Area Regression Test Plan
142+
143+
**Purpose:** To verify that changes in a specific area of the application have not affected other parts of the application
144+
**Test Cases Included:**
145+
146+
- Test cases related to the specific area where changes were made
147+
- Test cases that cover the integration points of the affected area
148+
149+
**Example:** If changes were made to the user profile model
150+
151+
- Test008: Verify password reset functionality with an invalid email address
152+
- Test009: Verify updating user profile information
153+
- Test010: Verify changing user password
154+
155+
### Other Test Plan Examples
156+
157+
Here are some additional examples of test plans:
158+
159+
#### Integration Test Plan
160+
161+
To verify that different modules or services of the application work together as expected
162+
163+
- Test cases that validate the interaction between different modules
164+
- Test cases that check data flow between integrated components
165+
166+
#### User Acceptance Test (UAT) Plan
167+
168+
To ensure the system meets the business requirements and is ready for production use
169+
170+
- Test cases based on real-world scenarios and user stories
171+
- Test cases that validate end-to-end business processes
172+
173+
#### Load Test Plan
174+
175+
To determine how the system performs under heavy load conditions
176+
177+
- Test cases that simulate high user traffic
178+
- Test cases that measure response times and system behavior under load
179+
180+
#### Security Test Plan
181+
182+
To identify and mitigate security vulnerabilities in the application
183+
184+
- Test cases that check for common security issues like SQL injection, XSS, and CSRF
185+
- Test cases that validate user authentication and authorization mechanisms
186+
187+
#### Compatibility Test Plan
188+
189+
To ensure the application works across different devices, browsers, and operating systems
190+
191+
- Test cases that validate functionality on various devices and browsers
192+
- Test cases that check for consistent user experiences across platforms
193+
194+
#### Recovery Test Plan
195+
196+
To verify the system's ability to recover from crashes, hardware failures, or other catastrophic problems
197+
198+
- Test cases that simulate system failures and recovery processes
199+
- Test cases that validate data integrity after recovery
200+
201+
#### Localization Test Plan
202+
203+
To ensure the application is correctly adapted for different languages and regions
204+
205+
- Test cases that validate language translations
206+
- Test cases that check for region specific content
207+
208+
### How to Group Test Cases into a Test Plan
209+
210+
1. **Identify the Scope:** Determine the scope of each test plan based on testing objectives
211+
2. **Select Relevant Test Cases:** Chose test cases that align with the scope and objectives of each test plan
212+
3. **Organize Test Cases:** Group the selected test cases into the respective test plans
213+
4. **Review and Validate:** Review the grouped test cases to ensure they cover all necessary aspects and validate them with stakeholders if needed
214+
5. **Document the Test Plans:** Clearly document each test plan, including the purpose, scope, and list of test cases
215+
216+
## Resources
217+
218+
- [The One Page Test Plan](https://www.ministryoftesting.com/articles/the-one-page-test-plan)
219+
- [One-Page Test Plan | Write your Plan in Minutes](https://www.youtube.com/watch?v=BYN6AFhR4GE)

0 commit comments

Comments
 (0)