QA Fundamentals
QA Fundamentals
QA (Quality Assurance) is about preventing defects and ensuring software meets requirements, user expectations, accessibility standards, and business goals.
QA is broader than testing.
- QA (Quality Assurance) → Process-focused (prevent problems)
- QC (Quality Control) → Product-focused (find problems)
- Testing → Execution activity to identify defects
Example:
A checkout page fails when discount codes are entered.
- QA asks: Why wasn't this scenario covered?
- QC finds the defect.
- Testing reproduces it.
1. Test Planning
A Test Plan defines what will be tested, how it will be tested, who will test it, and when testing happens.
Typical Test Plan sections:
Objectives
What are we validating?
Example:
Verify checkout functionality works correctly across browsers and devices.
Scope
In Scope
- Product search
- Basket
- Checkout
- Payment gateway
Out of Scope
Test Types
Include:
- Functional testing
- Regression testing
- Accessibility testing
- Performance testing
- Cross-browser testing
- Security testing
Environment
Example:
- QA environment
- Staging
- Production smoke validation
Browsers:
- Chrome
- Edge
- Safari
- Firefox
Devices:
Risks
Example:
| Risk |
Mitigation |
| Delayed requirements |
Clarify early |
| Environment instability |
Use backup test environment |
| Third-party API downtime |
Mock services |
Entry Criteria
Conditions before testing starts:
Example:
- Build deployed
- Requirements approved
- Test environment available
Exit Criteria
Conditions to stop testing:
Example:
- No critical defects open
- 95% test pass rate
- UAT signoff complete
2. Test Cases
A Test Case is a documented set of steps to verify functionality.
Basic structure:
| Field |
Example |
| Test ID |
CHK-001 |
| Feature |
Checkout |
| Objective |
Verify successful payment |
| Preconditions |
User logged in |
| Test Steps |
Add product → Checkout → Pay |
| Test Data |
Visa card |
| Expected Result |
Order confirmed |
| Actual Result |
Filled during execution |
| Status |
Pass / Fail |
| Defect ID |
BUG-123 |
Example:
Test Case: Login
Precondition
User account exists.
Steps:
- Open login page
- Enter valid email
- Enter password
- Click Login
Expected:
- Dashboard loads
- User session created
Positive vs Negative Testing
Positive:
Enter valid credentials → Login succeeds
Negative:
Enter invalid password → Error shown
Boundary:
Password minimum length = 8
Test:
- 7 characters
- 8 characters
- 9 characters
3. Regression Testing
Regression testing ensures:
New changes did not break existing functionality.
Example:
Developer changes checkout tax calculation.
Regression suite validates:
✓ Basket
✓ Discounts
✓ Shipping
✓ Payment
✓ Order confirmation
Regression testing happens:
- New releases
- Bug fixes
- Infrastructure changes
- Browser updates
Good regression suites are:
- Stable
- Repeatable
- Often automated
Typical candidates for automation:
- Login
- Checkout
- Search
- User registration
4. Smoke Testing
Smoke testing answers:
"Is this build stable enough for deeper testing?"
Quick, high-level validation.
Example release smoke test:
| Area |
Test |
| Homepage |
Loads |
| Login |
Works |
| Search |
Returns results |
| Checkout |
Opens |
| Payment |
Can initiate |
If smoke fails:
❌ Testing stops
❌ Build returned to development
Think:
Smoke = Build verification
Usually 5–30 minutes.
5. Sanity Testing
Sanity testing validates:
"Did the specific fix/change actually work?"
Smaller and focused.
Example:
Bug fixed:
Discount code SAVE10 not applying.
Sanity tests:
✓ SAVE10 works
✓ Basket total updates
✓ Tax recalculates
No need to test full checkout.
Think:
Sanity = Change verification
Smoke vs Sanity
| Smoke |
Sanity |
| Broad |
Narrow |
| Build stability |
Specific change validation |
| Before detailed testing |
After bug fix/change |
| Short suite |
Very focused |
| Entire system areas |
One impacted area |
Example:
New release deployed:
→ Run Smoke
Developer fixes payment timeout:
→ Run Sanity
6. UAT (User Acceptance Testing)
UAT validates:
"Does the software meet business/user needs?"
Usually performed by:
- Business users
- Product Owners
- SMEs
- Client stakeholders
QA supports but often does not own signoff.
Example eCommerce UAT scenarios:
Business flow
Customer:
- Search product
- Add to basket
- Apply promotion
- Checkout
- Receive confirmation email
Business validates:
✓ Process matches expectations
✓ Promotions behave correctly
✓ Reports updated
UAT entry criteria:
- QA complete
- Major defects resolved
- Stable environment
UAT exit criteria:
- Business approval
- Critical defects fixed
- Signoff obtained
Simple release flow
Requirements
↓
Test Planning
↓
Test Case Creation
↓
Development
↓
Smoke Testing
↓
Functional Testing
↓
Regression Testing
↓
Accessibility Testing
↓
UAT
↓
Production Deployment
↓
Production Smoke Check
