MY PROJECT
                   System Test Plan
            << Version: 1.0 >>
                                         Date: 24.01.2012

                                                                                                           



This and all subsequent versions of this document will be located in the project SharePoint site.
Revision Date(dd/mm/yy)
Summary of Changes
Modified By
0.1
24/11/2011
Initial draft

Distribution/Review
Name
Title
MR. xxx
Project Manger

Referenced Documents
Document and Version #
Date(dd/mm/yy)
Functional Requirement Document  Version
7/12/2011

Name
Title
xxx
 Technical (Hardware) Team Lead
     
Prepared By:
Name
Title
xxx
  Test Lead
                                                                              



My Project……………………
Purpose of Document
The purpose of this document is to detail the Functional-testing tasks for the “MY PROJECT” project. This document includes the end-to-end Functionality testing activities planned.

                Functional testing consists of a series of functional tests of workflows and transactions created and executed to identify and measure the quality of software. The testing will simulate user interaction with the system  so  that  functionality  of  the  system  can  be  evaluated  with  different  User  Roles.  The testing methodologies used for different types of functional testing of the “MY PROJECT” application will be documented with results and observations.
Functional testing involves testing of the system functionality against the specification requirements predefined. As the Test cases are executed and defects found will be reported to developers through authorized Channels. Tests are then repeated to close the open bugs. Functionality Testing will be performed until a predefined success criterion is achieved.








Acronym
Description
ST
System Test
QA
Quality Assurance
UAT
User Acceptance Test
P&C
Performance, Capacity and Failover  Testing
CCB                                        
Change Control Board
BRD
Business Requirement Document
SRS
Software Requirement Specifications
TBD
To Be Determined
SLA
Service Level Agreements






Test Overview                                                                                                                                                                  
       Validate that the system behavior is same as specified in the Functional Requirement Specification document.


           Assure that the system meets the full requirements, including quality requirements (Functional, Non-functional requirements). The user should find that the project has met or exceeded all of their expectations as detailed in the requirements at end of the project development life cycle.
         Identify and expose all issues and associated risks, communicate all known issues to the     project team, and ensure that all issues are addressed before release.  
The test plan for the system should support following objectives:

•     Identify which features of the system will be tested.

•     Define the pass/fail criteria for each feature to be tested.

•     Specify the testing approaches that will be used during testing.

•     Identify the deliverables of the testing process.



Scope
 The “MY PROJECT” Test Plan defines the unit, integration, system, regression, and User Acceptance   testing approach. The test scope includes the following:         
        Testing of all functional, application performance, security and use cases requirements listed in the Use Case document.
        End-to-end testing and testing of interfaces of all systems that interact with the TR.

1.     Features to be tested:
Testing of Functional behavior and Business Logic of the following Modules need to tested in this version are been clearly mentioned here
·         Registration
·         Login modules  
·         Total functional/non functional check will be done in the Phase-1
·         Owner
·         Tenant
·         Admin
Inclusions:
        Creation of Test Cases
        Creation of Test Data
        Test Case Execution
        Reporting Defect Status
        Unit Testing 
        Regression Testing
        System Testing
        User Acceptance
        Network Testing





    

        Out-Of-Scope:
        Performance Testing
        Automation
The list of all the features that are not planned for testing based on the following criteria will be listed out here in this section
·         Mailing concept
·         Low risk features
·         The functionalities that are planned to be incorporated in future
·         The features that are to be skipped based on the time constraints.

The following items are excluded from ST scope of this project:

        Performance Testing
        Stress Testing
        Load Testing Scenarios



The following general assumptions apply:

·         Adequate testing resource for system testing phase is available.

·         The test environment for “MY PROJECT” is available is the system test region.

·         The test environment with full production data (after masking the data) capacity is available in system test region.

·         No further changes or enhancements will be made to functional and technical documents after the walkthrough unless it is mutually agreed upon.

