What testing is for, and what a QA actually does

Most people think testing is "checking that the software works". That is part of it, but if it were the whole story, QA would be a clerical job — and it is not. Testing is a way of managing risk: finding the problems that matter before they reach a customer, and giving the team the information to decide whether to ship. This first lesson is what testing is actually for, what a QA does day to day, and why the role is valuable — the frame everything else in the course builds on.

Testing is about information, not a stamp of approval

A test does not "prove the software works" — you cannot prove that, because you can never try every input, device, network condition and sequence of actions. What a test does is produce information: it tells the team something they did not know — this flow breaks on a slow network, this form accepts a negative amount, this button does nothing on an older phone. Good testing gathers the information that lets the team make a decision: is this good enough to ship, or not?

So the QA's job is not to be a gate that says "approved" or "rejected". It is to be the person who knows the true state of the product — what works, what does not, what is risky — and communicates it clearly, so the people deciding whether to release are deciding with their eyes open. A release is a business decision; QA's job is to make sure it is an informed one.

What a QA does, day to day

The role is more varied than "click through the app". A typical week includes:

Understanding what should happen — reading a requirement, a ticket, or talking to the product owner, and working out what "correct" even means (often the requirement is vague, and finding that out is the first bug).
Designing tests — deciding what to check: the normal cases, the edge cases, the error cases, the combinations. This is a skill (the test-design lessons), not just listing the obvious.
Executing tests — running through them manually, and later, automating the repetitive ones.
Exploring — going off the script to find the problems nobody thought to write a test for (the exploratory-testing lesson).
Reporting bugs — writing them up so a developer can reproduce and fix them, not bounce them back as "cannot reproduce" (a whole lesson, because it is where QAs most often lose credibility).
Regression checking — making sure a new change did not break something that used to work.
Working with the team — with developers (without an adversarial relationship), product, and sometimes customers.

Notice how much of it is thinking — about what could go wrong — and communicating — so the right things get fixed. Clicking is the smallest part.

Why QA is valuable — the cost of finding it late

The reason companies invest in QA is economic: a bug found early is cheap; a bug found by a customer is expensive. A defect caught while testing costs a developer an hour to fix. The same defect shipped to production can mean: a customer's transaction fails and they lose money, support tickets, a bad review, an engineer paged at 2am, an emergency fix, and lost trust. For an app that handles money — a payment, a top-up, a transfer — a bug is not an inconvenience; it can be real money moving to the wrong place. The QA who finds that before release has saved far more than their salary. This is why QA is one of the most common and valuable entry points into the industry (the next lesson quantifies the cost).

Testing is not QA-only, but QA is the specialist

A word on where you fit. In a good team, everyone cares about quality — developers write their own tests (the "testing module" every developer course ends with), and quality is built in, not bolted on. So QA is not "the only people who test". But the QA is the specialist — the person whose full-time job is finding what others missed, who thinks about testing systematically, who tests the whole product the way a user meets it (not just the unit a developer was focused on), and who brings the mindset (next lesson) of actively trying to break things. Developers test that their code does what they intended; QA tests whether the product does what the user needs, including all the ways it might not. Both matter; you are the specialist in the second.

The shape of the work this course prepares you for

This course trains you for QA on the kind of product that is most common on the teams you will join: mobile-first, backed by an API, and often handling money. That shape determines where the interesting testing is:

Mobile — the app runs on a huge range of devices, OS versions, and network conditions (a mid-range Android on patchy mobile data, not a fast laptop on wifi). Much of what breaks is device- and connectivity-specific (the mobile-testing module).
API-backed — behind the app is a backend the app talks to; a lot of the logic (and the bugs) live there, and you can test it directly (the API modules).
Money — transaction flows (a payment, a top-up) are where a bug is most costly and most subtle (double-charge, a failed retry that charges twice, a balance that does not reconcile). These get special attention.

Knowing the shape of what you will test focuses the whole course: not "testing in the abstract", but the QA that matters for real mobile-money-style products.

Check your work

What testing is for. To produce information about the true state of the product (what works, what is risky), so a release is an informed decision — not to "prove it works" (impossible) or be a rubber-stamp gate.

What a QA does day to day. Understand what should happen, design tests, execute them, explore beyond the script, report bugs that get fixed, check regressions, and communicate with the team — mostly thinking about what could go wrong and communicating it, not just clicking.

Why QA is valuable. A bug found early is cheap; one found by a customer is expensive (support, lost money, trust) — for money-handling apps, a bug can move real money wrong. Finding it first saves far more than it costs.

QA versus everyone testing. Everyone owns quality (developers test their own code); QA is the specialist who tests the whole product as a user meets it, systematically, trying to break it — the complement to developer testing.

The shape you are trained for. Mobile-first, API-backed, money-handling apps — so the interesting testing is device/connectivity (mobile), the backend (API), and transaction flows (money).

Practice

Take an app you use daily and, in one paragraph, describe its "true state" as a QA would — what works well, what is annoying or broken, what you would be nervous shipping.
For a feature you know (say, sending money in a payment app), list five things that should happen and five ways it could go wrong. Notice you are already testing.
Estimate the cost of one real bug you have hit as a user (your time, the company's) versus the cost of a tester finding it first.
Distinguish, for one feature, what a developer would test about their code versus what a QA would test about the product.
Write down three things a QA does that are not clicking through the app, and why each matters.
For a mobile-money-style flow (a top-up), name the device, connectivity, and money risks you would want to test.

Official documentation

ISTQB — Foundation syllabus — The standard body of knowledge for the testing profession.
Ministry of Testing — What is software testing? — A large, practical software-testing community and its resources.
Google Testing Blog — Real testing practice from a large engineering org.

Next: quality, and the cost of a bug found late.