My own working notes on Quality Assurance — definitions, process, testing types, and terminology — written while I learn QA alongside frontend development.
Most people think QA means clicking around an app looking for bugs. That's only a small part of it.
Quality Assurance (QA) is the set of activities that ensure a software product meets its requirements and works reliably for the people who use it — before it ever reaches them.
QA isn't a single step at the end of development. It's a mindset applied throughout the entire process: reviewing requirements, designing test cases, executing tests, tracking defects, and confirming fixes.
The process. Focused on preventing defects by improving the process itself — planning, standards, and reviews before code is even written.
The product. Focused on identifying defects in the actual product — checking whether the built feature meets the requirement.
The activity. The specific act of executing a system to find defects — one activity that lives inside QC, which lives inside QA.
A simplified version of the Software Testing Life Cycle.
Review requirements for gaps, ambiguity, or things that can't actually be tested as written.
Decide scope, approach, resources, and schedule — what gets tested, how, and by whom.
Write specific, repeatable test cases and test data covering normal use, edge cases, and failure conditions.
Run the test cases manually or through automation, and record what passed and what failed.
Log failures as clear bug reports with steps to reproduce, expected vs. actual result, and severity.
Confirm the fix works, and re-run related tests to make sure nothing else broke because of it.
The core categories every QA learner runs into early.
Does the feature do what it's supposed to do?
Did a new change break something that used to work?
Quick check that the build is stable enough to test further.
Narrow, focused check after a small fix or change.
Do separate modules work correctly together?
Does it meet real user needs, tested by actual stakeholders?
How does it behave under load, stress, or many users?
Can the system be broken into or misused?
Is it actually easy and clear for a real person to use?
Does it work across browsers, devices, and screen sizes?
Do requests and responses behave correctly at the API layer?
Scripting repetitive tests so they run without manual effort.
Best for exploratory testing and new features. Good at catching usability issues a script would miss. Slower to repeat across every release.
Best for repetitive regression checks. Fast and consistent once written and maintained. Doesn't replace human judgment or exploratory testing.
A documented set of steps, inputs, and expected results used to verify one specific behavior.
A document outlining scope, approach, resources, and schedule for a testing effort.
An actual flaw in the code that causes it to behave incorrectly.
How badly a defect affects the system technically — e.g. crashes vs. cosmetic issue.
How urgently a defect needs fixing from a business perspective, independent of severity.
Re-testing previously working features after a change, to confirm nothing broke.
Software Testing Life Cycle — the structured sequence of testing phases within a project.
An input or condition at the extreme boundary of what's expected — often where bugs hide.
These notes will keep growing as I go deeper into QA.