·         New code is Unit and ST tested by the development team and delivered on time.

·         Testing resources assigned to this project will be available for the duration of the project.

·     All showstopper defects related to the new code will receive immediate attention by the developers

The following are dependencies for this project:

  • Availability of System test environment without instability & unavailability
  • Connectivity to System test server (Stability and Speed)
  • Unplanned outages due to production issues in system test environment

The test team requires experience test analyst to develop, perform and validate tests.
The source code must be unit tested and provided within the scheduled time outlined in the Project Schedule.
Hardware Dependencies
 3 PCs (with specified hardware/software) as well as the LAN environment need to be available during normal working hours. Any downtime will affect the test schedule.
Schedule:   
The schedule for each phase is very aggressive and could affect testing. A slip in the schedule in one of the other phases could result in a subsequent slip in the test phase. Close project management is crucial to meeting the forecasted completion date.

Technical:
Since this is a new system project. We will run our project in the TEST environment as it is developed phase wise and after completing all the Phases which are planned will go to the production like environment.
     
       Management:
        Management support is required so when the project falls behind, the test schedule does not get squeezed to make up for the delay. Management can reduce the risk of delays by supporting the test team throughout the testing phase and assigning people to this project with the required skills set.
Personnel: 
Due to the aggressive schedule, it is very important to have experienced test analyst on this project. Unexpected turnovers can impact the schedule. If attrition does happen, all efforts must be made to replace the experienced individual
      Requirements:
 The test plan and test schedule are based on the current Requirements Document. Any changes to the requirements could affect the test schedule and will need to be approved.
  


Risks description, Probability and impact of system in below table:
SL.NO
Risk
Risk of Occurrence
Risk of Impact
contingencies
1
Any delay in getting the necessary reviews / approvals for the System test stage may impact effort and schedule
L
M
Before the testing starts the test plan and test scenarios and scripts must be signed off.
2
Any delay in installing “MY PROJECT” application into Test environment will delay the testing.
H
H
Ensure that Before starting of ST the said “MY PROJECT” application should be installed.
3
Any delay in getting the test environment with production data capacity will delay the testing.
H
H
Test environment should be ready and functional before the ST starts.
4
Delays in response / support from SME’s will impact effort and schedule
M
M
The test leads must be informed about the daily execution status and other concerns on daily basis.

The list of all the potential risks we have assumed here are some more corresponding solution (contingences) plans are been listed.
·         Proper planning should be done, by taking into consideration of all aspects of Testing.
·         Employee bench strength needs to be maintained.
·         What not to be tested has to be planned in case of imposed dead lines.
·         Proper Training needs to be provided.

  
Issues

In-case any product related issues arise during installation and configuration, report up-gradation and conversion, assistance from “MY PROJECT” Team is required for the test team.


All other ongoing testing related issues that come up during the course of the project will be raised by the team and managed through “MY PROJECT” Project Management process.
       
         The test strategy consists of a series of different tests that will fully exercise the “MY PROJECT” system. The primary purpose of these tests is to uncover the systems limitations and measure its full capabilities.

 Overview    

      The System Testing is designed to test the completeness, consistency and accuracy of the “MY PROJECT”software application. It will be tested based on the business and system requirements. The System Test Plan ensures not only that the code function as designed but also that the appropriate business rules are tested whenever possible. Any defects or defects found will be tracked in Bugzilla.
System test requirements are identified as extracted from the Detailed Business Requirement document. Which are documented in the System Test Traceability Matrix? This traceability matrix maps business requirements, system requirements to test cases, to ensure complete test coverage of the requirements.
Detailed test cases are developed outlining the conations’,
1.       Test steps
2.       Test data
3.        Expected results
4.       Actual results
This will meet all the requirements identified in the Traceability Matrix.

The following formal reviews will occur in this test phase:
               
·         Walk through of the System Test Plan
·         Sign off of the System Test Plan
·         Walk through of the Traceability Matrix and System Test Cases
·         Review of defects in the weekly status meeting
·         Review of the test results


