Active TopicsActive Topics  Display List of Forum MembersMemberlist  CalendarCalendar  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin


 One Stop Testing ForumSoftware Testing @ OneStopTestingTest Plans @ OneStopTesting

Message Icon Topic: Creating a Test Plan

Post Reply Post New Topic
Author Message
Mithi25
Senior Member
Senior Member
Avatar

Joined: 23Jun2009
Online Status: Offline
Posts: 288
Quote Mithi25 Replybullet Topic: Creating a Test Plan
    Posted: 27Jul2009 at 11:41pm

Early in the deployment planning phase, the testing team creates a test plan. The test plan defines the objectives and scope of the testing effort, and identifies the methodology that your team will use to conduct tests. It also identifies the hardware, software, and tools required for testing and the features and functions that will be tested. A well-rounded test plan notes any risk factors that jeopardize testing and includes a testing schedule.

If your testing team is divided into technology subteams, each subteam should develop a test plan for that team’s specific technology area. For example, the networking team would write a test plan for testing networking features. All members of each subteam should review and approve its team’s test plan before it is integrated into the general test plan.

Figure below illustrates the tasks you must perform to create the test plan.

 Creating a Test Plan

Creating a Test Plan                                               
           
Defining Testing Scope and Objectives:In the scope and objectives section of the test plan, the testing team describes specifically what you want your testing to accomplish. For example, the objective of one team was to migrate the Microsoft® Windows NT® Server 4.0 operating system environment to a Windows Server 2003 environment, component by component, keeping the access control lists (ACLs) and Exchange permissions intact. Another team’s objective was to provide a means to measure network traffic and observe server performance during specific directory service tasks.

Also, you need to define the scope of your testing by identifying what you will test and what you will not. For example, you might limit your testing of client computer hardware to the minimum supported configurations or to the standard configurations.

Defining Testing Methodology: Describe the general methodology that your team will use for testing. For example, your approach to testing schema changes might be to configure an isolated domain in the test lab where schema changes can be applied without affecting other lab tests. This section of the test plan might address the following:
  • The domain architecture used for testing
  • The tools and techniques used to conduct the tests or to measure results
  • Automated techniques you plan to use during testing
Identifying Required Resources:Identify the resources required for the test lab:

Hardware   List the hardware that you need to conduct tests. For example, identify the standard configurations you plan to support for client computers. Include components such as video cards, modems, and external drives.

Software   List the software that you need to test the compatibility of your applications with Windows Server 2003. For example, include Microsoft® Systems Management Server (SMS) or other server-based products that you need for testing.

Databases   Include databases that you need to prepare for testing applications. Also include a description of the resources that you need to populate the databases, such as personnel and business data.

Personnel   Identify the number of testers you need and the skill level required. Include consultants and other support personnel, as necessary.

Training   Specify the Windows XP Professional or Windows Server 2003 training that your testers need to complete prior to testing their assigned applications or technologies.

Tools   Include all tools or scripts that you need to automate testing and to track test results. For example, if you do not have a second test lab that you can use for testing wide area network (WAN) links, include link simulators.

Identifying the Features and Functions to Test:

List all the features or aspects of features that need to be tested. This part of the test plan describes what to test, not how to test.

The following is an example of a feature test description:

  • Test 1 — Trust retention
    Description: All trusts to and from a domain should be retained when the domain controllers are upgraded to Windows Server 2003. Use the Domain Tree Manager to view the trusts. If the trusts do not appear, then the test failed.

Note that the description does not include instructions on how to perform the test.

Include tests that verify or address:

  • The functionality of each feature and service that you will implement.
  • Interoperability with existing components and systems in the production environment, both during the phase-in period, when there is a mix of old functionality and new Windows Server 2003 functionality, and after the Windows Server 2003 environment has been rolled out.
  • Hardware and driver compatibility for every type of client computer that will be running Windows XP Professional.
  • Application compatibility for every application that will run on Windows XP Professional.
  • Application compatibility for every server application that will run on Windows Server 2003.
  • Optimization of configurations, such as those for standardized desktops on client computers.


In addition, list:

  • Baselines (a range of measurements derived from performance monitoring that represents acceptable performance under typical conditions) for performance monitoring.
  • Baselines and stress tests for capacity planning.
  • Procedures for deployment and post-deployment administration, such as procedures for upgrading a client computer and for backing out of a faulty rollout process.
  • Required tools and utilities.
Identifying Risk Factors:Describe the risk factors that could prevent the successful completion of all required tests. For example, you might find that the test lab is behind schedule, or that required hardware or software is unavailable, or that testers are working on other projects or need additional training. After you have identified the risk factors, decide what you will do to avoid or mitigate each risk.
Draft a preliminary schedule that includes each test listed in the test plan. The schedule can help you coordinate test lab use among subteams. Assign a team member, ideally the test lab manager, if your team has one, to maintain and update the lab schedule. Having an up-to-date schedule is critical when unscheduled lab requests are submitted.
Establishing a Testing Schedule:



Post Resume: Click here to Upload your Resume & Apply for Jobs

IP IP Logged
cool7575
Newbie
Newbie


Joined: 13Sep2007
Online Status: Offline
Posts: 28
Quote cool7575 Replybullet Posted: 30Jul2009 at 3:15am
Also do not forget to include the test data part. how data will be collected, stored and mapped with the test cases.

Thanks
Raj

Software Testing
IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.297 seconds.
Vyom is an ISO 9001:2000 Certified Organization

© Vyom Technosoft Pvt. Ltd. All Rights Reserved.

Privacy Policy | Terms and Conditions
Job Interview Questions | Placement Papers | Free SMS | Freshers Jobs | MBA Forum | Learn SAP | Web Hosting