Programming and Software Development
Software testing and QA
Testing is the discipline of finding out how software behaves before its users do, and of saying clearly what was and was not checked. It has its own vocabulary, its own design techniques and a certification scheme recognised across employers, and few routes into software reward scepticism over typing speed as this one does.
Why this topic exists: Testing as a discipline: the ISTQB Foundation syllabus v4.0.1 (fundamentals, testing through the lifecycle, static testing, analysis and design, managing test activities, tools) plus the automation frameworks (Selenium, Cypress, Playwright).
More than finding bugs
A passing test proves only that one case behaved as expected on one day. Testing as a discipline accepts that no system can be checked completely and asks where limited effort should go so that the failures which would hurt most are found first. The ISTQB Foundation syllabus, the reference most employers share, frames the work as both verification (was it built as specified?) and validation (does it meet the need?), and counts reviewing a requirement before any code exists as testing too. SFIA reaches a similar shape from another side, listing functional testing and non-functional testing, for qualities such as performance, security and scalability, as separate skills.
| CTFL v4.0.1 chapter | What it means at work |
|---|---|
| Fundamentals | Why testing is needed, its principles, the activities involved and the roles on a test team |
| Testing across the lifecycle | Component, integration, system and acceptance levels; functional and non-functional types; retesting after maintenance |
| Static testing | Reviewing requirements, designs and code without running anything, where defects are cheapest to remove |
| Analysis and design | Black-box, white-box and experience-based techniques for choosing cases, plus approaches worked out jointly with developers and product owners |
| Managing test activities | Planning, risk, tracking progress, configuration management and defect reports someone can act on |
| Tools | What tool support offers, and what automation costs and risks |
The design techniques are where testing stops being guesswork. Equivalence partitioning groups inputs that should behave alike, so one case can stand for many. Boundary value analysis tests the edges of those groups, where off-by-one errors live. Decision tables cover combinations of conditions, and state transition testing walks a system through its permitted sequences. White-box techniques measure which statements and branches the tests actually reached. Experience-based testing, including exploratory sessions guided by a short charter, finds what the formal techniques failed to anticipate.
Automation, and where it goes wrong
Automation turns repeatable checks into code that runs on every change. Unit frameworks such as pytest, JUnit and Jest sit closest to the code; API tests call services directly; browser tools drive the real interface. Selenium, built on the WebDriver standard, is the long-established option across many languages and the one MDN's testing module sets up. Cypress runs inside the browser and suits JavaScript teams, while Playwright drives several browser engines from one script. The classic mistake is automating nearly everything through the user interface. Those tests are slow, break when a button moves and fail for reasons unrelated to any defect, until the team stops trusting them. A healthy suite has many fast, narrow tests and few broad ones.
Testing jobs range from test analysts through automation engineers to developers who specialise in test infrastructure, and the ISTQB scheme follows that spread. CTFL supplies the shared vocabulary and is the prerequisite for almost everything above it; CTAL-TA goes deeper on deciding what to test; CTAL-TAE treats an automation suite as software with an architecture of its own. Developers learn the habit of testing their own work first in software engineering practice, and pipelines that run every suite on every change belong to DevOps and CI/CD.
Next to this topic
- Programming fundamentalsOne language learned properly plus enough of the machine beneath it: variables, control flow, data structures, debugging and reading code (SFIA Programming/software development; MDN's getting-started modules).
- Programming languagesPython, JavaScript, Java, C#, C and C++, Go, TypeScript, Rust, Kotlin, Swift: what each is for and where it is hired, so the first choice is a career decision rather than a syntax preference (Udemy's Programming Languages shelf names the market).
- Web developmentHTML, CSS and JavaScript, then a framework and the browser's APIs: MDN's core and extension modules are the syllabus of the largest development field.
- Back-end development and APIsServers, frameworks, databases behind them and the HTTP and REST contracts between services (MDN server-side modules; DVA-C02; the freeCodeCamp back-end certificate).
- Mobile developmentiOS, Android and the cross-platform frameworks are their own toolchains, stores and review rules (SFIA Systems development; Udemy's Mobile shelf).
- Databases and SQLThe relational model, SQL, schema design and the document and key-value stores next to it: the layer every application and every analyst stands on (SFIA Database design; DP-900 relational concepts).
- Software engineering practiceVersion control, code review, testing habits, architecture, design patterns and clean code: the slow layer hiring quietly filters on (SFIA Systems and software lifecycle engineering; MDN version-control module).
- DevOps, Git and CI/CDVersion control workflows, pipelines, containers for developers and the culture that joins build and run (AZ-400; GitHub Foundations and Actions; the cloud field owns infrastructure as code and operations).
- Game developmentEngines, graphics, physics and the design loop are a development field with its own tooling and job market (Udemy's Game Development shelf; SFIA Animation development).
- No-code and low-code developmentBuilding software without writing most of it (Bubble, Webflow, Zapier, Make, Airtable) is a recognised route into shipping products; Microsoft's Power Platform is the office-suite version of the same idea.
- AI-assisted developmentAssistants changed how fast plausible code appears, not what makes it correct; reading, testing and correcting generated code is now part of the craft (GitHub certifies Copilot use and, on its 2026 credentials page, agentic AI development).
Concepts to know
Glossary entries with the reason each one matters here.
Certifications that test it
Vendor exams and free certificates; facts, cost and the preparation path are on each page, and the certifications hub has them all.
- ISTQB · CTFL v4.0ISTQB Certified Tester Foundation Level (CTFL) v4.0The Foundation Level syllabus is this topic.
- ISTQB · CTAL-TA v4.0ISTQB Advanced Level Test Analyst (CTAL-TA) v4.0Test analyst, the advanced level.
- ISTQB · CTAL-TAE v2.0ISTQB Advanced Level Test Automation Engineering (CTAL-TAE) v2.0Test automation engineering.
Tools of the trade
- Selenium and Playwright
Browser automation frameworks.
- Postman
API testing's workbench.
Frequently asked
- Do I need to code to work in software testing?
- Not for every role. Test analysts designing cases and exploring systems can work with little code, but automation roles are development jobs, and most QA adverts now expect at least enough scripting to read and maintain an existing suite.
- Is ISTQB Foundation worth taking?
- It is the one credential in this field that testers are commonly asked about by name, and it gives a team a common language for levels, techniques and defect reports. It proves vocabulary rather than skill, so pair it with examples of test design or automation you can show.
- Selenium, Cypress or Playwright?
- Learn whichever the teams you want to join already use; the concepts of locators, waits, fixtures and isolation carry over. Selenium has the widest language support and the longest history, Cypress suits JavaScript front ends, and Playwright covers several browser engines from one test.
- Is software testing a route into development?
- Often. Testers learn how a system fails, read code in reviews and, in automation roles, write it every day. The move is smoothest for testers who already maintain an automated suite and contribute to the pipeline that runs it.
Courses in the directory
425 courses are filed here; the top 6 by our ranking, details and the provider link on each course page.
Last reviewed 26 September 2026 · Getting Digital