Test Plan Interview Questions & Answers

Question 1. What Is A Test Plan?

Answer :

A Test Plan is a document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks and who will do each task (roles and responsibilities) and any risks and its solutions.

Question 2. What Does Test Plan Include?

Answer :

Components of the test plan document include:

• Test Plan id
• Introduction
• Test items
• Features to be tested
• Features not to be tested
• Test techniques
• Testing tasks
• Suspension criteria
• Features pass or fail criteria
• Test environment (Entry criteria, Exit criteria)
• Test deliverables
• Staff and training needs
• Responsibilities
• Schedule
• Approvals
• Risks and Contingencies

This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company.

Question 3. What Are The Levels Of Test Plan?

Answer :

The Level of Test Plan defines what the test plan is being created for e.g. subsections of testing:

• Integration
• Unit
• Acceptance
• A Test Plan document will follow the same structure for each level of test plan. The only difference being the content and detail.
• Hierarchy of Test Plans will exist.

Question 4. What Is Test Strategy?

Answer :

A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.

Question 5. What Does The Test Strategy Include?

Answer :

The test strategy includes introduction, resource, scope and schedule for test activities, test tools, test priorities, test planning and the types of test that has to be performed.

Question 6. What Is Test Case?

Answer :

A test case is a documentation which specifies input values, expected output and the preconditions for executing the test.

IEEE Standard 610 (1990) defines test case as follows:

A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

Question 7. What Are The Objectives Behind Writing And Executing The Test Cases?

Answer :

Below mentioned are some of the objectives behind running the test cases.

• Find the defects in software products.
• Verify that the software meets the end user requirements.
• Improve software quality.
• Minimize the maintenance and software support costs.
• Avoid post deployment risks.
• Compliance with processes.
• Help management to make software delivery decisions.

Question 8. What Is Test Ware?

Answer :

The test ware is:

• The subset of software which helps in performing the testing of application. 
• Test ware are required to plan, design, and execute tests. It contains documents, scripts, inputs, expected results, set-up and additional software or utilities used in testing. 
• Test ware is term given to combination of all utilities and application software that required for testing a software package.

Test ware is special because it has:

• Different purpose
• Different metrics for quality and
• Different users

Question 9. What Is A Test Case And A Test Case Walk-through?

Answer :

A test describes the input to a test. This can include the data, the screen that will be used and the parameters that may drive the test. It will describe the steps necessary to execute the test case. It will describe the output and the results that are to be expected. It may include manipulation of the input data to test the particular case. A Test Case Walkthrough is a review of the test case by Testing Peers. It can highlight steps that may have been missed or test cases that may have been missed.

Question 10. What Are The Different Test Plan Types?

Answer :

The different test plan types are

• Master Test Plan
• Testing Level Specific Test Plans
• Testing Type Specific Test Plans

Question 11. What Is Master Test Plan?

Answer :

A single high-level test plan for a project/product that unifies all other test plans.

Question 12. What Are Testing Level Specific Test Plans?

Answer :

Plans for each level of testing like

• Unit Test Plan
• Integration Test Plan
• System Test Plan
• Acceptance Test Plan

Question 13. What Are Testing Type Specific Test Plans?

Answer :

Plans for major types of testing like Functional Test Plan, Performance Test Plan and Security Test Plan.

Question 14. Is Test Plan Document Is Required For Testing?

Answer :

Test Plan covers – What needs to be tested, how testing is going to be performed? Resources needed for testing, Timelines and Risk associated. 

For efficient and effective test planning we don’t really need IEEE-829 template for test plan. Planning can be done without test plan document also. Identify your test Approach (strategy) and go with your testing. Many test plans are being created just for the sake of processes.

Note – We are not against Test Plan documents. Use test plan documents if they really contains some useful information.

Question 15. What Is Plan Identifier?

Answer :

A test plan document will commence with a unique test plan identifier

• Unique company generated number.
• Identifies the Test Plan, its test level and the level of software it’s related to.

Question 16. Why Do We Need An Identifier?

Answer :

We need plan Identifier for,

• Software Document.
• To assist in coordinating software and test ware versions.

Revision numbers are also used as plan identifier.

Example: RS-MTP01.3

Question 17. What Are Test Items?

Answer :

Identifying the test items is a section that basically specifies the things that are to be tested within the scope of this test plan:

• Functions of the software
• Requirements stated in the Design stage

The Test Plan should ensure correct names and versions as listed.

Software and hardware needed for testing will also be listed here, along with other test materials and participating organizations. 

Example: EXTOL EDI package, Version 3.0

Question 18. What Are Software Risk Issues?

Answer :

All risks associated with the software and its testing need to be identified in this section.

Why: Plan for risks and contingencies

• This could include complex functions, new versions of cooperating software, etc...

Test planners should be aware of:

• Vague, unclear or non-testable requirements
• Misunderstanding of requirements

Example: Backup and Recovery of the EDI transmission files, local databases and restart of the translation process, must be carefully checked.

Question 19. What Is Test Approach?

Answer :

This section identifies the strategy for this test plan, differing depending on the level of test plan (Unit, Integration, Acceptance).

• The approach stated should be appropriate and in agreement with all higher and lower levels of test plans.
• The level of detail of this section differs depending on the level of test plan. For example, a Unit test plan will go into much detail on individual unit tests and test data.
• The bulk of information on testing techniques and methodologies will be included in this section.

Question 20. What Is The Use Of Test Deliverables?

Answer :

This section is used to specify what is to be delivered as part of this test plan

• Note: One thing that is not a test deliverable is the software itself!
• Examples of Deliverables are,
• Test logs
• Incident reports
• Outputs
• Corrective actions taken

Question 21. What Are Environmental Requirements?

Answer :

• Environmental Requirements states any special requirements for this test plan including necessary hardware and software required for testing to proceed.
• Documenting the physical components required for test execution helps to identify potential gaps in what is required and what actually exists.

Example: Access to a nightly backup/recovery system.

Question 22. What Is The Way For Planning For Risks And Contingencies?

Answer :

• This section aims to identify the overall risks to the project with an emphasis on the testing process. Identified risks are then given possible solutions.
• Think back to “Risk Issues”.
• “Backup and Recovery of the EDI transmission files, local databases and restart of the translation process, must be carefully checked.”
• The section should in turn identify how to plan for risks stated earlier in the test plan.

Question 23. What Are Staffing/training Needs?

Answer :

• This section identifies all personnel and the hierarchies relevant to the test plan.
• This includes all areas of the plan such as setting risks, selecting testing and non-testing features, scheduling and most importantly critical go/no go decisions.

Example: Staff will require training on new equipment.

Question 24. What Is Schedule Of Test?

Answer :

• Scheduling should be based on realistic and validated estimates for software testing. 
• Milestones should be identified with schedules being specified for each milestone.
• Depending on the level of test, the size of this section will differ, e.g. Master test plan will involve all the test plan schedules below it making it fairly large.
• Dependent/Relative Dating.

Question 25. What Is Meant By Approvals?

Answer :

• Approvals states who can consent a process as complete and allow the project to proceed to the next stage.
• This depends on the level of test plan and can differ from a test team leader to a more executive employee.
• The type of knowledge at each level of test plan differs significantly. For example, programmers may understand the technical side of software but not the managerial or commercial side.

Question 26. What Re The Guide Lines For A Test Plan?

Answer :

• Make the plan concise. Avoid redundancy. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition/Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to base lining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
• Update the plan as and when necessary. An outdated and unused document stinks and is worse than not having the document in the first place.