Software QA & Test Automation

Take an unfamiliar web application and build a complete, maintainable quality strategy, from risk based test design to automated pipelines.

7 Weeks4 Sessions/WeekIn PersonBeginner-friendly

Risk-Based TestingTest AutomationAPI Testing

Share this course

Overview Curriculum Capstone Assessment Enquire

What you'll be able to do

Graduates can take an unfamiliar web application and produce a complete, maintainable, CI-integrated quality strategy.

Design risk-based test coverage and write reproducible bug reports
Build an API test suite with schema and database validation
Build a page-object-structured UI automation framework
Run suites cross-browser and in parallel inside a CI pipeline with gating
Publish reports and triage failures from them
Conduct performance and accessibility smoke testing
Argue credibly about what should and should not be automated

Who it's for

Manual QA testers moving into automation
Graduates seeking the fastest credible entry into a software team
Non-CS graduates with strong analytical skills
Developers wanting test engineering depth

Prerequisites

None beyond computer literacy and logical thinking.

Applicants should be aware that this is not a code-free course.

Test automation is software development, and students write code from week two onward.

All students complete the two-session Engineering Onboarding module before Module 1.

Tools and technologies

TypeScriptPlaywrightPostman and NewmanSQL and PostgreSQLGitHub ActionsAllure reportingDockerJira or GitHub Issuesk6axeSelenium WebDriver with Java or Python, covered as a second framework

Target roles

QA EngineerAutomation EngineerSDET ITest Engineer

Course curriculum

7 modules · 6-7 weeks

Concepts: where QA sits in the delivery lifecycle; shift-left and the cost of late defects; risk-based prioritisation; test design techniques including equivalence partitioning, boundary values, decision tables, state transitions and pairwise combinations; exploratory testing with charters; functional and non-functional dimensions; the bug report as a professional artifact covering title, environment, steps, expected against actual behaviour, evidence, severity and priority; defect lifecycle; requirements analysis; Agile ceremonies from a QA seat; entry and exit criteria; what not to automate.
Lab: timed exploratory session against a deliberately faulty application, with bug reports scored against a rubric where reproducibility is pass or fail; build a risk-prioritised test matrix; attempt to reproduce a classmate's defect using only their report.
Project: a written test strategy covering scope, risks, approach, environments, entry and exit criteria, and automation candidates with justification.

Concepts: TypeScript basics covering types, functions, arrays, objects and control flow; asynchronous code and why every browser action is asynchronous; classes and inheritance, since frameworks are built on them; modules and imports; error handling; reading a stack trace; JSON and data structures; the test runner model of describe blocks, hooks and assertions; debugging tests in an IDE; Git workflow for test code including reviewing test pull requests; browser DevTools covering the network tab, console, DOM inspection, cookies and storage.
Lab: twenty katas progressing from string handling to array transformation to asynchronous requests; write assertions against JSON responses; debug three failing tests using breakpoints; open and review a test-code pull request.
Project: a typed test-data utility library generating users, dates, identifiers and edge-case strings, reused throughout the course.

Concepts: why API tests carry the highest value per test; REST fundamentals from a tester's perspective; contract testing; status code and header verification; JSON schema validation; authentication in tests covering tokens, sessions and refresh; test data setup and teardown through the API rather than the UI; chained requests and state dependency; negative testing, boundary testing and input fuzzing; idempotency and race conditions; SQL for verifying that the API wrote what it reported; mocking third-party services; webhook testing; suite organisation and shared fixtures.
Lab: build a full suite for an authenticated CRUD service covering happy paths, every documented error path, schema validation and boundary cases; write SQL assertions confirming database side effects; break the API's validation with hostile payloads and report the findings.
Project: Mini-project 1: API Test Suite of forty or more tests, schema-validated, authentication-handling, database-verified, with fixtures and a README stating coverage and known gaps.

Concepts: browser automation architecture and sources of instability; locator strategy as the main determinant of maintainability, covering role-based and accessible locators, test identifiers, and why long XPath chains decay; auto-waiting against manual sleeps; retrying assertions; reusing authentication state; navigation, frames, dialogs, tabs, downloads and uploads; forms and complex widgets; tables and dynamic lists; test isolation; parallel-safe test data; visual comparison basics; debugging with the trace viewer, video and screenshots; the limits of generated code.
Lab: automate five critical journeys; refactor a generated test into a maintainable one and justify each change; create flakiness three different ways and fix each root cause; diagnose an unfamiliar failure using only the trace viewer; run an accessibility scan on a key page.
Project: an initial UI suite covering the target application's critical journeys, passing three consecutive runs.

Concepts: the difference between having tests and having a framework; the Page Object Model and its failure modes, including bloated page classes and assertions inside pages; component objects and application-action layers; fixtures and dependency injection; data-driven testing and parameterisation; per-environment configuration; secrets handling; tagging and suite segmentation into smoke, regression and critical sets; shared helpers and the tension between reuse and clarity; flakiness as an engineering problem, covering quarantine, retry policy and root-cause categories; suite runtime as a tracked metric; code review standards for test code; when to delete a test; where BDD frameworks help and where they add overhead.
Lab: refactor the Module 4 suite into a layered framework and measure the change in lines per test; parameterise a test across twelve data sets; split the suite into smoke and full regression with separate runtimes; review a classmate's framework against a maintainability rubric.
Project: Mini-project 2: the UI suite becomes a documented framework, environment-configurable, tagged, and extensible by another engineer.

Concepts: tests that do not run in a pipeline do not protect anything; pipeline triggers on pull request, merge, schedule and nightly runs; which suites run at which trigger; parallelisation and sharding to control runtime and cost; containerised execution for environment parity; cross-browser and cross-viewport strategy; artifacts including traces, videos and failure screenshots; reporting with trend history and a defined triage workflow; quality gates that block a merge; test environment and test data management in CI; notification design; flakiness tracking; Selenium WebDriver architecture, locators, waits and test structure, mapped onto concepts students already hold.
Lab: build a pipeline running smoke as a required pull request check and full regression nightly, sharded across four workers; publish reports as artifacts; force a pipeline failure on a real regression and triage it using only the report; port three tests to Selenium and document the differences.
Project: the full suite runs in CI with gating, sharding, reporting and failure artifacts.

Concepts: performance testing foundations covering load, stress and soak profiles, virtual users, percentile latency, bottleneck identification, and the boundary between the QA and engineering roles; accessibility testing covering WCAG basics, automated scan limits and manual keyboard and screen-reader checks; security smoke testing for the OWASP items a tester can verify, including broken access control, injection inputs, exposed data and missing rate limits; mobile testing awareness; AI-assisted testing covering generated test cases and data, locator repair, self-healing claims examined critically, failure summarisation, and the professional boundary that the engineer owns and reviews every generated test; meaningful metrics against vanity metrics; career progression after the first role.
Lab: load-test an endpoint and report percentiles and the identified bottleneck; audit two pages for accessibility with prioritised findings; run a security smoke checklist against the target application; generate test cases from a requirements document using an LLM, then edit them critically and report what the tool got wrong.