What a QA tester actually does
A QA tester studies a product and asks where it could fail for a real user. That work includes checking expected behavior, finding edge cases, reporting defects clearly, and helping the team decide what needs attention before release.
On a normal day, a tester may review a ticket, ask for clearer acceptance criteria, write test cases, test a new feature, retest a fixed bug, update regression coverage, or join a release discussion. Good testers do not only click around. They make risk visible.
What to save
- Situation: A beginner reviews a checkout change and notices guest checkout, coupon expiry, and payment retry all carry different risks.
- Evidence: The tester names the workflow, the risky conditions, and what evidence would support the release decision.
- Easy miss: The tester clicks the happy path once, marks it passed, and never explains what could hurt a real customer.
Manual testing basics beginners should know
Manual testing is not the beginner version of real testing. It is the base layer. Start with functional testing, exploratory testing, regression testing, smoke testing, boundary value testing, negative testing, and usability observations. If accessibility is new to you, the W3C accessibility principles are a useful first reference.
For a login form, check the happy path first. Then try a wrong password, an empty password, a locked account, mixed case email, copy and paste, browser refresh, password manager behavior, and what happens after too many failures. That is testing with intent.
What to save
- Situation: A login form accepts a valid email, but the tester also tries wrong passwords, locked accounts, empty fields, copy and paste, and too many failed attempts.
- Evidence: The notes cover positive, negative, boundary, and usability observations for the login flow.
- Easy miss: The tester signs in once with a known account and calls the login form tested.
How to think like a tester
Tester thinking starts with questions. Who uses this? What data matters? What could break quietly? What would embarrass the business? What would block the user? What would be annoying but acceptable for one release?
Not every bug has the same risk. A typo on an internal admin label is not the same as a checkout button that charges a customer twice. Beginners often treat every issue as equal. Teams need testers who can explain impact.
What to save
- Situation: A release has both a misspelled label and a payment bug that can double-charge a customer.
- Evidence: The tester explains impact, likelihood, affected users, and why the payment defect needs faster attention.
- Easy miss: The tester reports both issues with the same urgency and gives the team no way to prioritize.
Test cases, bug reports, and risk
A useful test case tells someone what you are checking, what data to use, what steps to follow, and what result should appear. A useful bug report gives clear steps, expected result, actual result, environment, screenshots or logs, and the user impact.
What to save
- Situation: A password reset defect blocks real users but the report only says reset broken.
- Evidence: The report includes steps, expected result, actual result, environment, and impact.
- Easy miss: The developer has to chase the tester for basic reproduction details.
Agile basics for new testers
Most QA testers work close to developers, product owners, designers, and support. Agile basics help you join the conversation early. The Scrum Guide is worth reading once, even if your team does not follow Scrum perfectly, because it explains the words people use in planning.
Ask questions during refinement. If a checkout story says users can apply a coupon, ask about expired coupons, multiple coupons, refunds, taxes, and error messages. That is shift left testing in plain clothes.
API and automation awareness
Beginners do not need to become automation engineers before applying for QA roles. Still, it helps to understand that many products can be tested below the UI. APIs send data between systems, and automated tests can repeat important checks quickly.
Learn what a request and response look like. Learn why a login smoke test might be automated. Learn why automation does not replace exploratory testing. This gives you better language in interviews and helps you choose what to study next.
In practice
A beginner notices that a manual login check passes every time at their desk, but the team’s automated version fails roughly once a day with no obvious pattern.
What helps: The beginner can articulate that works on my machine is not the same as reliable in CI and asks the team what data, environment, or timing differences could explain it.
What gets missed: The beginner assumes automation is broken in general and avoids learning what makes some checks stable and others fragile.
When API requests start showing up in tickets, move next to API Testing for QA Testers and learn how to inspect behavior below the screen.
Beginner practice projects
- Write test cases for a checkout page with cart totals, shipping, taxes, coupons, and payment errors.
- Test a public demo login form and document positive, negative, and boundary cases.
- Create a bug report for a broken password reset flow with screenshots and clear reproduction steps.
- Use a sample API to send a GET request, inspect the response, and record what you would test next.
- Run an exploratory session on a notes app and write a short test summary.
In practice
A learner tests a demo checkout page and creates test cases, one strong bug report, screenshots, and a short risk summary.
What helps: The project leaves behind artifacts another tester or interviewer can read and repeat.
What gets missed: The learner finishes a tutorial video but has no test notes, bug report, or explanation of coverage.
If you want a next step after manual practice, the Manual Tester to Automation Tester Roadmap shows how to choose checks worth automating.
What to put on a beginner QA resume
Show evidence. A beginner resume can include test case writing, bug reporting, exploratory testing notes, sample API checks, and a small portfolio link. Use honest verbs like practiced, wrote, tested, documented, compared, and investigated.
Better: Wrote test cases for login, account settings, and checkout flows. Weaker: Familiar with QA. The first line gives a hiring manager something to picture.
Resume contrast
A beginner writes "familiar with QA tools" while another writes "wrote test cases for login, checkout, and account settings flows using a demo app."
Stronger: each bullet names a feature, a testing action, an artifact, and what risk it covered so a hiring manager can picture the actual work.
Weaker: the resume lists tool names and soft skills with no project, no feature, and no evidence of how the tester actually thinks.
Common mistakes beginners make
- Memorizing definitions without practicing on a real screen. Definitions do not prove you can investigate a product. Practice on a real login, checkout, or account screen so you can explain the setup, the expected result, the actual result, and the user risk.
- Writing bug reports that say broken with no steps or expected result. A developer cannot fix a bug report that only says something is broken. Include steps, test data, expected behavior, actual behavior, environment, and impact so the defect can be reproduced without a follow-up meeting.
- Ignoring risk and treating every defect as urgent. Risk is how teams decide what to fix first. If a typo and a failed payment receive the same urgency, the team wastes time and may ship a customer-blocking defect.
- Trying to learn five automation tools before learning test design. Automation tools are easier to learn after you understand what deserves checking. Without test design, a beginner often automates shallow happy paths and misses the behavior that actually matters.
- Listing credentials or tools on a resume without examples of work. A resume claim needs proof behind it. Pair any tool or credential with a project, bug report, checklist, or API example so the reader sees the work, not just a label.
Better vs weaker evidence
A beginner realizes three weak bug reports all failed because they lacked steps, expected results, and user impact.
Stronger evidence
The next report names the workflow, test data, expected behavior, actual behavior, and risk.
Thin evidence
The same vague notes keep coming back with developer questions instead of fixes.
How to practice
Pick one small feature each week. Test it as if a team will read your notes. Write five to ten test cases, run them, log one strong sample bug, and write a short summary of risk. Rotate between login, checkout, search, account settings, file upload, and notifications.
What to save
- Situation: A beginner spends one week on search and writes what was tested, which data was used, what failed, and what risk remains.
- Evidence: The weekly note includes test cases, a defect example, and a short summary of what to practice next.
- Easy miss: The tester runs checks from memory and cannot explain what changed between sessions.
Prove the fundamentals with AT*SQA
Once you have the basics down, the AT*SQA Testing Essentials AT*SkillStack lets you prove them. It is eight micro-credentials covering Test Approaches, Testing Techniques, Test Automation, Performance Testing, Cybersecurity Testing, Usability Testing, Testing for IoT and Mobile, and DevOps Testing. Each exam is $39, with two open-notes attempts and a full year of validity.
New to studying for exams? AT*SQA’s AT*Learn Testing Essentials training (one-year subscriptions starting at $39) helps you prepare.
Pass all eight and AT*SQA awards you the full Testing Essentials certification at no additional cost, $312 for eight micro-credentials plus the certification. For a first QA role, every credential appears on the Official U.S. List of Certified and Credentialed Software Testers and adds Testing Tiers points, giving a hiring manager something verifiable beyond "completed a tutorial." You can start with one credential at a time.
FAQ
Questions testers ask
Can I become a QA tester without coding?
Yes. Many testers start with manual testing, test design, bug reporting, and product risk. Coding helps later, especially for automation, but it is not the first skill to learn.
What should I practice first?
Practice test cases, bug reports, exploratory notes, and simple risk explanations. A login form, checkout page, and password reset flow are good starting points.
Do I need a credential for my first QA job?
A credential documents learning, but it should sit beside projects, clear examples, and honest resume bullets.
How do I show evidence if I have no QA job yet?
Create a small portfolio with test cases, bug reports, API checks, and short explanations of what you tested and why.
How do I build a QA portfolio if I have never worked as a tester?
Pick two or three public demo apps and create real testing artifacts: test cases, bug reports, exploratory notes, and a short risk summary. Show your thinking, not just screenshots. A small portfolio that explains what you tested and why is stronger than a long list of tools.
What tools should a beginner QA tester learn first?
Start with a browser, a spreadsheet or test case tool, screenshots, basic dev tools, and a simple API client such as Postman. Tools matter only when they support clear testing work. Learn bug reports and test design before chasing automation frameworks.
How do I write a QA bug report that developers will use?
Write the exact steps, expected result, actual result, environment, data used, and user impact. Add a screenshot, video, log, or API response when it helps. A good report saves the developer time and makes the risk obvious.
Can I apply for QA jobs before learning automation?
Yes, especially for manual QA, QA analyst, and entry-level tester roles. You should still understand what automation is for, because teams expect testers to know when repeatable checks should become automated. Use the automation roadmap once your manual basics are solid.
What is the difference between QA testing and just using the app?
Using the app follows the product as a normal user. QA testing deliberately challenges assumptions, checks boundaries, varies data, compares expected and actual behavior, and explains risk to the team.