QA Fundamentals
Shared QA vocabulary for testing purpose, defects, failures, levels, types, and regression.
Quality assurance is not just finding bugs. It is the discipline of reducing product risk by making important behavior observable, repeatable, and reviewable.
Why teams test
Testing gives teams information about risk. A test does not prove that a product is perfect. It gives evidence about specific behavior under specific conditions.
Good testing helps teams:
- find defects before users do
- verify that key workflows still work after change
- understand release risk
- create evidence for product, engineering, support, and leadership decisions
- learn where the product or process is unclear
Defect, failure, and error
Use these terms consistently:
| Term | Meaning | Example |
|---|---|---|
| Error | A human mistake in thinking, coding, configuration, or process | A developer checks the wrong permission flag |
| Defect | A flaw in the product, data, configuration, or requirement | The checkout button is disabled for valid users |
| Failure | Observable incorrect behavior during execution | A user cannot complete checkout |
In Certyn, a failed run is evidence of a possible failure. A confirmed product problem should become an issue with reproduction steps and artifacts.
Test levels
Different levels answer different questions:
| Level | Main question | Certyn fit |
|---|---|---|
| Unit | Does one small code unit work? | Usually outside Certyn |
| Integration | Do services or modules work together? | Useful when exposed through UI or API flows |
| System | Does the complete product workflow work? | Strong Certyn fit |
| Acceptance | Does the product satisfy user or business expectations? | Strong Certyn fit |
Certyn is strongest for system, acceptance, regression, smoke, and exploratory browser testing.
Test types
| Type | Purpose | Example |
|---|---|---|
| Functional | Check user-visible behavior | A user can reset a password |
| Regression | Check that existing behavior still works after change | Login still works after auth refactor |
| Smoke | Quick confidence check after deploy | App loads, user can sign in, core dashboard renders |
| Exploratory | Learn about behavior while testing | Probe a new onboarding flow for confusing states |
| Security | Look for security risk | Session handling, access control, input handling |
| Usability | Check whether users can complete tasks clearly | Form errors explain what to fix |
| Performance | Check speed and capacity | Checkout remains responsive under expected load |
Confirmation vs regression
Confirmation testing checks whether a specific fix worked. Regression testing checks whether the fix or related change broke something else.
When a bug is fixed:
- Re-run the test or scenario that exposed the bug.
- Add or update coverage so the same failure can be detected again.
- Run nearby workflows that share code, data, permissions, or UI components.
Static vs dynamic testing
Static testing reviews work products without executing the product. Examples include reviewing requirements, designs, code, test cases, and release plans.
Dynamic testing executes the product. Certyn runs dynamic browser tests and records evidence.
Teams need both. Static review catches ambiguity early; dynamic testing confirms behavior in a real environment.
Practical rule
For every important product change, ask:
- What user behavior must still work?
- What changed area is most likely to fail?
- What evidence would convince us it is safe?
- What would make us block, warn, or approve release?