1. What is Software Testing Technique?

• Answer: Software testing techniques are methods used to test software applications to
ensure they meet the required quality standards. These techniques help detect defects and
ensure functionality, reliability, and performance.

• Explanation: Software testing techniques are broadly categorized into two types:

o Static Testing Techniques (e.g., reviews, walkthroughs, inspections): Test the

software without executing code.

o Dynamic Testing Techniques (e.g., black-box, white-box, and gray-box testing): Test
the software by executing the code.

• Diagram:

o Diagram illustrating types of testing techniques (Static vs. Dynamic).

• Example: Black-box testing is often used to validate user interfaces without knowing the
underlying code.

• Key Points:

o Purpose: Detect defects, validate functionality, and improve quality.

o Categories: Static (no execution) and Dynamic (execution-based).

2. What are the phases involved in Software Testing Life Cycle (STLC)?

• Answer: The Software Testing Life Cycle (STLC) includes phases that outline the systematic
approach to testing, ensuring software meets requirements and quality standards.

• Explanation:

o Requirements Analysis: Understanding testing requirements.

o Test Planning: Defining test strategy, scope, objectives, and resources.

o Test Case Development: Writing test cases and scripts.

o Environment Setup: Preparing test environments.

o Test Execution: Running tests and reporting bugs.

o Test Closure: Finalizing test results and documentation.

• Diagram:

o A flowchart of the STLC phases, showing the sequence from Requirement Analysis to
Test Closure.

• Key Points:

o Purpose: Structured approach to ensure comprehensive testing.

o Phases: Requirements, Planning, Development, Setup, Execution, Closure.

.
3. What is Black-box Testing?

• Answer: Black-box testing is a testing technique where the tester only checks the software’s
functionality without looking at the actual code.

• Explanation: In black-box testing, we treat the software like a “black box”—we only focus on
the input and output, not the internal workings. This type of testing is done from a user’s
perspective.

• Example: When testing a login form, the tester only checks if entering valid or invalid
credentials results in the correct response (e.g., login success or error message).

• Diagram: A simple input-output diagram representing black-box testing.

• Key Points:

o Focus on inputs and outputs.

o Doesn’t require knowledge of code.

4. What is White-box Testing?

• Answer: White-box testing is a testing technique where the tester examines the internal
structure of the code.

• Explanation: White-box testing requires understanding of the code and logic. Testers look at
specific paths, conditions, loops, and other parts within the code.

• Example: A tester might check each “if” condition in a code to see if all possible paths
produce the correct results.

• Diagram: A diagram showing code flow, with paths checked by the tester highlighted.

• Key Points:

o Focus on code structure.

o Requires knowledge of the code.

5. What is Gray-box Testing?

• Answer: Gray-box testing is a mix of black-box and white-box testing, where the tester has
some understanding of the internal structure but tests mostly from the outside.

• Explanation: In gray-box testing, testers have partial knowledge of the code but focus on
testing from a user’s perspective. It helps in identifying issues that may not be visible with
only black-box or white-box testing.

• Example: A tester knows how certain functions work and checks if each function responds
correctly based on its known logic.

• Diagram: A diagram showing partial visibility into the system, representing gray-box testing.

• Key Points:

o Combines elements of both black-box and white-box.

 o Useful for testing complex systems.

6. What is Unit Testing, Integration Testing, System Testing & Acceptance Testing?

• Unit Testing: Tests individual components (or units) of software to ensure they work on their
own. For example, checking if a specific function gives the expected result.

• Integration Testing: Tests how different units work together. For instance, testing if a login
function works with the user profile component.

• System Testing: Tests the entire software system to ensure it meets all requirements. It’s
done from start to end, like a user would use the software.

• Acceptance Testing: Final testing to check if the software is ready for release. It ensures the
software works well for users in real-world scenarios.

• Diagram: A pyramid or sequence showing the levels from Unit to Acceptance Testing.

• Key Points:

o Each level has a different focus, from individual parts (unit) to full system readiness
(acceptance).

o Helps in identifying issues at each stage of development.

7. What is Sanity/Smoke Testing, Regression Test, Retest?

• Sanity Testing: Quick checks to see if a specific part of the software is working correctly after
minor changes.

• Smoke Testing: Basic testing to ensure the main functions work, like “does the software
launch?”

• Regression Testing: Testing to make sure recent changes haven’t broken any existing
functionality.

• Retest: Re-testing specific cases where bugs were previously found, to ensure they’ve been
fixed.

• Example: After fixing a login bug, sanity and smoke tests might confirm the basic
functionality, while regression testing checks that other functions haven’t been affected.

• Key Points:

o Sanity and smoke tests focus on quick checks.

o Regression and retest ensure stability after changes.

.
8. What is Functional & Non-Functional Testing?

• Functional Testing: Tests if each function in the software works as expected. It focuses on
what the software should do.

• Non-Functional Testing: Tests the performance, usability, and reliability of the software. It
focuses on how well the software performs.

• Example:

o Functional testing: Checking if a “search” function shows correct results.

o Non-functional testing: Checking how fast the search results appear (performance).

• Key Points:

o Functional: Checks functionality.

o Non-Functional: Checks performance, security, usability.

9. What is Adhoc Testing?

• Answer: Adhoc testing is an informal testing method where the tester tries to “break” the
software by exploring it randomly without following any test cases.

• Explanation: Adhoc testing doesn’t follow a plan or script. It’s done by exploring the
software in unpredictable ways to catch unusual bugs.

• Example: Clicking randomly around the software to see if it crashes.

• Key Points:

o No plan or test cases.

o Focuses on finding unexpected issues.

10. What is Automation Testing?

• Answer: Automation testing is the process of using software tools to run tests automatically
instead of manually.

• Explanation: Automation testing saves time and reduces human error. It’s especially useful
for repetitive tasks, like running the same tests every time there’s a change.

• Example: Using a tool like Selenium to automatically test if the login page works correctly.

• Key Points:

o Uses tools to automate tests.

o Saves time and improves accuracy.

11. What is Verification and Validation in Software Testing?

• Verification: Checking if the product is being built correctly (are we following the right
steps?).

• Validation: Checking if the right product is built (does it meet user needs?).
 • Explanation: Verification is done by reviewing documents and plans, while validation is
about testing the final product to make sure it works for users.

• Example: Verification might involve reviewing requirements, while validation involves testing
the software.

• Diagram: A diagram showing verification as an early phase (checking plans) and validation as
later (checking the product).

• Key Points:

o Verification: “Are we building it right?”

o Validation: “Did we build the right thing?”

12. Why is Selenium a preferred tool for Automation Testing?

• Answer: Selenium is popular because it’s free, supports many browsers, and works with
multiple programming languages.

• Explanation: Selenium allows testers to automate web applications, making it easier to test
across different browsers. It’s open-source, so it has a strong community and regular
updates.

• Example: Selenium can run tests in Chrome, Firefox, and other browsers automatically.

• Key Points:

o Free and open-source.

o Supports multiple browsers and languages.

13. What are the various components of Selenium?

• Answer: Selenium has four main components:

1. Selenium IDE: A simple tool for recording and playing back tests.

2. Selenium WebDriver: Allows you to write code to control browsers.

3. Selenium Grid: Lets you run tests on multiple machines and browsers at the same
time.

4. Selenium RC (Remote Control): An older tool to write tests in different programming

languages.

• Key Points:

o IDE for recording, WebDriver for coding, Grid for parallel testing, and RC (outdated)

o for cross-language tests.

14. What are the different types of locators in Selenium?

• Answer: Locators in Selenium help find elements on a webpage. Common locators include:

1. ID: Finds elements by their unique ID.

2. Name: Finds elements by their name attribute.

3. Class Name: Finds elements by their class name.

4. Tag Name: Finds elements by their HTML tag.

