Manual QA Engineer Course: Testing Strategies, STLC, and Interview Prep
What is Manual QA Testing?
Manual QA (Quality Assurance) is the practice of manually testing software applications to identify defects, verify functionality, and ensure the application meets quality standards. A Manual QA engineer manually executes test cases, navigates the application, and reports bugs โ without relying on automated test scripts.
While automation testing has gained popularity, manual testing remains absolutely essential in software development. Automation cannot replicate human judgment, creative problem-solving, or user experience validation. The best QA teams combine both manual and automated testing strategies.
Manual QA vs Automation Testing
Many companies hire both manual QA engineers and automation engineers because each discipline has unique strengths:
- Manual QA: Better at exploratory testing, finding unexpected issues, validating UX, testing new features without existing test infrastructure.
- Automation: Better at regression testing, running repetitive tests, testing across browsers/devices in parallel, catching regressions fast.
- Combined approach: Use manual testing for exploratory testing and new features. Use automation for regression testing and CI/CD pipelines.
Role of a QA Engineer
Top Interview Questions
What is the difference between QA and QC?
QA (Quality Assurance): Process-oriented, prevents defects through process improvement.
QC (Quality Control): Product-oriented, detects defects through testing. QA is about "doing things right," QC is about "doing the right things."
What is STLC and what are its phases?
Software Testing Life Cycle (STLC) is a systematic process for testing software. Phases: Planning โ Analysis โ Design โ Execution โ Closure. Each phase has specific deliverables and entry/exit criteria.
What are the types of testing?
Functional: Features work as specified. Non-functional: Performance, security, usability. Regression: Existing features still work. Smoke: Quick sanity check. UAT: End-user validation.
What's the SDLC and how does testing fit?
Software Development Life Cycle (SDLC) covers entire development. Testing is integrated in each phase. QA should be involved from requirements gathering through deployment for early defect detection.
What makes a good test case?
Good test cases are: Clear and specific, Include preconditions, Have step-by-step actions, Define expected results, Cover both positive and negative scenarios, Are reusable and maintainable.
What is a test plan?
A test plan documents testing strategy, scope, objectives, timeline, resources, testing tools, test environment setup, and risk assessment. It's the blueprint for all testing activities.
Components of a Test Case
| Component | Description |
|---|---|
| Test Case ID | Unique identifier (e.g., TC001) |
| Title | Clear description of what's being tested |
| Preconditions | System state before test starts |
| Steps | Clear, numbered, sequential actions |
| Expected Result | Desired outcome after each step |
| Actual Result | What actually happened (filled during execution) |
| Status | Pass, Fail, or Blocked |
Best Practices
Use Clear Language
Write in simple, understandable terms. Avoid jargon. Make it easy for anyone to execute the test case.
Cover Edge Cases
Include positive, negative, and boundary value test cases. Think about what could go wrong.
Include Data Inputs
Specify exact data values to use. Make tests reproducible and clear.
Make Tests Independent
Each test case should stand alone. Don't rely on previous test execution.
Use Consistent Naming
Follow naming conventions. Use meaningful IDs and titles for easy reference.
Version Control & Review
Track changes to test cases. Have team members review for quality.
What's the difference between test case and test scenario?
Test scenario is a high-level user journey or business flow. Test case is a detailed step-by-step procedure with expected results for that scenario.
How do you identify test cases?
Read requirements carefully, extract functional and non-functional requirements, identify edge cases, apply boundary value analysis (BVA) and equivalence partitioning (EP).
What is boundary value analysis?
BVA tests values at the boundaries of input ranges. For age (1-100): test 0, 1, 100, 101. Boundary values are more likely to reveal bugs than mid-range values.
What is equivalence partitioning?
Divide input data into equivalent classes where each class should behave the same. Test one value from each class. Reduces test cases while maintaining coverage.
How do you ensure test case coverage?
Use requirements traceability matrix (RTM) to map each requirement to test cases, review with stakeholders, apply multiple techniques (BVA, EP, state transitions), and aim for high coverage.
Functional Testing Types
Unit Testing
Individual functions/modules tested at developer level for basic correctness.
Integration Testing
Multiple modules tested together to ensure they work correctly as a group.
System Testing
Complete application tested as a whole against specifications and requirements.
Smoke Testing
Quick sanity check on critical features to determine go/no-go for deeper testing.
Regression Testing
Verify that existing features still work after code changes or new features.
UAT Testing
End-user validation of business requirements and overall system functionality.
Non-Functional Testing
Performance Testing
Measure response time, throughput, and resource usage under various loads.
Security Testing
Identify vulnerabilities, test authorization, encryption, and data protection.
Usability Testing
Evaluate user experience, interface intuitiveness, and user satisfaction.
Compatibility Testing
Verify application works across different browsers, OS, and devices.
Load Testing
Test behavior under expected user volume and concurrent user scenarios.
What's tested in functional vs non-functional testing?
Functional: Features, workflows, data accuracy against requirements. Non-functional: Performance, security, usability, reliability, portability. Both are essential for complete quality assurance.
When do you choose smoke vs regression testing?
Smoke testing is quick validation of major features after builds (go/no-go decision). Regression is comprehensive testing after changes to ensure nothing broke. Smoke is first pass, regression is thorough.
What is UAT and who performs it?
User Acceptance Testing is validation by end-users that the system meets business requirements. Performed by business analysts, product owners, and actual end-users. Requires formal sign-off.
Waterfall Phases
Requirements
Gather and document all requirements from stakeholders and business.
Design
Create architecture and design documents based on requirements.
Development
Code is written by developers based on design specifications.
Testing
QA tests complete application (STLC begins here) against requirements.
Deployment
Release the tested application to production environment.
Maintenance
Provide support, fix bugs, and handle production issues.
Characteristics
Fixed Requirements
Requirements are locked early in the project.
Clear Timeline
Each phase has defined start and end dates.
Sequential Phases
Each phase must complete before next begins.
Comprehensive Documentation
Detailed docs at each phase for reference and compliance.
Limited Flexibility
Changes are costly and difficult to implement.
Late Testing
Testing happens after development, leading to late bug discovery.
When is Waterfall appropriate?
For fixed-scope projects with stable requirements. Projects where changes are costly. Government/regulated industries. Large teams with clear roles. Not suitable for projects needing frequent changes.
What are advantages and disadvantages of Waterfall?
Advantages: Clear structure, comprehensive documentation, easy to manage large teams. Disadvantages: Testing late in cycle, late defect detection, hard to accommodate changes, risk concentrated at end.
What's the QA testing timeline in Waterfall?
QA testing begins only after development is complete. Testing is concentrated in one phase. If critical bugs found, fixes push timeline back significantly. This is why early QA involvement is crucial.
How can you improve testing in Waterfall?
Get involved early in requirements review, create test cases before development, use static testing (reviews) early, plan for comprehensive regression, use automation for repetitive tests, document everything.
Agile Testing Cycle
Sprint Planning
Define sprint goals, select user stories, estimate effort and create testing tasks.
Daily Development
Code and test features daily with continuous integration and feedback.
Continuous Testing
QA tests features as they're developed, not waiting until end of sprint.
Sprint Review
Demonstrate completed features to stakeholders for feedback.
Retrospective
Team reflects on what worked and what to improve in next sprint.
Repeat
Next sprint begins immediately with improved processes.
Key Concepts
User Stories with Acceptance Criteria
Clear definition of what needs to be tested and accepted.
Daily Stand-ups
Quick syncs to identify blockers and plan daily work.
Pair Testing with Developers
QA and developers work together for better understanding.
Definition of Done
Includes testing, so features only marked complete when tested.
Continuous Integration & Testing
Automated tests run constantly for quick feedback.
Quick Feedback Loops
Bugs discovered and fixed within same sprint.
What's the QA role in Agile sprint planning?
QA estimates test effort for stories, identifies test scenarios, breaks down testing tasks, flags risks early, ensures acceptance criteria are testable, prepares test data, and collaborates on story refinement.
What is Definition of Done in Agile?
Checklist for user story completion: Code written, Code reviewed, Unit tests pass, Features tested (QA), Documentation updated, Regression tests pass, Ready for production. Varies per team.
How is testing continuous in Agile?
QA tests features as soon as they're developed, not at the end. Daily testing provides quick feedback. Bugs are fixed within the sprint. Automated tests run continuously. Testing is everyone's responsibility.
What challenges does Agile present for QA?
Rapid pace requires fast testing, limited time for comprehensive testing, need for automation skills, constant context switching, unclear requirements (user stories), limited documentation, pressure to keep up with velocity.
How do you handle testing in a 2-week sprint?
Work in parallel with developers, test as features are built, prioritize critical paths, automate repetitive tests, use exploratory testing for new features, complete testing before sprint end, communicate blockers immediately.
V-Model Structure
Right Side (Validation): Unit Testing โ Integration Testing โ System Testing โ UAT (bottom-up)
Each development level has corresponding testing level.
Key Characteristics
One Phase Per Level
Each development level matched with corresponding testing level.
Clear Entry/Exit Criteria
Each phase has defined start and end conditions for quality gates.
Emphasis on Documentation
Detailed documents created at each phase for traceability.
Early Test Planning
Test cases designed while development is being planned.
Traceability
Clear mapping between development and testing phases.
Regulated Industries
Works well for government and regulated industry projects.
How does V-Model differ from Waterfall?
Waterfall is linear. V-Model parallels testing with development. V-Model has explicit verification and validation. V-Model requires earlier test planning. Both are sequential, but V-Model is more thorough about testing phases.
What's the relationship between left and right sides?
Left side (requirements โ design โ code) is matched by right side (UAT โ system โ integration โ unit). Each coding level has a corresponding test level. For example, system design is validated by system testing.
What is verification vs validation?
Verification: Are we building the product correctly? (Testing against specs)
Validation: Are we building the right product? (Testing against requirements). Both are essential for quality.
How do you ensure traceability in V-Model?
Create RTM (Requirements Traceability Matrix) mapping requirements to design to code to test cases. Ensure each requirement has corresponding test case. Track coverage at each level. Document all dependencies.
When to Perform Regression Testing
After Bug Fixes
Test related features to ensure the fix doesn't break them.
New Features Added
Verify existing features still work after new code integration.
Before Release
Comprehensive testing before going to production.
After Configuration Changes
Test after changing system settings or parameters.
Environment Changes
Test after upgrading OS, database, or middleware.
Patch/Upgrade Installation
Verify system still functions after applying patches or upgrades.
Regression Testing Strategies
Full Regression
Re-test entire application. Time-consuming but thorough and provides confidence.
Partial Regression
Test only affected modules. Faster approach, risk-based and targeted.
Smoke Testing
Quick check of critical paths. Gates whether further testing should continue.
Selective Testing
Test specific features based on impact analysis of changes.
When do you run regression tests?
After any code change. High priority after bug fixes and new features. Before every release. The sooner you catch regressions, the cheaper they are to fix.
How do you choose a regression strategy?
Based on impact analysis, time constraints, and risk. After minor fixes: smoke test. After major changes: partial regression. Before release: full regression. Automate for faster execution.
What's the relationship between regression and automation?
Manual regression is time-consuming. Automation makes regression testing faster and repeatable. Build automated regression suite for critical paths. Still use manual testing for new features and exploratory areas.
Key Characteristics
Learn While Testing
Discover product behavior and edge cases simultaneously.
No Predefined Test Cases
Tests are designed and executed on-the-fly based on findings.
Creative Bug Finding
Testers use experience and intuition to find unexpected bugs.
Follow Discoveries
Based on findings, explore deeper to understand impact.
Time-Boxed Sessions
Usually conducted for 1-4 hours with defined scope.
Document Findings
Create detailed notes and screenshots of discoveries for reproducibility.
Exploratory Techniques
User Journey Tours
Follow typical user workflows and business processes.
Feature Tours
Explore each feature deeply and systematically.
Risk-Based Tours
Focus testing on high-risk areas and critical features.
Role-Based Tours
Test from different user perspectives (admin, user, guest).
Checklist-Based
Use testing guidelines but stay flexible to adapt.
When do you use exploratory testing?
For learning about new features, finding edge cases, validating UX, when requirements are vague, when time is limited, to complement scripted testing.
What are advantages of exploratory testing?
Finds bugs scripted tests miss โข Tests user experience โข Builds product knowledge quickly โข Adapts to unexpected behavior โข Cost-effective for new features โข Doesn't require test case design upfront.
How do you document exploratory testing?
Session notes with date/tester/duration, features tested, findings, screenshots of bugs, assumptions, follow-up tests. Detailed enough for others to understand discoveries.
Defect States
New
Just logged by QA, awaiting triage and review.
Open
QA verified the issue, assigned to developer for fixing.
In Progress
Developer is actively working on the fix.
Fixed
Developer marked the issue as resolved and completed.
Verified
QA confirms the fix works and issue is resolved.
Closed
Issue is officially resolved and closed in system.
Severity vs Priority
Critical
Application crash, data loss, major functionality broken.
High
Major feature broken, significant workaround needed.
Medium
Feature partially works, minor impact on functionality.
Low
Minor issue, easy workaround exists, cosmetic issue.
Priority P0 (ASAP)
Fix immediately, impacts production or customers.
Priority P3 (Backlog)
Fix when possible, low business impact, can wait.
What information must a bug report contain?
Title, environment (OS/browser), steps to reproduce, expected vs actual result, screenshots/logs, severity, priority, assigned to. Clear enough for anyone to reproduce.
What's the difference between severity and priority?
Severity is technical impact (how broken is it?). Priority is business decision (when should we fix it?). A typo in logo is low severity but can be high priority.
How do you handle bug reopening?
If issue recurs, reopen with new evidence. If partially fixed, comment with details. If developer questions fix, provide clear reproduction steps. Collaborate respectfully, focus on getting quality fixed.
What causes bugs to be rejected or closed?
Not reproducible, duplicate of existing bug, working as designed, not enough info, workaround exists. Always document reason for closure. Allow reopening if new evidence appears.
Advanced Concepts
Risk-Based Testing
Prioritize testing based on risk probability and impact of failure.
Requirements Traceability Matrix
Map requirements to test cases to defects for complete coverage.
Test Data Management
Create realistic data for comprehensive and effective testing scenarios.
Defect Prevention
Use root cause analysis to prevent similar bugs in future.
Communication Skills
Effective stakeholder and team interactions for quality collaboration.
Test Metrics
Measure and track quality indicators for process improvement.
Shift-Left Approach
Early Involvement
Get QA involved early in requirements and design phases.
Design Reviews
Participate in architecture and design reviews for quality input.
Test Case Creation
Create test cases before development begins.
Static Testing
Perform code reviews and requirement reviews early.
Quality Gates
Establish checks to prevent low-quality code from advancing.
Defect Prevention
Prevent defects rather than just finding them after development.
What is risk-based testing?
Prioritize testing effort on high-risk areas. Identify risks early, assess probability and impact, allocate more test cases to critical areas, less to low-risk components. Optimizes testing time and resource efficiency.
How do you create and maintain an RTM?
Map each requirement to test cases, document coverage percentage, link to defects, update when requirements change, track test execution status. Ensures no requirements are untested.
What is shift-left testing?
Shift testing activities left in the timeline (earlier in SDLC). Participate in requirements reviews, design reviews, code reviews. Find defects early when they're cheap to fix.
How do you perform root cause analysis on defects?
Use techniques like 5 Whys or Fishbone Diagram. Ask why the defect occurred, why tests didn't catch it, why process allowed it. Implement preventive measures for similar bugs.
What metrics indicate testing effectiveness?
Test coverage %, defect density, bug escape rate, test effectiveness ratio (bugs found/total bugs), testing ROI. Monitor trends over time to improve process.
How do you communicate test results to executives?
Focus on business impact, not technical details. Use metrics like quality score, risk assessment, release readiness. Executive summary with key findings and recommendations.
Common Scenarios
You find a critical bug 1 hour before release. What do you do?
Immediately report with full details and reproduction steps. Escalate to stakeholders. Provide risk assessment. Let them decide on release vs delay. Document decision.
Requirements are unclear. How do you write test cases?
Ask clarifying questions in requirements meetings. Create test cases based on best interpretation. Flag assumptions in test documentation. Get stakeholder sign-off before execution.
A developer says your bug report is "not reproducible". How do you respond?
Provide detailed steps with exact data. Include screenshots/logs. Offer to pair test with developer. Provide environment details. Ask specific questions about their testing steps.
You've tested 80% but time is running out. What's your priority?
Focus on critical and high-priority features. Document what's untested and why. Provide risk assessment for untested areas. Discuss options with stakeholders.
You found a "weird" behavior but can't call it a bug. How do you report it?
Document as detailed observation. Include reproduction steps. Provide context. Ask stakeholders if this is expected behavior. Let them decide if it's a defect or feature.
Before the Interview
Research the Company
Understand their products, tech stack, and market position.
Study Their Products
Use their products, find bugs, think about QA challenges.
Review Common Questions
Prepare answers to typical QA interview questions.
Prepare Examples
Have real examples of bugs you found and how you solved them.
Test Your Setup
Check camera, microphone, internet connection, and lighting.
During the Interview
Ask Questions
Show genuine curiosity about the company and role.
Use STAR Method
Situation, Task, Action, Result when answering behavioral questions.
Be Specific
Use real examples, not hypotheticals or generic answers.
Listen Carefully
Answer what's asked, don't go off on tangents.
Show Enthusiasm
Demonstrate passion for testing and the company.
Discuss Trade-offs
Show maturity by acknowledging there's no perfect answer.
Essential QA Traits to Highlight
Detail-Oriented
Catch subtle issues that others miss.
Communicative
Clear bug reports and effective team collaboration.
Curious and Analytical
Ask "what if?" and understand system behavior deeply.
Problem-Solver
Find root causes and suggest improvements.
Patient
Handle repetitive work and tedious testing scenarios.
Collaborative & Adaptable
Work with different teams and learn new tools quickly.
Common Acronyms
STLC
Software Testing Life Cycle โ systematic testing process phases.
SDLC
Software Development Life Cycle โ entire development process.
QA / QC
Quality Assurance (process) / Quality Control (product).
RTM
Requirements Traceability Matrix โ mapping requirements to tests.
BVA
Boundary Value Analysis โ testing at input range boundaries.
EP
Equivalence Partitioning โ dividing input into equivalent classes.
UAT
User Acceptance Testing โ end-user validation phase.
API
Application Programming Interface โ backend service testing.
Test Execution Checklist
Test Environment Ready
All systems, data, and tools set up correctly.
Test Data Prepared
Valid, invalid, and edge case data ready to use.
Test Cases Reviewed
All test cases reviewed and approved by team.
Smoke Tests Pass
Critical features verified before full test execution.
Full Test Execution
All test cases executed and results documented.
Defects Logged
All issues documented with full details for reproduction.
Regression Complete
Retesting after bug fixes to ensure no new issues.
Report Generated
Final test report with metrics, summary, and sign-off.
Best Practices
Common Challenges
Insufficient test coverage
Cause: Vague requirements or tight timelines. Solution: Create RTM, prioritize critical features, request requirements clarification.
Repeated bugs in production
Cause: Poor test case design or rushed testing. Solution: Root cause analysis, update test cases, implement automation for critical paths.
Communication gaps with dev
Cause: Unclear bug reports or misunderstanding. Solution: Use clear reproduction steps, include screenshots/videos, schedule sync meetings.
Time constraints
Cause: Aggressive timelines. Solution: Prioritize by risk, use automation for regression, focus on critical paths.
FAQs
What testing types should manual QA focus on?
UI/UX, usability, exploratory, smoke, sanity, regression, and UAT. Automate routine checks; use manual testing for complex scenarios.
How do I prioritize tests?
Use risk-based testing: prioritize critical features, high-risk areas, frequently used flows. Test high-impact items first.
When should I switch to automation?
Automate: repetitive tests, regression tests, data-intensive tests. Keep manual: exploratory, ad-hoc, UX validation.
How do I report effective bugs?
Include: title, severity, steps to reproduce, expected vs actual, screenshot, environment details. Make it actionable.
What's the ideal test case format?
ID, Title, Preconditions, Steps (numbered), Expected Result, Actual Result, Status, Date, Tester. Use templates for consistency.
How do I manage test data for manual tests?
Use realistic data, handle edge cases (empty fields, max values, special characters). Reset data after tests using DB scripts.