Following Test Types are relevant to ST phase of this project:

System Test:
The System tests will focus on the behavior of the “MY PROJECT” system. User scenarios will be executed against the system as well as screen mapping and error message testing. Overall, the system tests will test the integrated system and verify that it meets the requirements defined in the requirements document.
Security Test:
As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that
        Confidentiality
        Integrity
        Authentication
        Authorization
        Availability
        Non-repudiation.
          Confidential data (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.)
Security tests will determine how secure the “MY PROJECT” system is. The tests will verify that unauthorized user access to confidential data is prevented.
Regression Testing: 
A suite of tests will be developed to test the basic functionality of the “MY PROJECT” system and perform regression testing on areas of the systems that previously had critical/major defects.

Recovery Test:
Recovery tests will force the system to fail in a various ways and verify the recovery is properly performed. It is vitally important that all Admin Panel data is recovered even if any system failure & no corruption of the data occurred.     
Document Test: 
Tests will be conducted to check the accuracy of the user documentation. These tests will ensure that no features are missing, and the contents can be easily understood.

User Acceptance:
Once the “MY PROJECT” system is ready for implementation, the “MY PROJECT” client will perform User Acceptance Testing. The purpose of these tests is to confirm that the system is developed according to the specified user requirements and is ready for operational use.

Production data will be loaded on to the databases in the ST Environment, based on which reports will be generated.
Uploads Details: Blocks, Flat Types, Floor Numbers and Flat Numbers all this information should be collected before ST..

  
Test Automation should be implemented.
  

Following are the entry criteria that must be met:

·         The installation of “MY PROJECT” Application and configuration of all the licensed products in ST region is done.
·         The System test plan is reviewed and signed off.
·         The System test scenarios and scripts are reviewed and signed off.
·         The System test Cases which are prepared must meet the business requirements.
·         The System test environment is loaded with the production data.
·         The System test defect management process is defined and approved.
·         The System test Reporting process defined and approved.
·         The Independent ST Test Team has performed a ‘Mini’ shakedown of the environment prior to the start of Independent ST Execution.
·         Approval to start the System testing.
·         Environment is ready for System testing.



The ST Execution for this project includes the following testing to be carried out in order:
1.       Configuration and Installation Testing: To test if “MY PROJECT” application has been successfully installed in the ST environment.
·          Logging into computer mediate communication checking whether the Servers are up and Running

                                                                                                                                                                            
Test cases executed on the “MY PROJECT” will pass if they meet the specific requirements as mentioned in the BRS. A test case will fail if any behavioral expectation is not met as described.

  

·         Defects will be logged by test analyst when there is a mismatch between the expected and actual results
·         While raising a defect, it is to be ensured that all required information such as the test case ID, expected results, actual results, supporting evidence (such as screenshots), complete steps to help recreate the defect is captured
·         Defects will be tracked using the  Bugzilla
·         During daily defect triage meetings, appropriate Test Coordinator will review entered defects with the leads and will assign defects to appropriate team lead. Standard defect management process will be used.
·         Defects will be prioritized for resolution with input from the Business Team
·         Once, the defects have been fixed by the developer, it is re tested and closed if the defect is resolved

  
A problem or incident results from a program error.  A post-implementation change request that deviates from the specifications provided to development will not be classified as a problem or incident.  If the required change of functionality is equivalent in impact to a severity 1 or severity 2 error (as described below) it can prevent the completion of rollout into the production environment.

