Software Testing Interview Questions-Part 6

1. Difference between static and dynamic testing?

2. What is test plan?
3. Difference between Test plan and test strategy?
4. What is compatibility testing? Explain with examples.
5. Difference between testcase and test scenario.

[Link] between static and dynamic testing

Static Testing:
• Static testing is done without executing the program.
• Static testing checks the code, requirement documents, and design documents to find errors
• Static testing is about the prevention of defects
• Static testing does the verification process and is performed before compilation
• The main objective of static testing is to improve the quality of software applications by
finding errors in early stages of software development process.

Static Testing Techniques:

• Informal Reviews
• Technical Reviews
• Walkthrough
• Inspection
• Static code Review

Dynamic Testing:
• Dynamic testing is done by executing the program.
• Dynamic testing checks the functional behaviour of software system, memory/CPU usage
and overall performance of the
• Dynamic testing is about finding and fixing the defects.
• Dynamic testing does the validation process and is performed after compilation.
• The main objective of this testing is to confirm that the software product works as per
business requirements.

Dynamic Testing Techniques:

• Unit Testing
• Integration Testing
• System Testing

2. What is test plan?

• A test plan is a detailed document that outlines the strategy and approach for testing a
software application. It acts as a blueprint for the testing process, describing what will be
 tested, how it will be tested, and the resources needed. The test plan ensures that testing is
done systematically and efficiently.

Key Components of a Test Plan:

1. Test Objectives: What the testing aims to achieve (e.g., verify that the application meets the
requirements).

2. Test Scope: What will be tested (features, functionality) and what won’t be tested.

3. Test Strategy: The approach or methods to be used (manual testing, automation, etc.).

4. Test Resources: The team, tools, and environments needed to conduct the tests.

5. Test Schedule: A timeline of when each testing phase will be carried out.

6. Test Criteria: The conditions under which testing is considered a success (pass/fail criteria).

7. Risks and Assumptions: Potential challenges that might affect testing and assumptions
made during planning.

Example:
Imagine you’re testing a login page:

• Objective: Ensure that users can log in successfully with valid credentials.

• Scope: Testing the login form (valid/invalid input).

• Strategy: Manual testing to check the form’s functionality and automation for repetitive
validation.

• Resources: Testing team, testing tools (like Selenium), test environment (staging server).

• Schedule: Test execution planned for the next week.

3. Difference between Test plan and Test strategy?

Test Plan:
• Test Plan is used at the project level.
• Contains detailed testing activities and schedules.
• Describes how testing will be executed.
• Test plan is carried out by a testing manager or lead that describes how to test, when to test,
who will test and what to test.
• Test plan narrates about the specification.
• Test plan can change.

Test strategy:
• Test strategy is set at organization level and can be used by multiple projects.
• Contains High-level approach to testing practices.
• Describes the overall testing methodology and techniques.
• A test strategy is carried out by the project manager. It says what type of technique to follow
and which module to test.
 • Test strategy narrates about the general approaches.
• Test strategy can not be changed.

4. What is compatibility testing? Explain with examples.

Compatibility Testing is a type of testing that ensures a software application works correctly across
different devices, operating systems, browsers, or environments.

Key Areas:
1. Different Browsers (for web applications)

2. Different Operating Systems (like Windows, macOS, Linux)

3. Different Devices (like mobile phones, tablets, desktops)

4. Different Screen Resolutions

Simple Examples:
1. Web Browser Compatibility:

o Testing a website to ensure it works on different browsers like Google Chrome,

Mozilla Firefox, and Safari.

o Example: The "Submit" button on a form might work in Chrome but doesn't appear
correctly in Internet Explorer. Compatibility testing helps catch these issues.

2. Mobile App on Different Devices:

o Testing a mobile app on devices like an iPhone and a Samsung Galaxy to ensure the
app behaves the same on both.

o Example: The app's user interface might look perfect on an iPhone but might get
distorted on an Android phone with a different screen size.

3. App on Different Operating Systems:

o Testing a software application on Windows 10 and macOS to make sure it functions

the same way.

o Example: A desktop app might have different performance or UI issues on Windows

and macOS because of differences in how each OS handles applications.

4. Screen Resolution:

o Checking how a website or application looks on high-resolution screens (like 4K)

versus low-resolution screens (like 720p).

o Example: Text or buttons might appear too small on a high-resolution screen and
too big on a low-resolution screen. Compatibility testing ensures the UI adjusts
properly.

Why It’s Important:

 • Better User Experience: Ensures the app or website works well for all users, no matter what
device, operating system, or browser they use.

• Wider Reach: Helps make sure the software works across different platforms, increasing its
accessibility.

[Link] between test case and test scenario.

Test Case:
• Definition: A test case is a detailed, step-by-step instruction on how to test a specific feature
or functionality of the software. It includes specific inputs, actions, expected results, and
other conditions needed to verify whether the software works as expected.

• Components:

o Test case ID

o Description of what to test

o Preconditions (if any)

o Test steps

o Expected result

o Actual result (filled after test execution)

• Example:

o Test Case for a login screen:

▪ Test Case ID: TC_01

▪ Description: Verify login with valid credentials.

▪ Test Steps:

1. Open the login page.

2. Enter a valid username and password.

3. Click the "Login" button.

▪ Expected Result: User is successfully logged in and redirected to the

dashboard.

▪ Actual Result: (To be filled after executing the test).

Test Scenario:
• Definition: A test scenario is a high-level description of a functionality or feature to be
tested. It outlines the broad situation that needs testing without providing the step-by-step
instructions like a test case does. It’s focuses on what to test.
• Components:

o Test Scenario ID

o Description of the scenario

• Example:

o Test Scenario for a login screen:

▪ Test Scenario ID: TS_01

▪ Description: Verify login functionality for the user.