5. Link Text: Finds links by their exact text.

6. Partial Link Text: Finds links by part of their text.

7. CSS Selector: Finds elements using CSS rules.

8. XPath: Finds elements using their path in the HTML structure.

• Example: Using ID to locate a login button with ID “loginBtn.”

• Key Points:

o Different locators suit different situations, like IDs for unique elements and
CSS/XPath for complex structures.

15. What is the difference between Absolute and Relative Path?

• Answer:

o Absolute Path: A complete path to an element starting from the root (top) of the
document.

o Relative Path: A shorter path that starts from a certain point in the document, not
the root.

• Explanation: Absolute paths are more detailed but can break if there are changes in the
document structure. Relative paths are flexible and usually preferred for their stability.

• Example:

o Absolute XPath: /html/body/div[1]/button

o Relative XPath: //button[@id='submit']

16. What do you mean by Boundary Value Analysis?

• Answer: Boundary Value Analysis (BVA) is a testing technique that focuses on values at the
edges of input ranges.

• Explanation: BVA helps identify potential bugs around minimum and maximum values. Since
bugs are more likely to appear at boundaries, testing these can improve quality.

• Example: If a system accepts values between 1 and 10, BVA would test values like 1, 10, 0,
and 11.
 • Diagram: A range diagram showing test cases at boundary points.

• Key Points:

o Tests values at the edges of input ranges.

o Useful for finding boundary-related bugs.

17. Which test cases are written first: white-box or black-box?

• Answer: Black-box test cases are usually written first because they are based on user
requirements and don’t need knowledge of the code.

• Explanation: Black-box tests focus on software functionality from a user’s perspective, while
white-box tests focus on code logic. Testing functionality often comes first.

• Key Points:

o Black-box first: Focus on user needs.

o White-box after: Focus on code structure.

18. What is Selenium?

• Answer: Selenium is a tool for automating web browser testing.

• Explanation: Selenium allows testers to write scripts that simulate user interactions with
web pages, helping ensure the website works as expected.

• Example: Automating the login process on a website by filling in the username, password,
and clicking the login button.

• Key Points:

o Automates browser testing.

o Supports multiple browsers.

19. What is a Test Plan? What does it include?

• Answer: A test plan is a document that describes the testing strategy, objectives, schedule,
and resources for a testing project.

• Explanation: It provides a roadmap for the testing process and helps ensure that all testing
activities are well-organized and aligned with the project goals. A test plan typically includes:

o Test Objectives: Goals of testing.

o Scope: What features will be tested.

o Resources: People, tools, and environments needed.

o Schedule: Timelines for testing activities.

o Risks and Assumptions: Potential issues and what is assumed.

• Key Points:
 o Blueprint for testing.

o Includes objectives, scope, resources, schedule, and risks.

20. What is SDLC in Software Testing?

• Answer: SDLC (Software Development Life Cycle) is a process for planning, creating, testing,
and deploying software.

• Explanation: SDLC provides a structure for developing software in steps, helping ensure
quality and efficiency. Phases include:

o Requirement Gathering: Understanding what the software should do.

o Design: Planning how the software will work.

o Implementation: Coding the software.

o Testing: Checking for bugs and issues.

o Deployment: Releasing the software.

o Maintenance: Fixing issues and making improvements after release.

• Diagram: Flowchart of SDLC phases.

• Key Points:

o Guides the software creation process.

o Includes planning, design, implementation, testing, and maintenance.

21. What is the Defect Life Cycle?

• Answer: The defect life cycle, or bug life cycle, shows the stages a defect goes through from
discovery to resolution.

• Explanation: It helps track and manage defects effectively. Typical stages include:

o New: Defect is found.

o Assigned: Assigned to a developer for fixing.

o Fixed: Developer resolves the defect.

o Retest: Tester checks if it’s fixed.

o Closed: Defect is confirmed as fixed and closed.

o Reopened: If the defect reappears, it’s reopened.

