Software Testing Foundation is a course in systematic software testing, from analysing requirements and writing precise test cases to using generative AI to design end-to-end test scenarios, with no programming required. It suits testers, QA staff, developers, business analysts and anyone moving into a software testing role.
Most software that runs into trouble after delivery was not left untested; it was tested in the wrong places. Missing or conflicting requirements were not caught early, test cases were written so loosely that nobody else could follow them, and no one could say whether the testing actually covered how real users work. Good testing starts with understanding the requirements and needs a systematic way of thinking, not just clicking around to see whether things work.
This course builds a solid foundation in software testing, starting with the role of testing in each phase of the SDLC, gathering requirements from stakeholders, finding requirements that are missing or in conflict and turning them into test cases, the types of testing and how to choose between them, the difference between test-last and test-first, and writing precise, well-structured test cases. Day two moves
on to prioritizing test cases with risk analysis, using generative AI to help design test cases, test scenario techniques that cover every requirement, analyzing user scenarios and system flows, designing end-to-end scenarios around business processes, and managing defects systematically. Everything is practiced through workshops built on one continuous case across both days. (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 that follow one continuous case across both days. Beginner to Intermediate level; no programming background is needed. The course focuses on testing techniques and ways of thinking rather than any particular testing tool. Workshops are done in spreadsheets and prepared templates, and a free generative AI plan is enough. Learners take home the course materials, exercises, and templates for test cases, test scenarios and defect reports that they can use with their team straight away.
Section 1: The SDLC and the Role of Testing
An overview of the Software Development Life Cycle, phase by phase
What testing contributes from requirements through to delivery
The cost of defects found late compared with defects found early
Quality responsibilities of testers, developers and BAs
Section 2: Developing and Gathering Requirements
What makes a good requirement
Identifying stakeholders and what each of them needs
Techniques for eliciting and gathering requirements from stakeholders
Separating functional from non-functional requirements
Section 3: From Requirements to Test Cases
Finding requirements that are missing, ambiguous or in conflict
Turning requirements into testable conditions
Linking requirements to test cases so they can be traced back
Workshop: analyze the requirements of a realistic case and draft test cases
Section 4: Testing Concepts and Types
Basic principles of software testing
Test levels: unit, integration, system and acceptance
Functional and non-functional testing, regression and smoke testing
Choosing the right type of testing for the work and the resources
Section 5: Test-Last versus Test-First
The test-last approach: testing after development
The test-first approach: thinking about tests before development
Strengths and limits of each approach
Choosing an approach that suits the team and the project
Section 6: Writing Precise and Effective Test Cases
The parts of a well-structured test case
Writing clear preconditions, test steps and expected results
Avoiding test cases so broad or vague that nobody can follow them
Workshop: write and review test cases together in groups
Section 7: Prioritizing Test Cases with Risk Analysis
Assessing risk by likelihood and impact
Identifying the parts of the system with the highest risk to the business and users
Prioritizing test cases when testing time is limited
Workshop: prioritize the case's test cases by risk level
Section 8: Using Generative AI to Design Test Cases
Using generative AI to break requirements down into test cases
Writing prompts that produce complete test cases in the right format
Reviewing AI output for gaps and errors
Workshop: compare hand-written test cases with AI-assisted ones
Section 9: Test Scenario Design Techniques
How test scenarios differ from test cases
Designing scenarios that cover every requirement
Scenarios for normal, error and boundary cases
Using a coverage table to check requirement coverage
Section 10: User Scenarios and System Flow
Looking at scenarios from the user's point of view
Analyzing system flow to find the paths that need testing
Validating that the scenarios are complete
Workshop: write user scenarios and check their completeness against the flow
Section 11: End-to-End Business Process Scenarios
Walking through a business process from start to finish
Integration points between systems where problems often appear
Designing end-to-end scenarios that reflect real use
Workshop: design end-to-end scenarios for a sample process
Section 12: Defect Management and Analysis
The life cycle of a bug or defect
Writing defect reports that developers can reproduce and fix
Setting severity and priority appropriately
Analyzing defect trends to improve the process
Taking the knowledge back to the team and on to advanced testing
A test scenario describes, at a high level, what needs testing, such as a user placing an order and paying successfully. A test case details how to test it, with preconditions, test steps, test data and an expected result clear enough for someone else to repeat. One scenario usually breaks down into several test cases covering normal paths, error paths and boundary values.
List the parts of the system or features to be tested, then rate each on two factors: the likelihood of failure, such as new or complex code, and the impact of a failure on the business and users, such as payments or customer data. Multiply the two or place them on a risk matrix, and test the highest-risk areas first and in most depth, so that when time is short the most important areas are still covered.
Severity describes how badly a defect affects the system, such as a crash or corrupted data, and is usually assessed by the tester. Priority describes how urgently it must be fixed from a business point of view, and is usually decided by the product owner or project manager. They do not always match: a misspelt company name on the home page is low severity but high priority, while a crash in a rarely used menu may be high severity but lower priority.
It suits testers and QA staff who want a systematic foundation, developers and dev leads who care about quality, product owners, business analysts and system analysts, and people changing careers into software testing. No programming background is needed, though experience of using websites or apps and a general idea of how software is developed will help. A free generative AI account is needed for the workshops.
You will be able to analyse requirements for gaps, ambiguity and conflicts, write precise test cases, choose suitable test levels and types, prioritise test cases with risk analysis, use generative AI to turn requirements into test cases and review the results, design end-to-end scenarios and write defect reports developers can reproduce. 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 analysing requirements and writing test cases for the systems your team builds or maintains. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
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…
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…
