Top 50 Software Testing Interview Questions and Answers

1. What is Test Plan & Test Strategy? What are the differences between Test Plan and Test Strategy?

Test Plan: A test plan is a document consisting of Scope, Approach, Objectives, Resources, and Schedule of Testing Activities for the specific project. Standard Test Plan consists of different fields like:

  • Test Plan ID
  • Project Introduction
  • Scope (In Scope and Out Scope): In scope is what we planning to test. Out scope is what we are not planning to test.
  • Resources (Tools, Manpower, Environmental Requirements)
  • Risks (Time, Previous Phase)
  • Mitigation Plan (Overcome Risk)
  • Entry Criteria (Time, No P0 and P1 Bug in Open State, Environment Ready)
  • Exit Criteria (100% Test Execution, All Bugs are Fixed, Time)
  • Approvals/Sign Off (All the responsible parties like product owner, project manager, UAT manager, test lead to do a written signature)

Test Strategy: A Test Strategy is a part of Test Plan that describes the Test Efforts, Test Configuration, Testing Tools to be Employed, Test Environments, Exit Criteria and Entry Criteria for Testing, What different Types of Testing will be Carried Out (for example, Smoke test, Regression, Load test, Functional test and so on) and System Requirement.

Difference between Test Plan and Test Strategy:

Basically there is no difference between Test Plan and Test Strategy. Test Strategy is the part of Test Plan. Everything I do to ensure the Test plan is completed on Time is my test Strategy.

Whatever I am doing in the test plan is my Test Strategy like what are the things we planning to test and what we’re not planning to test.

I am going to tell you these are my risks as well as and how to overcome this risks by a mitigation plan.
I am not going to accept this product if there is a P0 and P1 bug.
I am not going to stop the testing until I completed 100% Test Execution and all the Bugs are Fixed.

Previous Phase – Drop off the code from SIT to UIT. There should not be a P0 and P1 Bugs in open state.
Entry Criteria – when you are going to Start your testing.
Exit Criteria – when you need to Stop testing.

2. What is Test Cases? What are the differences between Test Cases and Test Scenarios?

Test Cases: A Test Case is a document that describes step-by-step process how to test the application. A Test Case includes:

  • Test Case ID
  • Test Step
  • Steps Description
  • Test Data
  • Expected Output
  • Actual Output
  • Pass/Fail
  • Created By
  • Remarks

Test Scenarios: A Scenario is any functionality that can be tested. It is also called Test Condition or Test Possibility. A scenario has multiple test cases. Every time we have write test cases for test scenario.

Differences between Test Cases and Test Scenarios:

Test scenario means high level of functionality and test case means how to test the particular functionality.

Test Scenario: What to test?
Test Case: How to test?

3. What is a Use Case and what does it include?

A Use Case is a flowchart that telling us Where do we Start, How do we Navigate there, and How do we Complete the process for a particular functionality.

Use case diagram are drawing the Analysis phase and design phase so when we coming to the business requirement for the project, we create the use case diagram to map how we’re going to meet this requirements.

For instance, if we want to login first start with by launching the browser and open the application url. Then using the valid user and password logged in the application.

Use Case Includes:

  • Cover Page
  • Revision History
  • Table of Contents
  • Flow of Events (normal flow and alternate flow)
  • Exceptions
  • Special Requirements
  • Pre-conditions
  • Post-conditions

1 Use Case = Many Test Cases.

4. Explain the Defect Life Cycle (DLC).

When a tester finds a bug, the bug is assigned with NEW or OPEN status.

The bug is assigned to development project manager who will analyze the bug. He will check whether it is a valid defect. If it is not valid bug is rejected, now status is REJECTED.

If not, next the defect is checked whether it is in scope. When bug is not part of the current release. Such defects are POSTPONED.

Now, Tester checks whether similar defect was raised earlier. If yes defect is assigned a status DUPLICATE.

When bug is assigned to developer. During this stage bug is assigned a status IN-PROGRESS.

Once code is fixed. Defect is assigned with FIXED status.

Next the tester will re-test the code. In case the test case passes the defect is CLOSED.

If the test case fails again the bug is RE-OPENED and assigned to the developer.

That’s all to Bug Life Cycle.

5. What was the process of QA testing in your company where you worked for the last time?

