|
1 | 1 | # Session Plan |
2 | 2 |
|
3 | | -> [!TIP] |
4 | | -> The session plan is written to guide the mentor to prepare and run the session. Of course, trainees may come across and read this material. But it should be written as if you're speaking to a mentor. |
| 3 | +- Introduction & Context (20 mins) |
| 4 | + - What performance testing is and why it matters |
| 5 | + - Business impact of poor performance |
| 6 | + - QA’s role as the first line of defense |
| 7 | +- Performance Fundamentals (30 mins) |
| 8 | + - What performance means (response time, error rate, throughput) |
| 9 | + - Industry standards and expectations |
| 10 | + - Availability and downtime impact |
| 11 | + - Throughput vs number of users |
| 12 | +- Performance Across the SDLC (25 mins) |
| 13 | + - Performance mindset: shift left |
| 14 | + - Responsibilities in each SDLC phase: |
| 15 | + - Requirements |
| 16 | + - Design |
| 17 | + - Development |
| 18 | + - Testing |
| 19 | + - Production |
| 20 | + - Performance success model |
| 21 | +- Stages of Performance Testing (25 mins) |
| 22 | + - Planning |
| 23 | + - Preparation |
| 24 | + - Scripting |
| 25 | + - Execution |
| 26 | + - Analysis |
| 27 | + - Reporting |
| 28 | + - Typical deliverables of a performance engagement |
| 29 | +- Backend Performance Testing with k6 (Hands‑On) (40 mins) |
| 30 | + - What k6 is and why it’s used |
| 31 | + - Key k6 concepts (VUs, stages, checks, thresholds) |
| 32 | + - Writing k6 scripts in VS Code |
| 33 | + - Running: |
| 34 | + - Single‑user tests |
| 35 | + - Load tests |
| 36 | + - Stress tests |
| 37 | + - Reading metrics and results |
| 38 | + - PASS / FAIL against SLAs |
| 39 | +- Frontend Performance Testing with Google Lighthouse (20 mins) |
| 40 | + - What Lighthouse is |
| 41 | + - Why frontend performance matters |
| 42 | + - Lighthouse audit categories |
| 43 | + - Core Web Vitals (FCP, LCP, TBT, CLS, Speed Index) |
| 44 | + - Desktop vs Mobile differences |
| 45 | +- Lighthouse Hands‑On Exercises (25 mins) |
| 46 | + - Running Lighthouse from Chrome DevTools |
| 47 | + - Reading the report (Metrics, Opportunities, Diagnostics) |
| 48 | + - Mobile vs Desktop analysis |
| 49 | + - Running Lighthouse from CLI |
| 50 | + - Using Lighthouse as a performance budget gate |
| 51 | +- Reporting & Decision Making (15 mins) |
| 52 | + - Correlating frontend and backend findings |
| 53 | + - Identifying risks, bottlenecks, hot spots |
| 54 | + - Communicating results to stakeholders |
| 55 | + - Go / No Go mindset |
| 56 | +- Wrap‑Up & Next Steps (10 mins) |
| 57 | + - Key takeaways |
| 58 | + - Performance as continuous practice |
| 59 | + - How to apply in real projects |
5 | 60 |
|
6 | 61 | ## Session Materials |
7 | 62 |
|
8 | | -> [!TIP] |
9 | | -> Previously used slides, docs or any other materials that future mentors could get value from should be listed here. If we don't have any (yet), this section can be removed. |
10 | | -
|
11 | | -These are some examples of previously created materials by mentors that you can use yourself, or for inspiration. |
12 | | - |
13 | | -- [`Resource Name`, `@author`, `Team X`](https://example.com/) |
14 | | - |
15 | | -## Session Outline |
16 | | - |
17 | | -> [!TIP] |
18 | | -> Write a plan for the order of topics, points to cover, examples, timings, exercises and any other useful info to guide the session. |
19 | | -
|
20 | | -## Exercises |
21 | | - |
22 | | -> [!TIP] |
23 | | -> Exercises might appear inside the Session Outline section if they are tightly integrated into the flow of the session. If you have more like a library of exercises that should be worked through in order, then you could also list them in a separate section here. |
24 | | -
|
25 | | -## Optional Exercises |
26 | | - |
27 | | -> [!TIP] |
28 | | -> If you have some extra exercises that trainees can complete if they finish the rest, or want to push themselves, include them in this optional section. |
| 63 | +In this session, you will learn the fundamentals of front-end performance testing and how modern tools like Google Lighthouse help QA teams ensure quality. We will cover key performance metrics, run Lighthouse audits, interpret reports, and explore automation options using Lighthouse CLI or Node module. |
0 commit comments