81. What is Mutation Testing?
Answer:
Mutation Testing is a white-box testing technique used to evaluate the effectiveness of the test cases. In this method, small changes (mutations) are made to a program’s source code to create a mutant version of the program. These changes could include altering an operator, modifying a variable, or changing a constant.
The goal is to check whether existing test cases can detect the mutations. If they do, the mutant is said to be “killed”; if not, it survives—indicating the test suite may be weak and needs improvement.
Example:
If a condition in code is if(a > b) and the mutation changes it to if(a < b), then the test case must fail or detect this logical error. If not, it means the test case is not robust.
Q82. What is Error Guessing? When is it used?
Answer:
Error Guessing is a technique based on intuition, experience, and domain knowledge of the tester to identify possible areas of defects in an application. Unlike structured techniques like boundary value analysis or equivalence partitioning, error guessing relies heavily on the skill and past experiences of the tester.
When is it used?
- When testing complex or critical applications
- At the final stages of exploratory testing
- When conventional techniques fail to find deep or hidden bugs
Example:
If a tester knows that a login page often fails with special characters in usernames, they may deliberately input !@#User123 to check for issues.
Q83. How do you handle exploratory testing in agile environments?
Answer:
Exploratory testing in agile is highly effective because:
- Agile environments encourage continuous testing
- There’s often limited time for documentation, making exploratory testing suitable
- Testers can quickly validate features as they are developed
Approach:
- Start with understanding user stories and acceptance criteria.
- Perform session-based exploratory testing (time-boxed).
- Note down observations and defects immediately.
- Use mind maps or charters to track areas tested.
- Collaborate with developers and product owners for clarification.
Q84. Explain how you manage risk-based testing in a real-world project.
Answer:
Risk-based testing is the process of prioritizing testing efforts based on the impact and probability of risks. In real projects, it’s not possible to test everything, so resources are focused on high-risk areas.
Steps to implement:
- Identify risks – technical, business, security, etc.
- Assess likelihood and impact (High, Medium, Low)
- Prioritize test cases accordingly
- Monitor and re-evaluate risks throughout the project
Example:
A banking app module handling payments may have higher priority than a theme customization module, due to higher risk.
Q85. What is Configuration Management in testing?
Answer:
Configuration Management (CM) is a discipline for managing and controlling the evolution of software test artifacts like test cases, scripts, data, environment, and documentation across different builds.
Importance in Testing:
- Ensures consistency and traceability across multiple test cycles
- Allows testers to reproduce defects accurately
- Helps in managing changes due to version upgrades
Tools: Git, SVN, Jenkins, Azure DevOps, etc.
Q86. How do you test APIs manually without automation tools like Postman?
Answer:
APIs can be tested manually using:
- Browser for GET calls (e.g., entering https://api.example.com/users)
- Command-line tools like CURL
Example with CURL:
bash
curl -X POST https://api.example.com/login -H “Content-Type: application/json” -d ‘{“username”:”admin”,”password”:”admin123″}’
Key Aspects to Check:
- Status Codes (200 OK, 401 Unauthorized, etc.)
- Response Time
- Headers (Content-Type, Authorization)
- Payload data validation
Q87. What is Defect Triage and how is it conducted?
Answer:
Defect Triage is a process where the team reviews, prioritizes, and assigns defects for resolution based on severity, priority, and business impact.
Key Participants:
- QA Lead
- Development Lead
- Product Owner
- Project Manager
Steps in Triage:
- Review each defect
- Confirm its validity and severity
- Set the priority for fixing
- Assign it to the appropriate developer or module team
Q88. Describe how you would do performance testing manually.
Answer:
Though performance testing is largely automated, manual performance testing involves:
- Measuring page load times using browser developer tools (like Chrome DevTools → Network tab)
- Simulating concurrent users using multiple browsers or machines
- Recording memory usage and CPU load on the client system
However, for real scenarios, tools like JMeter, LoadRunner, or BlazeMeter are preferred.
Q89. How do you test security aspects of a web application manually?
Answer: Manual security testing includes:
- Input Validation Testing – trying SQL injection (‘ OR 1=1 –) or script injection (<script>alert(‘test’)</script>)
- Authentication Bypass – tampering with cookies or session tokens
- URL Manipulation – manually changing ID in URL (e.g., /user/1001 to /user/1002)
- Session Management – testing session expiration and logout functionality
Tools often used manually: Burp Suite, OWASP ZAP (though semi-automated)
Q90. How do you approach test data management in a live environment?
Answer:
Test data management in a live or production-like environment requires careful planning:
- Use masked or anonymized data to protect PII
- Use data subsetting to extract only necessary rows
- Create scripts for data creation and cleanup
- Separate test and production data using tags or environment flags
Best Practices:
- Always take backups before testing
- Avoid writing to production systems unless absolutely necessary
Q91. What is Baseline Testing?
Answer:
Baseline Testing refers to testing the initial version of the application to verify that all core features are working before enhancements or changes are made.
It serves as a reference point for future testing. After changes, the current build is compared against this baseline.
Benefits:
- Identifies deviations early
- Helps in regression comparison
Q92. How do you validate logs and database entries manually during testing?
Answer:
- Logs: Access server-side log files (e.g., Apache, Tomcat) to trace errors, stack traces, and flow of requests.
- Database: Use SQL queries to check backend updates, inserts, deletes made by the application
Example Query:
sql
SELECT * FROM users WHERE email=’test@example.com’;
Check whether:
- Correct data is inserted
- No unintended changes occurred
- Data integrity is maintained
Q93. What’s the difference between Verification and Validation?
Answer:
- Verification: Are we building the product right? (Static testing – reviews, walkthroughs, inspections)
- Validation: Are we building the right product? (Dynamic testing – execution of test cases)
Example:
- Checking requirements → Verification
- Running tests on application → Validation
Q94. What is your approach for Testing in CI/CD pipeline?
Answer: CI/CD requires:
- Smoke tests and unit tests on code check-in
- Automated functional tests in nightly builds
- Integration with Jenkins/GitHub Actions
- Feedback loop for early detection
Tools used: Jenkins, Bamboo, CircleCI, Azure DevOps, Selenium, TestNG
Q95. What is Sanity Testing and when do you do it?
Answer:
Sanity Testing is a subset of regression testing. It’s done after receiving a build to verify whether the core functionalities work properly before moving forward with further testing.
When to do:
- After minor changes or bug fixes
- To validate the stability of the application
Q96. What is a Test Harness?
Answer: A Test Harness is a collection of test scripts, configurations, data, stubs, and drivers used to test software components in isolation.
It’s used to:
- Simulate interactions between modules
- Test units when some modules are not yet developed
Example: When testing a login module while the user profile module isn’t ready, stubs are used to simulate it.
Q97. How do you manage cross-browser testing manually?
Answer: Cross-browser testing involves verifying whether a web application works as expected across different browsers and versions.
Manual Process:
- Create a browser matrix (e.g., Chrome 123, Firefox 115, Safari 17, Edge 120)
- Use VMs, BrowserStack, or real devices
- Test key areas – layout, responsiveness, JavaScript functionality, form behavior, cookies
Q98. How do you perform Root Cause Analysis for a defect?
Answer: Root Cause Analysis (RCA) involves:
- Reproducing the defect
- Tracing back steps using logs and system behavior
- Reviewing design and code if needed
- Discussing with developers to identify origin
Tools/Methods: Fishbone diagram, 5 Whys, Log analyzers
Q99. What is the difference between Severity and Priority?
Answer:
- Severity: Technical impact of the bug (e.g., Crash vs. UI alignment)
- Priority: Business urgency to fix (e.g., Minor bug in payment page → High priority)
| Type | Example |
| High Severity, Low Priority | System crash on rare feature |
| Low Severity, High Priority | Spelling mistake on homepage |
Q100. Explain how you create a Test Strategy document.
Answer: A Test Strategy is a high-level document that outlines the approach, scope, resources, schedule, and techniques for testing.
Sections Include:
- Test Objectives
- Scope (In-Scope & Out-of-Scope)
- Test Environment
- Test Deliverables
- Tools and Automation Approach
- Entry & Exit Criteria
- Risk & Mitigation
- Roles and Responsibilities
The Next 20 questions -III: MANUAL TESTING
