What is Test Plan

It is our official document which will decide  what we are going to test, when we will test and how we are going to test the in-scope requirements.
BY ISTQB Defination 
Test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice,and any risks requiring contingency planning.






    Basically Test plan will be prepare by Testing Lead. Tester 
   will just go through the document and write the testcases and 
 executes.

 1.Objectives and Scope:

This document provides a high level view of the type of test that is scheduled to be carried out and the features that will and will not be tested.



The objective of this document is to test the functionality of the Facebook Application.(Write your Application Name)



2       Features to be tested

FaceBook - Release 1:

The features which are to be tested, are:

1.    LoginPage

2.    Home Page

(Write Modules According to Your Application)

2.1      Features not to be Tested
3       Approach


In Approch You can write which model You are Going to follow.


Agile Methodology with scrum.


WaterFall 
3.1 Types of Testing


This document provides different types of testing for Facebook Application.


      1.    Static Testing


This testing does not need computer as the testing of program is done without executing the program. For example:  reviewing, walk through, inspection of the documents


2.  Dynamic Testing


a)Smoke Testing

b)Functional Testing

c)Retesting and Regression Testing

d)E2E Testing

e)Integration Testing
f)UAT


The testing will initiate with the review of the user requirement documents.

The first type of tests to be carried out will be Smoke and functional testing to determine that each of the individual features perform the functions for which they have been specified. After this a full set of end-to-end test scenarios will be identified once all the features have been delivered and tested, for this a set of e2e scripts would be produced which will seek to exercise the various workflow scenarios specified. This will be followed by system integration testing and UAT/CAT

                                      
Smoke Testing:

Smoke testing covers most of the major functions of the software. The result of this test is used to decide whether to proceed with further testing. If the smoke test passes, go ahead with further testing.

Functional Testing:

Functionality testing will be performed for all the functionalities of the application which will covers all the screens including inputs and outputs fields, buttons graphics and all the navigational flow between the screens.
 Regression Testing

Regression testing will be performed once a defect has been fixed and also if there any enhancements. The scope of this testing will depend on the nature of the defect fixed, but will include at least a re-run of the test where the defect was first identified and, any tests required to get the system into the state at which the problem was identified.

End-2-End Testing

A full end-2-end test will be carried to verify the flow of the process and to exercise all specified work flow route.

UAT/CAT Testing

User Acceptance/Customer Acceptance Testing phase will be performed to ensure that all the functionality scheduled for  delivery meets the business requirements.

Test Case Preparation

The test cases will be generated using JIRA,TFS,QC(Test Management Tool) and also in the excel sheet by the QA team lead. Requirement Traceability Matrix(RTM) will also be generated to make sure that all the requirements are covered 100%

Test Execution

The tester will carry out the execution based on the availability of the functionality and adequate release notes from the development team. Entry criteria for the system test stage are described below.

The Test Results will be updated as Passed, Failed, or Not Completed and a test completion test summary report will be produced at the end by the QA team lead.

Bug Life Cycle and Reporting

All bugs found during the testing phase will be reported using the defect tracking tool JIRA,TFS,QC(Test Managemet Tool) The tester will assign the defect to the development team. Once the developer fixes the defect, the status of the defect is changed to Awaiting QA. The tester will then retest the defect in the latest build available and change the status of the defect to Done/Failed QA accordingly.

3.2 Entry Criteria
Entry criterion is used to determine when a given test activity should start. It also includes the beginning of a level of testing, when test design or when test execution is ready to start.
  • Test enviornment are ready to use like  browser (if web application), Tablets or Devicesif(Mobile Application)
  • Test tools installed are ready to use
  • Test data is available 
    3.3      Exit criteria
    All entry criteria met.
    Test Summary Report has been produced, reviewed and approved by the Delivery   Manager.

      All Critical, High and Medium priority defects have been retested and closed.

 3.4 Item Pass/Fail Criteria
  Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.
A test will be considered passed if the actions described in the test meet the ‘expected output’ for all steps described in the test case.
 If the output is not as expected, it will be reported and investigated to determine where the problem lies. 
3.5 Suspension Criteria and Resumption Requirements
Testing may be suspended under the following circumstances: -
• A discrepancy between the information contained in the Requirements, the Work Flow diagrams and the software delivered.
• The delivered functionality is not functioning well enough for the tests to be meaningful
• A defect is found in the software, which means that further testing is impossible
• A defect is found in the software which affects further test cases, or renders them inoperable
The following activities must be carried out on resumption of testing: -
• Checks must be carried out on any corrections which have been made, to ensure that the corrective action does not affect the rest of the system (Regression)
• Unless the tester is absolutely certain about the impact of a change, then the entire Test will be re-run 
• New test cases may have to be written to test the changes
• The system must be restored to a known stable state before testing commences
3.6 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
4.Test Enviornment 
Specify the properties of test environment: hardware, software, network etc.
List any testing or related tools like Selenium, qtp,Sahi

5       Test Data

All test data identified will be specified in a separate document, i.e.Test Data Specification document.

6      Test tools

Test management tool JIRA,TFS,QC will be used during this project  for all Test Cases.
JIRA will be used for defect reporting and management.
Selenium  and Qtp is also introduced for Automation testing which will be used if the time permits.    

7       Responsibilities

  1.      The preparation and execution of the testing will be carried out by the Quality Analyst Test Team
  2.       The development team will provide the environment specification
  3.  The Business Analyst team will provide with all the user stories and use cases.
  4.  Quality Analyst will review all test products (specifications, reports, etc.).
8    Resource
QA test analysts will carry out the test preparation phase.
QA Team Lead – DDM,
QA Test Analyst – Ritika

 9.     Schedule

The test cases to be executed would have been identified from the relevant use case specification in this project it is from the user stories created in JIRA,

10.Test Estimation    
Test Estimation is like How many user stories we have.Based on user stories how many test cases we can write.How many total test script we can write.Its like an estimation of whole project.
11.Risk  and Contignious


 

12   Defect Management/ Problem Severity 

All problems found during the testing phases will be logged uing JIRA,  each problem will be assigned a severity by the QA team; the classification of defect reporting is given in the table below.  The delivery manager will make the final decision on severity classifications in the event that there are any disagreements.  The developers shall also use these severity definitions for problems that they identify during their Unit testing.

Severity 
1 Critical – the system is broken and cannot be used, major functionality is impaired, or there is data loss. There are no workarounds. Problems are so severe that the timescales cannot be met. Testing may need to be suspended and the problem resolved.

2 Major - the fault renders several system elements unusable, or affects one or more system elements. Workarounds exist which may be unacceptable to the customer. Problems that will jeopardise the launch unless corrected.

3 Medium - the fault affects system elements that are not key to the overall functionality of the system.   The system continues to produce correct results and data is not affected. Acceptable workaround may exist.

4 Low/Trivial – this fault barely affects the quality of a system and will only be fixed if time permits.