Severity focuses on the degree of impact that a defect has on the development or operation of a component or system. Severity does not define which defect to fix first.
Severity Level
Description
Severity 1
(Showstopper)
“Cannot use any part of the system until the problem is fixed.”  Unable to proceed with test or development.  The application (or system) may a bend, or hang repeatedly or there may be an unrecoverable data loss. According to SLA an immediate fix is needed within 1hour.
Severity 2
(Critical/ High)
“Can use the system, but a by-pass is required.”  Test or development is severely restricted due to a defect encountered for which there is no acceptable circumvention.  The application executes but wrong results are encountered, or problems are discovered which would significantly affect production operation. A fix is required in order to proceed with this function. According to SLA’s an immediate fix is needed within 2 hours.
Severity 3
(Medium)
“Functionality impacted, but testing can proceed.”  Able to proceed with limited functionality not crucial to test or development.  There may be discrepancies between product operation and the product documentation.  Additionally, any problem that is caused by extreme or unlikely circumstances, environments or operator sequences, provided a straightforward workaround exists and there is no unrecoverable data loss. According to SLA’s an immediate fix is needed within 1day.
Severity 4
(Low)
“Shortcoming.”  No immediate impact to test or development.  This could be an incorrectly spelled word or poorly worded error message.  Discrepancies are found that are of an insignificant nature and do not affect satisfactory operation or usability of the product.  Examples may include improper presentation of menus, messages, prompts or minor functional deviations that can be easily avoided.  Also, included may be usability or certain types of performance concerns.  Fixes should take place only after all severity 1, 2 and 3 problems have been resolved.
Severity 5 (Enhancements)
Enhancement request or design issue.  References user suggestions for change to code and/or appearance, which were not initially defined as part of requirements.
  




Defect Priority Definitions
Priority focuses on the business impact of the reported defects and the sequence they are to be fixed, retested and promoted to production.

Priority Level
Description
Priority 1 (Urgent)
Further development and/or testing cannot occur until the defect has been repaired. The system cannot be used until the repair has been made. This defect has a major impact on the customer. It must be fixed immediately.
Priority 2 (High)
The defect must be resolved as soon as possible because it is impairing development/and or testing activities. System use will be severely affected until the defect is fixed. This defect has a significant impact on the customer. The problem should be fixed before the release of the current version in development, or a patch must be issued if possible.
Priority 3 (Medium)
The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
Priority 4 (Low)
The defect is an irritant that should be repaired but can be repaired after the more serious defects have been fixed. This could be a minor cosmetic suggestion or usability issue.




·         All the test cases are executed and reviewed.
·         All the ST defects are retested and reviewed.
·         There are no Severity 1 or 2 defects and a limited number of Severity 3 or Severity 4 defects, which the business has approved, may be migrated to the next level of testing for resolution.
·         The test completion report is complete and approved
·         The ST phase Exit signoff and Walkthrough complete.
·         Business will sign off on the Independent ST results.



      Testing will provide specific deliverables during the project.  These deliverables fall into three basic categories: Documents, Test Cases / Bug Write-ups, and Reports.  Here is a diagram indicating the dependencies of the various deliverable:

https://3.bp.blogspot.com/-CjXlEmqhppU/T0XX6bQCdNI/AAAAAAAAAJ4/sEC2UGBSlZg/s320/testdeliverables.JPG



As the diagram above shows, there is a progression from one deliverable to the next.  Each deliverable has its own dependencies, without which it is not possible to fully complete the deliverable.

  

The following page contains a matrix depicting all of the deliverables that Testing will use.
Deliverable
Milestone
Documents
  Test Approach
Planning
  Test Plan
Design
  Test Schedule
Design
  Test Specifications
Development
Test Case / Bug Write-Ups
  Test Cases / Results
All
  Coverage Reports
All
  Bug Tracking System Bugs and Regression                Results
All
  Bug Tracking System Analyzer Bug Reports
All
Reports
  Weekly Status Reports
All
  Phase Completion Reports
All
  Test Final Report - Sign-Off
Stabilization




