Test Plan Interview Questions

Test Plan Interview Questions and Answers

1) What is a Test Plan?
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.

2) What does test plan include?
Components of the test plan document includes,

•    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

3) What are the levels of test plan?
•    The Level of Test Plan defines what the test plan is being created for e.g. subsections of testing: Integration, Unit, and 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:What is a Master Test Plan?
•    Note: All Test Plans must agree

4) What is Test strategy?
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.

5) What does the test strategy include?
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.

6) What is Test Case?
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.

7) What are the Objectives behind writing and executing the test cases?
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

8)What is Test ware?
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

9) What is a test case and a test case walk-through?
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.

10) What are the different test plan types?
The different test plan types are,
•    Master Test Plan
•    Testing Level Specific Test Plans
•    Testing Type Specific Test Plans

11) What is Master Test Plan?
A single high-level test plan for a project/product that unifies all other test plans.

12) What are Testing Level Specific Test Plans?
Plans for each level of testing like,
•    Unit Test Plan
•    Integration Test Plan
•    System Test Plan
•    Acceptance Test Plan

13) What are Testing Type Specific Test Plans?
Plans for major types of testing like Functional Test Plan, Performance Test Plan and Security Test Plan.

14) Is Test Plan document is required for testing?
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.

15) What is Plan Identifier?
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.

16) Why do we need an Identifier?
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

17) What are Test Items?   

 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

18) What are Software Risk Issues?
•    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 un-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.

19) What is Test Approach?
•    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

20) What is Suspension Criteria?
•    Involves identifying when pausing during a series of tests is necessary.
•    E.g. if the number of defects reaches a point where the follow on testing has no value, it makes no sense to continue the test and waste resources
•    A test planner should specify “what constitutes stoppage for a test?” and “what is an acceptable number of defects to allow testing to continue?”

21) What is the use of Test Deliverables?
•    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

22) What are Environmental Requirements?
•    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

23) What is the way for Planning for Risks and Contingencies?
•    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.

24.) What are Staffing/Training Needs?
•    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

25.) What is Schedule of Test?
•    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

26.) What is meant by approvals?
•    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.

27.) What re the guide lines for a test plan?
•    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.

Also Read:
Sample Test Plan

Test Plan Templates

Test Planning FAQ


Post a Comment