My current project is at “XYZ Company” is based on Agile methodology. At the very beginning, gathers the team together, including the Scrum Master. Scrum Master attempted to facilitate Scrum planning. First of all the Business Requirement Document was prepared as per the client’s requirement (with the muck-up). The Developers started coding their modules (started programming).

Then on the basis of the requirement document, QA Team wrote Test Plans, Test Cases and Test Strategies. We join Daily Stand-up Meeting discuss sprint task what I did yesterday, what I’m doing today and bring up if any issue or blocker, any issue with server, application or even a bug.

Once the developers finished coding, the Configuration Management Team compiled the code together and prepared a build. This Build is now deployed to different testing environments where different types of testing were performed.

Once the defects were found, the testers would log the defect using the tools HP ALM. Once the defects are logged, then those defects would be discussed in the defect status meeting and would take further actions (meaning, closing, reopening, retesting of defects etc).

Once the defects were fixed, re-tested them and if the passed, closed them. If the defects were not fixed, then reopened them.

6. What is Requirement Traceability Matrix? Did you prepare any RTM? How did you prepare RTM?

Requirement Trace-ability Matrix or RTM is a document that maps and traces user requirement with prepared test cases. The goal of Requirement Trace-ability Matrix is to see that all the test cases are covered so that no functionality should miss while developed and testing.

Requirement Trace-ability Matrix – Parameters:

  • Requirement ID
  • Risks
  • Requirement Type
  • Requirement Description
  • Trace to Design Specification
  • Unit Test Cases
  • Integration Test Cases
  • System Test Cases
  • User Acceptance Test Cases
  • Trace to Test Script

Types of Trace-ability Matrices:

  1. Forward Trace-ability: Mapping of requirements to test cases. A forward trace-ability helps us see which requirements are covered in which test cases? Or whether a requirements is covered at all.
  2. Backward Trace-ability: Mapping of test cases to requirements. A backward trace-ability matrix helps us see which test cases are mapped against which requirements.
  3. Bi-Directional Trace-ability: A bi-directional trace-ability matrix contains both forward and backward trace-ability. A good example of a bi-directional trace-ability matrix used in software testing is the references from test cases to basis documentation and vice versa.

Benefits of Trace-ability Matrices:

  • Software is being developed as required.
  • Making sure that all requirements are included in the test cases.
  • Ensuring that developers are not creating features that no one has requested.
  • Easy to identify missing functionalities.
  • Making it easy to find out which test cases need updating if there are change requests.
  • Confirms 100% test coverage.

Yes, I have prepared Requirement Traceability Matrix one of my previous project.

How to Prepare RTM in ALM:

Trace-ability matrix can be generated by Navigating to “Requirements” Module and go to View > Trace-ability Matrix.

Click Configure Traceability Matrix > Define source requirements.

Also Define Filter by linked requirements or Filter by linked tests and click OK.

Now click on “Generate Trace-ability Matrix” which will generate the trace-ability matrix based on the filter criteria.

7. What’re the differences between Agile and Waterfall model

Waterfall Model Agile
In Waterfall model Software Design Process is Linear. In Agile Software Design Process is Incremental and Iterative approach.
Development flows sequentially from start point to end point, with several different stages: Requirement Analysis, System Design, Implementation (Construction), Testing, Deployment, and Maintenance. Software is developed in incremental, rapid cycles. The design process is broken into individual models that designers work on.
Distance Between Customer and Developer is Long in Waterfall model. Distance Between Customer and Developer is Short in Agile method.
In Waterfall Time Between Specification and Implementation is Long. In Agile Time Between Specification and Implementation is Short.
In Waterfall Planning Scale Long Term. In Agile Planning Scale is Short Term.
Ability to Respond Quality to Change Low. Ability to Respond Quality to Change High.
Time to Discover Problems is Long. Time to Discover Problems is Short.
A process that requires clearly defined requirements upfront. A process in which requirements are expected to evolve and change.
Suited for a situation where change is uncommon. Best for those who want continuous improvements.

When should you use Waterfall methodology:

  • When there is a clear picture of what the final product should be.
  • When clients won’t have the ability to change the scope of the project once it has begun.
  • When definition, not speed, is key to success.

When should you use Agile methodology:

  • When rapid production is more important than the quality of the product.
  • When clients will be able to change the scope of the project.
  • When there isn’t a clear picture of what the final product should look like.
  • When you have skilled developers who are adaptable and able to think independently.
  • When the product is intended for an industry with rapidly changing standards.