Below Table will give information which can be delivered as Test Deliverable to the Client.
Deliverable
Description
Owner
System Test Plan
Overall plan for the System Test
Test Lead
Traceability Matrix
Associates test cases to specific requirements being tested
Test Lead
System Test Cases
Set of test cases for ST
Testers
System Test Execution Schedule
Detailed execution plan for ST
Test Lead
System Test Summary Report
Report summarizing test results from ST
Test Lead
System Test Defect Reports
Individual test reports from individual ST tests
Test Lead
System Test Test-Phase Exit Sign-Off
Sign off to indicate completion of ST
Test Lead


A   ST Summary Report is generated at the end of ST phase followed by ST Phase Exit Signoff and Walkthrough. Also, Lessons Learnt and Best Practices for the completed ST phase will be documented.



 DEV & TEST Environments

System / Component
Hardware
Software / Platform
Notes
Development Team
Server Name: Linux server
                                
IP Address:  xxxx
Web Application Server:tomcat
OS:  windows xp professional
Repository: cvs
Data Sources: oracle 10g,

Testing Team
Server Name: testsev.xxx.in
IP Address:  xxx
Web Application Server: tomcat
OS: windows xp professional
Repository:
Data Sources: oracle 10g

     

Details
Description
Server Host Name
Testsev.xxx.in
IP Address
/port
Operating System
Windows 2003 Server Ent
CMS Database
 ( content management system database)
Oracle 10g  
Web Application Server
IIS 6
Server Name
Testsev.xxx.in




                       
Task
Owner
Target Date
Status
Bugzilla for  test phase
ST team
30/1/2012
Planned
Promote code to the test environment
Development Team
TBD
Planned
Conduct Environment Sanity Check
Release Manager
TBD
Planned

  


Tool
Overview
Development Team Software
                                                Server Name: Rpct.com (For DEV Environment)
                                                IP Address: (For DEV Environment)
                        Visual studio 2008
                        VSS 2005


Testing Team
Bugzilla Version:3.6.1
Operating System :Windows 2003 Server Ent


Bugzilla Version:3.6.1




Reviews:  
The project team will perform reviews for each Phase. (i.e. Requirements Review, Design Review, Code Review, Test Plan Review, Test Case Review and Final Test Summary Review). A meeting notice, with related documents, will be emailed to each participant.
Bug Review Meetings:  
Regular weekly meeting will be held to discuss reported defects. The development department will provide status/updates on all defects reported and the test department will provide additional defect information if needed. All member of the project team will participate.
Change Request: 
Once testing begins, changes to the “MY PROJECT” system are discouraged. If functional changes are required, these proposed changes will be discussed with the Change Control Board (CCB). The CCB will determine the impact of the change and if/when it should be implemented.ST team will follow the Standards of “MY PROJECT” Management Process.
Defect Reporting:
When defects are found, the test analyst will complete a defect report on the defect tracking system. The defect tracking Systems is accessible by test analyst, developers & all members of the project team. When a defect has been fixed or more information is needed, the developer will change the status of the defect to indicate the current state. Once a defect is verified as FIXED by the test analyst, will close the defect report.



  During ST, the testers will assign the defects to developers. The resolution details are updated in Bugzilla under each fixed defect. The developer/lead designer will notify the tester to retest once code changes are made.

 Formal configuration control procedures will be applied for ST phase following the Standard “MY PROJECT” Change/Release Management processes. 
      Once  “MY PROJECT” application system code( programs) moved from the development portion of the to the test portion of the system will be controlled through the Formal Configuration Management application process this will ensure that code which is deployed is free zed. So that there will not any Ambiguity between Development Team and Test Team for Functionality..
All documents relating to this project will be placed into the project folder.
All key documents will be under version control.         
The ST Plan and the Test Cases will be uploaded in to VSS.

 “MY PROJECT” testing reports and charts will be produced. These include:
  • Test Progress chart
  • Passed vs. Tested
  • Closed vs. Total
  • Open vs. Close by severity
  • Defects by function
  • Application/System Availability

Note:
Tractability can be done in two ways i.e.
1. Forward Tractability
BRD/SRS>>Module>>Scenario>> Test Case ID:

2. Backward Tractability
Test Case ID>> Scenario>> Module>> BRD/SRS


Status           

What
Frequency
Audience
Current outstanding defects
Daily
Test leads
Defect summary by severity
Weekly
Management, test leads
Project status report
Weekly
PM, management
Team meetings
As required
Individual teams
The Test Lead and Project Manager will determine when system test will start and end. The Test lead will also be responsible for coordinating schedules, equipment, & tools for the test analysts as well as writing/updating the Test Plan, Weekly Test Status reports and Final Test Summary report. The test analysts will be responsible for writing the test cases and executing the tests.
The test team will consist of:
·         A Project Manager
·         A Test Lead
·         1  Test Analysts


https://2.bp.blogspot.com/-X6KpBU2F7Jo/T0XYDuq94oI/AAAAAAAAAKA/PyIhT-64DEc/s320/Team+Structure.JPG

           




Role
Responsibility
 Test Lead
1.       Regularly review system-testing progress with test team
2.       Raise and manage issues / risks relating to system test or outside test team control
3.       Support and participate in the development of system test documents, such as: System Test Plan, Traceability Matrix, System Test Execution Schedule, System Test Cases, and System Test Summary Report
4.       Report testing progress at regular status reporting meetings
5.       Ensure system test outages / problems are reported immediately and followed up
6.       Conduct defect review meetings
7.       Support and participate in planning the test effort for system test (Resources are yet to be finalized).
Test Analyst
1.       Review functional, system and technical specification documents (e.g. Business Requirements Document, Detailed Business Requirements Document)
2.       Identify the Scenarios’ and collect test data requirements for system tests
3.       Design and develop test cases for system test
4.       Execute system test cases, validate & document system test results
5.       Raise / report software defects(Bugzilla)
6.       Produce System Test Plan and Traceability Matrix for system test



If any defects are found which seriously impact the test progress, then it may choose to
Suspend testing. Criteria that will justify test suspension are:
§  Hardware/software is not available at the times indicated in the project schedule.
§  Source code contains one or more critical defects, which seriously prevents or limits testing progress.
§  Assigned test resources are not available when needed by the test team.
§  If build not passed the SANITY TEST
§  If build contain any serious session errors.
§  If build fail the security testing

If testing is suspended, resumption will only occur when the problem(s) that caused the suspension has been resolved. when a critical defect is the cause of the suspension, the “fix” must be verified by the test department before testing is resumed.



Position
Name
Contact Information
Project Manager
xxx
Test Lead
xxx
Technical SMEs (Development)
xxx
Business Analyst 
xxx
Technical Support
xxx

  • Bugzilla: Bugzilla will be defect tracking tool for this project. Hence, training is required on usage of Bugzilla.

The ST testing will be divided into two phases based on the below understanding:
·         Phase I –Testing the TR>> (27.1.2011 to 2.2.2012)
·         Phase II –  Testing the TR>> TBD
·         Phase III – Testing the TR>>TBD

Test Phase
Major Task and Description
Duration (# of Weeks)
 Phase 1-ST 
System Testing
1weeks
Phase  2-ST 
Phase  3-ST 

  

·         TR, Functional Requirement Documents.

·         Project Manager : Mr. xxx






Project Name:
TR
Document Name:
Test Plan
Version:
TR_TP_001
Issue Date:
24.01.2012
Issued By:
Sign-Off Group:

The contents of the System Test Plan document for ‘TR’ have been approved.
Your signature indicates agreement with document contents.




Sign-off Name:                                                                        Date: 

                                                < Approver’s name and title >

Sign-off Name:                                                                        Date: 

                                                < Approver’s name and title >









TrainingHUB. Powered by Blogger.

Total Pageviews

THE BEST QTP TRAINING INSTITUTE IN HYDERABAD

QTP Training in hyderabad

Sql Tutorial

Popular Posts

Our Facebook Page

TrainingHUB

Followers