AI for QA & Software Testing is a course in using AI at every stage of testing, from requirement analysis, test case design and test data to exploratory and API testing, maintaining automated scripts, risk-based regression and quality reports, with a clear view of AI's limits. It suits QA engineers, software testers, manual testers and QA leads.
Most QA time disappears into repetitive work: writing test cases one by one from incomplete documentation, preparing test data set by set, chasing scripts that broke because a screen changed slightly, and then summarizing results for the team. When time runs short someone has to choose what gets tested and what gets waved through, and that is exactly where bugs slip into production. This course uses AI to cut that repetitive work away and gives the time back to deciding what actually needs testing and what carries the most risk. Learners apply AI across the whole discipline: analyzing requirements to surface risk,
designing test cases with standard techniques such as equivalence partitioning and boundary value analysis, generating thorough test data without using real customer records, running directed exploratory testing, testing APIs against the spec, writing and repairing automation scripts, selecting a risk-based regression set, analyzing failures and writing defect reports a developer can act on immediately, and reporting quality to management. A dedicated section covers where AI cannot be trusted and must always be checked. It closes with a capstone that plans and tests one system end to end. (2 days, 6 hours per day, 12 hours in total, Beginner to Intermediate level.)
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.
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
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
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
Boundary value analysis picks test values at the edges of a valid range, because errors tend to occur there. For an age field accepting 18 to 60, you would test 17, 18, 60 and 61. It is usually paired with equivalence partitioning, which divides inputs into groups the system should treat alike and tests one value from each. Together they cut the number of test cases while still covering the key risks.
Start by giving the AI a clear requirement or user story with its business rules, ask it to apply named techniques such as boundary values or decision tables, and specify an output with preconditions, steps and expected results. Then ask it for cases people tend to miss, have a person review and remove duplicate or wrong cases, and prioritise by risk. Never put real customer data into external AI tools.
A flaky test passes sometimes and fails other times without any code change. Common causes are poorly timed waits, shared test data and selectors tied to page structure. Quarantine unstable tests first so the team does not stop trusting results, then find the root cause from logs, screenshots or traces and decide whether to fix or remove the test. AI can help analyse causes and suggest fixes.
It suits QA engineers and software testers who want less repetitive work and better coverage, manual testers who want to start automating without a programming background, developers who test their own work, and QA leads who plan testing and report on quality. You should understand the software development process, have some testing experience and be confident with computers; programming is not required.
You will be able to write a test plan from requirements, design test cases with standard techniques and AI, create synthetic test data without real customer data, run focused exploratory testing, test APIs with Postman from an OpenAPI specification, turn test cases into automated scripts and keep them robust, choose regression suites by risk and produce quality reports. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Yes. It can be run in-house for your team, with examples adapted to your own work, such as building the test plan and test suites around a system or website your team looks after. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
Testing a web application by hand before every release burns an enormous amount of team time, and the bigger the system gets the less of it actually gets covered. The bugs users hit are usually in the paths nobody re-clicked. Playwright is Microsoft…
System analysis and design work burns more time on writing documents and drawing diagrams than on the design thinking itself. Getting the use cases complete, finishing the process flows, making the ER diagram match what was actually agreed, then writing the…
