Learn Manual QA step by step

Testing can show that defects exist. It can reveal that a login button does not submit, that a password reset link expires too early, or that an API returns private data. But testing cannot prove that there are no bugs. A product can pass many checks and still fail in a case nobody tried.

This matters because beginners often think the job is to confirm that everything works. In real projects, the job is to collect useful information about risk. QA helps the team decide what is safe enough, what is still unknown, and what should be fixed before release.

Exhaustive testing is impossible. Even a simple login page can have many combinations: browser, device, account state, password validity, network speed, session state, security rules, and localization. QA chooses valuable checks instead of pretending every combination can be covered.

QA looks at requirements: what was promised and what behavior should exist? If the requirement says users can log in, QA asks which users, with which credentials, under which account states, and what should happen after login.

QA also looks at user behavior. Real users make mistakes, use old links, forget passwords, paste spaces, use mobile devices, double-click buttons, and leave pages open. Testing should represent real behavior, not only the perfect demo path.

Data is another angle. A feature may behave differently for a new user, an existing user, a locked user, a user with expired subscription, or a user with missing profile data. Technical risk matters too: APIs can fail, sessions can expire, and systems can return inconsistent responses.

The happy path is the expected successful flow. It is important, but it is only the starting point. If a login page accepts valid credentials, that does not mean the feature is ready.

Negative tests check invalid or forbidden behavior. Empty email, wrong password, unknown account, locked account, expired session, and too many attempts are all meaningful. Edge cases check boundaries and unusual states. Usability checks whether people can understand and complete the flow.

Security checks ask how the feature can be abused. A login page should not reveal whether an email exists, should handle brute-force attempts, and should create sessions safely. QA does not need to be a security expert to notice basic abuse risks.

A beginner answer for a login page is often: I will check that login works. That is not wrong, but it is too shallow. It does not show that the tester understands risk.

A stronger answer names concrete flows: valid email and password, invalid password, empty email/password, locked or disabled users, unverified users, remember me behavior, forgot password link, safe error messages, rate limiting, session behavior after login, mobile layout, keyboard navigation, and accessibility basics.

This style is what interviewers and teams look for. You are not trying to list random cases. You are showing that you can move from feature description to practical coverage.