8. What you’ll do, if requirements are Changes?

Changing requirements is a common problem and a major headache. If requirements are changes I’ll

  • Work with the project’s stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
  • Try to move new requirements to a ‘Phase 2’ version of an application, while using the original requirements for the ‘Phase 1’ version.
  • Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
  • Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted – after all, that’s their job.
  • Then be sure Test Plan, Test Scenario, Test Cases or Test Script are modified. The project’s initial schedule should allow for some extra time corresponding with the possibility of changes.
  • Finally I’ll perform the Regression Testing to make sure that the added new functionality does not break the other parts of the application.

9. What is Entry Criteria and Exit Criteria?

Entry Criteria: Entry criteria is the minimum set of conditions that should be met in order to start the testing work . Entry criteria are documented and signed off during the test planning phase and is included in the relevant test plans. Typical entry criteria may include the following:

  • Documentation – All the necessary documentation, design, and requirements information should be available that will allow testers to operate the system and judge the correct behaviour.
  • Hardware – All test hardware platforms must have been successfully installed , configured, and functioning properly.
  • Software – All the standard software tools including the testing tools must have been successfully installed and functioning properly.
  • Training – All personnel involved in the testing effort must be trained in the tools to be used in the testing process.
  • Test Data – Proper test data is available.
  • Test Environment – The test environment such as, lab, hardware, software, and system administration support should be ready.

If any of the conditions specified in the Entry criteria ( that is already documented and signed off) cannot be met due to some reasons, an approval is needed from all the stakeholders that were involved during the signing off.

Exit Criteria: Exit criteria is the set of conditions that should be met in order to close a particular project phase. Exit criteria are documented and signed off during the test planning phase and are included in the relevant test plans. Typical Exit criteria may include the following:

  • All Test plans have been run.
  • A certain level of requirements coverage has been achieved.
  • No high priority or severe bugs are left outstanding.
  • All high-risk areas have been fully tested, with only minor residual risks left outstanding.
  • Cost – when the budget has been spent.
  • The schedule has been achieved.

Exit criteria should have been agreed as early as possible in the SDLC cycle; however, it may get subjected to controlled changes as the details of the project become more clear.

10. What are the features you have tested in your last project?

Please Answer Yourself According to Your Project.

11. Did you have experience in Agile? Tell me about your agile experience.

Yes, I have good experience in Agile. My current project at “NH Tech Inc.” is based on Agile methodology. At the very beginning, gathers the team together, including the Scrum Master. Scrum Master attempted to facilitate Scrum planning.

The team reduced the product backlog by priorities backlog and asked the owner for details user story. We also size the user story in order to determine what story are fits into the this sprint.

We moved the high priority stories from the product backlog into the Sprint Backlog that defines the scope of Sprint. When the Sprint backlog is complete the the team working on the user stories.

Everyday I attend the Daily Stand-up meeting and answer the questions:
i. What I did yesterday
ii. What Shall I do today
iii. Any obstacles are impeding my progress.

When the entire Sprint works has been completed, I joined the End-of-Sprint Review meeting where the Scrum team presents that release.

As final action of the Sprint, I joined the Retrospective meeting. We discussed what went well and what didn’t well during the Sprint. Identified the areas of improvement in future.

After that meeting next Sprint start and consists of the same process Sprint Planning, Daily Stand-up Meeting, End-of-Sprint Review, and concluding with the Retrospective meeting.

12. What is Regression Testing? How Do You Perform Regression Testing?

When a new functionality is added to the software, we need to make sure that the added new functionality does not break the other parts of the application. Or when defects (bugs) are fixed, we need to make sure that the bug fix has not broken the other parts of the application. To test this, we perform a repetitive test, which is called regression test.

Regression testing ensures that a change or fix has not caused faults to appear in unchanged parts of the system.

Regression Testing is important because of following reason:

  • That the application works even after the alteration in the code were made.
  • The original functionality continues to work as specified even after doing changes in the software application.
  • The alteration to the software application has not introduced any new bugs.

How do I Perform: In my current application “NH Tech Inc.” Campus Solution we found a bug at Certificates of Deposit section in the Banking module. There was a calculation error in the Interest Rate. We send this bug to development project manager and development team fix the bug.

