MT- 2 - All about testplan !!

I'd like to do a copy some of the basic testplan attributes from the IEEE standard of the testplan and its contents :

IEEE 829 STANDARD TEST PLAN TEMPLATE
Test plan identifier
Test deliverables
Introduction
Test tasks
Test items
Environmental needs
Features to be tested
Responsibilities
Features not to be tested
Staffing and training needs
Approach Schedule
Item pass/fail criteria
Risks and contingencies
Suspension and resumption criteria Approvals

Lets discuss each one in details :

TEST PLAN TEMPLATE-

Testplan is an artifact usually creatred either by test leads or by experienced test engineers which intents to the planning done to complete a project with available resources and time. The above inputs are kept in mind while doing planning. it defines the objective of the test that is to be carried out.The testplan template varies from company to company and process to process. In some companies I have seen people saying testcase document as testplan.

Test Plan Identifier:

• Provide a unique identifier for the document. It is basically given by the Configuration Management Team. It basically may depend on the build version or type to uniquely identify the testplan.

Introduction:

• Provide an overview of the thing we are going to access.
• Specify the goals/objectives.
• Specify any constraints.

References:

• List the related documents, with links to them if available, including the following:
  • Project Plan
  • Configuration Management Plan

 Test Items:

• List the test items (software/products) and their versions.
• List the baseline if any .

Features to be Tested:

• List the features of the software/product to be tested.
• Provide references to the Requirements and/or Design specifications of the features to be tested

Features Not to Be Tested:

• List the features of the software/product which will not be tested.
• Specify the reasons these features won’t be tested.

Approach:

• Mention the overall approach to testing.
• Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria:

• Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

Suspension Criteria and Resumption Requirements:

• Specify criteria to be used to suspend the testing activity.
• Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

• List test deliverables, and links to them if available, including the following:
  • Test Plan (this document itself)
  • Test Cases
  • Test Scripts
  • Defect/Enhancement Logs
  • Test Reports

 Test Environment:

• Specify the properties of test environment: hardware, software, network etc.
• List any testing or related tools.

Estimate:

• Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule:

• Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

Staffing and Training Needs:

• Specify staffing needs by role and required skills.
• Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

• List the responsibilities of each team/role/individual.
• Dividing the work as per skill set and experience and risk.

Risks:

• List the risks that have been identified.
• Specify the mitigation plan and the contingency plan for each risk.
• List the timeline issues if any.

Assumptions and Dependencies:

• List the assumptions that have been made during the preparation of this plan.
• List the dependencies.

Approvals:

• Specify the names and roles of all persons who must approve the plan.
• Provide space for signatures and dates. (If the document is to be printed.)

TEST PLAN GUIDELINES

• Make the plan concise. Avoid redundancy and superfluousness. 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 after approval from the stake holders.
• 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 baselining 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 out-dated and unused document stinks and is worse than not having the document in the first place

Testplan can be further categorised into following categories : 

• Unit Test Plan (to test a single functionality of any code)
• Integration Test Plan (To test integration between two modules)
• System Test Plan ( For testing system as a whole)
• Acceptance Test Plan (Usability testing or UAT )

NOTE : Never get confused between Test Strategy and testplan. Both are different terms.

MT-1 - Does the testing really means the same what we think ?

We must have heard the term testing many times but do we really know the meaning of it. Here I will be discussing about the term testing in brief and precise way.
Testing clearly refers to the three terms - Correctness , Completeness and Quality of the Product.
Testing is not about software only it can be about any thing. One favourite question of all the interviewers is about testing of any generic things like pen, chair, mobile, etc. and we really start thinking about this question. Do you think this is a tough question... Obviously not. Just think of the answer that how can you check the mentioned three terms of the the product. Correctness says about the meeting the actual product with the specified requirements. Does the product is as per the specified requirements,then go to the next step where we check the completeness of the product. Completeness says about the integration/interfacing of the each object of the product as the whole system..does the product works well after  integration..if yes then lets go to the last step that is Quality of the product. Quality is something different from the above two terms. Quality refers the testing of the product from the view of an end user. If we talk about software the Quality testing include several stuffs like performance , localization, globalization , security , accessibility , usability , recovery and Cross-browser testing. That's all.
Now  we can easily answer this popular interview question.