• Diagram: A lifecycle diagram showing each stage.

• Key Points:

o Tracks defect status.

o Stages: New, Assigned, Fixed, Retest, Closed, Reopened.

22. What is Selenium Grid?

 • Answer: Selenium Grid is a tool that allows you to run tests on multiple machines and
browsers at the same time.

• Explanation: By distributing tests across different environments, Selenium Grid speeds up

testing and helps ensure compatibility across various platforms.

• Example: Running tests on both Chrome and Firefox across different devices simultaneously.

• Key Points:

o Runs tests on multiple machines/browsers.

o Useful for compatibility testing.

23. What is SRS?

• Answer: SRS (Software Requirements Specification) is a document that describes what the
software should do, including features, functionalities, and limitations.

• Explanation: SRS acts as a contract between clients and developers. It ensures everyone
agrees on what the software will provide before development begins.

• Example: SRS for an e-commerce site might specify that users should be able to browse
products, add items to cart, and complete purchases.

• Key Points:

o Describes software requirements.

o Aligns clients and developers.

24. Explain Functional and Non-Functional Requirements.

• Functional Requirements: Define what the software should do (e.g., login functionality).

• Non-Functional Requirements: Define how well the software performs, such as speed,
security, and reliability.

• Example: For a banking app:

o Functional: User can check balance and transfer money.

o Non-Functional: The app should load within 3 seconds.

• Key Points:

o Functional: What software does.

o Non-Functional: How well it performs.

25. What is Requirements Analysis?

• Answer: Requirements Analysis is the process of understanding and documenting what the
users need from the software.

• Explanation: During this phase, developers and testers gather and analyze the requirements
to ensure they are clear, complete, and feasible.
 • Key Points:

o Understand and document user needs.

o Ensures requirements are clear and complete.

26. What are constraints of your project?

Project constraints are limitations or restrictions that the project team must work within. They can
include:

• Time: The deadline by which the project or part of the project must be completed.

• Budget: The amount of money available to complete the project.

• Scope: The boundaries or extent of the project, determining what will and won’t be
delivered.

• Quality: Standards that the project deliverables must meet.

• Resources: The availability of necessary people, equipment, or technology.

Constraints affect planning and decision-making, as they must be managed to ensure the
project's success.

27. What is a Test Case?

A test case is a set of specific conditions or variables used to verify if a software application is
working as expected. It typically includes:

• Test case ID: Unique identifier for the test case.

• Description: Brief explanation of what is being tested.

• Preconditions: Any setup needed before testing begins.

• Test Steps: Step-by-step actions to perform the test.

• Expected Result: The anticipated outcome if the software is functioning correctly.

• Actual Result: The observed outcome, which is compared to the expected result.
Test cases help ensure software behaves as intended and aids in identifying defects.

28. What is a Test Scenario?

A test scenario is a high-level description of what needs to be tested, focusing on the functionality or
feature to verify. For example, in an e-commerce application, a test scenario could be "Verify the
checkout process." Test scenarios provide a broader perspective of the testing process and help
guide the creation of more detailed test cases.

29. What is Test Data?

Test data is the data or input used in testing software. It is created or gathered to ensure that the test
cases cover all possible inputs and scenarios. For example, in a login test case, test data might
include different usernames and passwords to check how the application handles valid and invalid
inputs.
30. What is the difference between a Use Case and a Test Case?
A use case describes a specific user action and interaction with the system to achieve a goal, usually
from an end-user perspective. It helps in understanding how users will interact with the software.
A test case, however, is a set of steps with specific inputs and expected outcomes to check if the
software meets requirements. While a use case shows what users want to do, a test case verifies if
the software allows it successfully.

31. What is the difference between a Test Scenario and a Test Case?
A test scenario is a high-level idea of what to test, focusing on end-to-end functionality. It’s a broader
concept without specific steps.
A test case is a detailed document with specific instructions to execute and expected results. While
scenarios outline what to test, test cases provide the how-to steps to validate that scenario.