After fixing this bug our configuration team sent to us a new build. And then we perform regression testing to ensure other functionality is not affected for this fix.

13. What is difference between Retesting and Regression testing?

Retesting is done to verify defects fixes whereas regression is performed to check if the defect fix have not impacted other functionality that was working fine before doing changes in the code.

Retesting is planned testing based on the defect fixes listed whereas regression is not be always specific to any defect fix. Also regression can be executed for some modules or all modules.

Retesting concern with executing those test cases that are failed earlier whereas regression concern with executing test cases that was passed in earlier builds.

Retesting has higher priority over regression, but in some case retesting and regression testing are carried out in parallel.

14. What is the most challenging testing situation you faced and how did you overcome it?

In my last project at “XYZ Company”, we’re almost ready to release a cycle. Suddenly just before very few days to release, one of the requirements has changed! We had to changed the Test Plan, Test Scenario, Test Cases and a huge Test Script. This was the most challenging situation I have faced ever. Because the release deadline was very near and if we fail to release company will lose huge revenue.

To overcome this situation, I worked 12 hours in a day. There were no choice to do extra hours. Even I worked at my holidays. And finally we could release on time. This saves my company from a huge loss.

15. How to overcome the challenge of not having input documentation for testing?

Well, this is a situation where I have come across several times in my past experiences.

In this case, If detailed standard documentation like BRD and FSD are unavailable I went to the Business Analyst and sometimes to developers to find out how exactly the functionalities work, how to navigate from one page to another page and so on. After getting a clear vision, I write test cases based on the conversation and get ready for testing.

I also depend on some point of references if available like,
Wireframes A previous version of the application.

When none of these situations work, we can just conceptualize the application based on our previous IT application experience and create the basic set of test scripts. When testing phase comes up, we can set up a portion of test cycle time and do some test case management (make the already created scripts perfect) so we have the doc for the next phases.

16. How big is your Team?

10 Developers, 5 Manual Tester, 3 QA Automation, 1 Tech Lead, 1 QA Lead, IT Manager, Project Managers, Business analysts and System Analysts, and Agile/Scrum Master. Total 25 team members.

17. What’s your great accomplishment?

When I joined the company “XYZ Company”, there were no Monthly Report. I created a Monthly Report besides the weekly status report. That helps much more the project manager and the company to estimate the task done and in what we need more effort to complete the testing task to release the product on estimated deadlines.

Now the company using Monthly Report also for the development team besides the testing team. And I was mentioned as the employee of the year.

18. You have given ATM card. You’ll withdraw $100 from card. How do you write Test Scenario?

Req. Id Scenario Id Test Scenario Test Cases
R0001 TS001 Validate the Login Functionality of the Application to ensure
only the Registered Customers are Allowed to Login using ATM Card.
R0002 TS002 Validate Customer can Withdraw Money from ATM Card. 2

19. What is End-to-End Testing? How did you performed End-to-End Testing?

Testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system is behaving as expected.

For example, I performed a simplified end-to-end testing of an email features one of my last project involve:

  • Logging in to the application.
  • Accessing the inbox.
  • Opening and closing the mailbox.
  • Composing, forwarding or replying to email.
  • Checking the sent items.
  • Logging out of the application.

20. Which Test Cases Should be Automated? Why do we need Automation?

  • Functional test cases are automated.
  • Execute the routine tasks like smoke tests and regression tests.
  • High Risk Business Critical test cases.
  • Test cases that are executed repeatedly for multiple builds.
  • Tests that require different sets of data.
  • Tests that run on several different hardware or software platforms and configurations.
  • Identical tests that need to be executed using different browsers.
  • Tests that are highly subject to human error.
  • Test cases executed with complex business logic or complex calculation.
  • Tests that take a lot of manual effort and time.
  • Test case Involves large amount of data.
  • Test cases which are stable enough.
  • Number of iterations of the test case executions are not known.
  • Test Cases those are very tedious or difficult to perform manually.
  • If the test cases are not validating look and feel of the application.
  • If the test case steps are Not dependent on the other platform.

However, in case you need to understand the look, feel or human reaction to a certain feature, then that is not possible.

