Course Details
A 2-day course, 6 hours per day (12 hours in total, 09:00-16:00), delivered as lectures with workshops against a real system. Beginner to Intermediate level. The course focuses on testing thinking and process rather than a deep dive into any single tool, so it transfers to other frameworks. Anyone wanting a Playwright-specific deep dive should take the separate Playwright End-to-End Web Testing course. Learners take home a prompt template set covering every QA stage, templates for test plan, test case, defect report and quality report, plus sample scripts.
Day 1: Designing Tests with AI
Section 1: AI in QA Work and Where It Belongs
- The QA work that consumes the most time and where AI genuinely helps
- What AI cannot do for you, such as judging what is risky enough to test
- An overview of the full path from planning to quality reporting
- Confidentiality risk when customer data meets external AI tools
- Preparing tools and accounts for both days
Section 2: Requirement Analysis and Test Planning
- Reading requirements to find ambiguity and unstated conditions
- Using AI to generate the questions to send back to the dev team before testing starts
- Risk assessment to decide what gets tested first
- What a concise, genuinely usable test plan contains
- Lab: write a test plan from the requirements of your own system
Section 3: Test Case Design with Standard Techniques
- Equivalence partitioning and boundary value analysis
- Decision tables and state transition for complex conditions
- Writing test cases with clear preconditions, steps and expected results
- Using AI to extend the set into the cases people habitually miss
- Removing redundant cases so the suite does not bloat
- Lab: build a test case set for a real feature and check its coverage
Section 4: Preparing Test Data
- Types of test data and the edge cases that must always be present
- Using AI to generate realistic synthetic data without touching real customer records
- Anonymization and the precautions required under the Personal Data Protection Act
- Preparing data sets so repeated runs give identical results
- Lab: build a test data set covering every case you designed
Section 5: Directed Exploratory Testing
- The difference between scripted testing and exploratory testing
- Writing a charter to set the scope and goal of each session
- Using AI to form hypotheses about where the system is likely to break
- Recording what you did and what you found so it can be audited later
- Lab: run an exploratory session against a real system and summarize the findings
Section 6: API Testing
- Reading an OpenAPI spec to derive what must be tested
- Designing tests for happy paths, invalid data and unauthorized access
- Verifying status codes, response structure and error messages
- Using AI to build the API test set from the spec and checking it is complete
- Lab: build and run an API test set in Postman from a real spec
Day 2: Automation, Analysis and Reporting
Section 7: Writing Automation Scripts with AI
- Deciding which test cases are worth automating and which should stay manual
- Turning test cases into scripts with AI and reviewing what it produced
- Choosing selectors that survive interface changes
- Structuring scripts so they can be maintained rather than thrown away
- Lab: convert test cases into automation scripts and run them against a real system
Section 8: Keeping Scripts from Turning Brittle
- Why test scripts break so often and how to prevent it while writing them
- Handling waits and page state so results stay stable
- Dealing with flaky tests and deciding whether to fix or delete them
- Using AI to analyze why a script failed and propose a fix
- Lab: repair a script broken by an interface change
Section 9: Risk-Based Regression Selection
- Why running the full regression suite every time stops being viable
- Analyzing which parts of the system a code change touches
- Using AI to propose the test set to run from the change list
- Tiering suites into smoke, critical path and full regression
- Scheduling runs across the development cycle to fit the time available
Section 10: Failure Analysis and Defect Reports
- Reading a failure and separating a real bug from a problem in the script itself
- What a defect report needs so a developer can act without asking questions back
- Using AI to write clean reproduction steps and assign severity
- Grouping bugs that share a root cause to avoid duplicate reports
- Lab: write defect reports from the real test results produced in class
Section 11: Quality Reporting and the Limits of AI
- Quality metrics that mean something versus metrics that make teams game the numbers
- Summarizing quality status for management without technical detail
- Where AI typically fails in testing, such as test cases that look good but test nothing
- Reviewing AI output before use and keeping accountability with people
- Lab: produce a one-page quality report for the test cycle just completed
Section 12: Capstone and Real-World Adoption
- Capstone: plan and test one feature set from requirement analysis through to the report
- Presenting the reasoning behind your scope and test order
- How to bring this process back to your team, starting where it pays off fastest
- Workshop: present your work and review the approach with the instructor