Why Need Automation: Automation is good for checking, verifying, and validating the Application. We need Automation to –

  • Test Each and Every Feature.
  • Reduce Manual Effort and Saving Time.
  • Save Money.
  • Increasing Productivity.
  • Reducing Human Errors.
  • Faster Cycle/Release.
  • Increased Test Efficiency and Software Quality.
  • Increased Confidence.
  • Greater Test Coverage.

21. What is Regular Expression? How do you use Regular Expression in your Object Repository?

An expression that can match one or more expression or values is a Regular Expression.

Regular expressions are used when the object’s value are dynamically changed. By using special characters such as a period (.), asterisk (*), caret (^), and brackets ([ ]) you define the conditions of the search.

Regular Expressions can be used in UFT in cases where the user needs to identify objects where part of the object property remains constant and the remaining part changes frequently.

To use Regular Expression in Object Repository, open Object Repository from Resources > Object Repository. Select the object which you want add Regular Expression. In the Value section Click on the Configure the value. Put check mark on the Regular expression and change the Constant value to (.*) which are changes frequently.

22. How does QTP identify an object?

QTP has a predetermined set of properties that it learns/stores for every class of object it identifies.

During a run session, UFT first attempts to identify the test object using the Learned Description properties. The Learned Description mechanism uses two types of properties.

  1. Mandatory Properties – Mandatory properties are properties that UFT always learns for a particular test object class.
  2. Assistive Properties – Assistive properties are properties that UFT learns only if the mandatory properties that UFT learns for a particular object in your application are not sufficient to create a unique description.

After the Learn Description properties are applied, if no objects or more than one object is found, it attempts to identify the object using the Visual Relation Identifier. Enables UFT to identify test objects according to their neighboring objects in the application.

After the Visual Relation Identifier is applied, if no objects or more than one object is found, the visual relation identifier fails, and UFT continues to Smart Identification (when defined for that test object class). The Smart Identification mechanism uses two types of properties:

  1. Base Filter Properties – the most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link tag was changed from {A} to any other value, you could no longer call it the same object.
  2. Optional Filter Properties – other properties that can help identify objects of a particular class. These properties are unlikely to change on a regular basis, but can be ignored if they are no longer applicable.

After Smart Identification is applied, if no objects or more than one object is found, Ordinal Identifiers are used for that test object. UFT can use the following types of ordinal identifiers to identify an object:

  1. Index – Indicates the order in which the object appears in the application code relative to other objects with an otherwise identical description.
  2. Location – Indicates the order in which the object appears within the parent window, frame, or dialog box relative to other objects with an otherwise identical description.
  3. CreationTime (Browser object only) – Indicates the order in which the browser was opened relative to other open browsers with an otherwise identical description.

23. What is Object Spy? How to use the Object spy?

Object Spy Tool helps to learn the objects in the application under test (AUT). By simple click on the object, Object Spy displays Properties and Operations of Native and Identification objects. Object Spy Dialog Box: Tools > Object Spy…

It shows all the properties of the object and the corresponding values. It also shows the object hierarchy. It also has a provision that lets the users add a certain object to the OR.

There are two ways to Spy the objects in QTP:

  1. Toolbar: In the ToolBar click on the near last toolbar button (an icon showing a person with hat).
  2. Object repository Dialog: In Object Repository dialog click on the button “object spy…” In the Object spy Dialog click on the button showing hand symbol. The pointer now changes into a hand symbol and we have to point out the object to spy the state of the object. If at all the object is not visible or window is minimized then hold the Ctrl button and activate the required window to and release the Ctrl button.

24. What is an object repository?

Object Repository is a collection of object and properties with which UFT will be able to recognize the objects and act on it.

Object Repository displays a tree of all objects in the current component or in the current action or entire test( depending on the object repository mode you selected). We can view or modify the test object description of any test object in the repository or to add new objects to the repository.

25. Explain the concept of how UFT identifies object and how UFT recognizes objects?

During recording UFT looks at the object and stores it as test object. For each test object QT learns a set of default properties called mandatory properties, and look at the rest of the objects to check whether this properties are enough to uniquely identify the object.

During test run, UFT searches for the Run Time objects that matches with the Test Object it learned while recording.

Quicktest learns the default property values and determines in which test object class it fits. If it is not enough it adds assistive properties, one by one to the description until it has compiled the unique description. If no assistive properties are available, then it adds a special Ordinal identifier such as object’s location on the page or in the source code.

(To be Continue)

About the Author

Leave Comment