Archive

Posts Tagged ‘Test Plan’

Web Test Plan Development

Web Test Plan Development
The objective of a test plan is to provide a roadmap so that the Web site can be evaluated through requirements or design statements. A test plan is a document that describes objectives and the scope of a Web site project. When you prepare a test plan, you should think through the process of the Web site test. The plan should be written so that it can successfully give the reader a complete picture of the Web site project and should be thorough enough to be useful. Following are some of the items that might be included in a test plan. Keep in mind thatthe items may vary depending on the Web site project.
The Web Testing Process

  • Internet
  • Web Browser
  • Web Server
PROJECT

  • Title of the project:
  • Date:
  • Prepared by:
PURPOSE OF DOCUMENT

  • Objective of testing: Why are you testing the application? Who, what, when, where, why, and how should be some of the questions you ask in this section of the test plan.
  • Overview of the application: What is the purpose of the application? What are the specifications of the project?
TEST TEAM

  • Responsible parties: Who is responsible and in charge of the testing?
  • List of test team: What are the names and titles of the people on the test team?
RISK ASSUMPTIONS

  • Anticipated risks: What types of risks are involved that could cause the test to fail?
  • Similar risks from previous releases: Have there been documented risks from previous tests that may be helpful in setting up the current test?
SCOPE OF TESTING

  • Possible limitations of testing: Are there any factors that may inhibit the test, such as resources and budget?
  • Impossible testing: What are the considerations involved that could prevent the tests that are planned?
  • Anticipated output: What are the anticipated outcomes of the test and have they been documented for comparison?
  • Anticipated input: What are the anticipated outcomes that need to be compared to the test documentation?
TEST ENVIRONMENT: Hardware:

  • What are the operating systems that will be used?
  • What is the compatibility of all the hardware being used?

Software:

  • What data configurations are needed to run the software?
  • Have all the considerations of the required interfaces to other systems been used?
  • Are the software and hardware compatible?
TEST DATA

  • Database setup requirements: Does test data need to be generated or will a specific data from production be captured and used for testing?
  • Setup requirements: Who will be responsible for setting up the environment and maintaining it throughout the testing process?
TEST TOOLS

  • Automated:Will automated tools be used?
  • Manual:Will manual testing be done?
DOCUMENTATION

  • Test cases: Are there test cases already prepared or will they need to be prepared?
  • Test scripts: Are there test scripts already prepared or will they need to be prepared?

PROBLEM TRACKING

  • Tools: What type of tools will be selected?
  • Processes: Who will be involved in the problem tracking process?
REPORTING REQUIREMENTS

  • Testing deliverables: What are the deliverables for the test?
  • Retests: How will the retesting reporting be documented?
PERSONNEL RESOURCES

  • Training:Will training be provided?
  • Implementation: How will training be implemented?
ADDITIONAL DOCUMENTATION

  • Appendix:Will samples be included?
  • Reference materials:Will there be a glossary, acronyms, and/or data dictionary?
Once you have written your test plan, you should address some of the following issues and questions:

  • Verify plan. Make sure the plan is workable, the dates are realistic, and that the plan is published. How will the test plan be implemented and what are the deliverables provided to verify the test?
  • Validate changes. Changes should be recorded by a problem tracking system and assigned to a developer to make revisions, retest, and sign off on changes that have been made.
  • Acceptance testing. Acceptance testing allows the end users to verify that the system works according to their expectation and the documentation. Certification of the Web site should be recorded and signed off by the end users, testers, and management.

Test reports. Reports should be generated and the data should be checked and validated by the test team and users.

Web Test Plan Development

Web Test Plan Development
The objective of a test plan is to provide a roadmap so that the Web site can be evaluated through requirements or design statements. A test plan is a document that describes objectives and the scope of a Web site project. When you prepare a test plan, you should think through the process of the Web site test. The plan should be written so that it can successfully give the reader a complete picture of the Web site project and should be thorough enough to be useful. Following are some of the items that might be included in a test plan. Keep in mind thatthe items may vary depending on the Web site project.
The Web Testing Process

  • Internet
  • Web Browser
  • Web Server
PROJECT

  • Title of the project:
  • Date:
  • Prepared by:
PURPOSE OF DOCUMENT

  • Objective of testing: Why are you testing the application? Who, what, when, where, why, and how should be some of the questions you ask in this section of the test plan.
  • Overview of the application: What is the purpose of the application? What are the specifications of the project?
TEST TEAM

  • Responsible parties: Who is responsible and in charge of the testing?
  • List of test team: What are the names and titles of the people on the test team?
RISK ASSUMPTIONS

  • Anticipated risks: What types of risks are involved that could cause the test to fail?
  • Similar risks from previous releases: Have there been documented risks from previous tests that may be helpful in setting up the current test?
SCOPE OF TESTING

  • Possible limitations of testing: Are there any factors that may inhibit the test, such as resources and budget?
  • Impossible testing: What are the considerations involved that could prevent the tests that are planned?
  • Anticipated output: What are the anticipated outcomes of the test and have they been documented for comparison?
  • Anticipated input: What are the anticipated outcomes that need to be compared to the test documentation?
TEST ENVIRONMENT: Hardware:

  • What are the operating systems that will be used?
  • What is the compatibility of all the hardware being used?

Software:

  • What data configurations are needed to run the software?
  • Have all the considerations of the required interfaces to other systems been used?
  • Are the software and hardware compatible?
TEST DATA

  • Database setup requirements: Does test data need to be generated or will a specific data from production be captured and used for testing?
  • Setup requirements: Who will be responsible for setting up the environment and maintaining it throughout the testing process?
TEST TOOLS

  • Automated:Will automated tools be used?
  • Manual:Will manual testing be done?
DOCUMENTATION

  • Test cases: Are there test cases already prepared or will they need to be prepared?
  • Test scripts: Are there test scripts already prepared or will they need to be prepared?

PROBLEM TRACKING

  • Tools: What type of tools will be selected?
  • Processes: Who will be involved in the problem tracking process?
REPORTING REQUIREMENTS

  • Testing deliverables: What are the deliverables for the test?
  • Retests: How will the retesting reporting be documented?
PERSONNEL RESOURCES

  • Training:Will training be provided?
  • Implementation: How will training be implemented?
ADDITIONAL DOCUMENTATION

  • Appendix:Will samples be included?
  • Reference materials:Will there be a glossary, acronyms, and/or data dictionary?
Once you have written your test plan, you should address some of the following issues and questions:

  • Verify plan. Make sure the plan is workable, the dates are realistic, and that the plan is published. How will the test plan be implemented and what are the deliverables provided to verify the test?
  • Validate changes. Changes should be recorded by a problem tracking system and assigned to a developer to make revisions, retest, and sign off on changes that have been made.
  • Acceptance testing. Acceptance testing allows the end users to verify that the system works according to their expectation and the documentation. Certification of the Web site should be recorded and signed off by the end users, testers, and management.

Test reports. Reports should be generated and the data should be checked and validated by the test team and users.

Test Plan

February 13, 2008 1 comment

Test Plan

The test strategy identifies multiple test levels, which are going to be performed for the project. Activities at each level must be planned well in advance and it has to be formally documented. Based on the individual plans only, the individual test levels are carried out.

Entry means the entry point to that phase. For example, for unit testing, the coding must be complete and then only one can start unit testing. Task is the activity that is performed. Validation is the way in which the progress and correctness and compliance are verified for that phase. Exit tells the completion criteria of that phase, after the validation is done. For example, the exit criterion for unit testing is all unit test cases must pass.

Unit Test Plan {UTP}

The unit test plan is the overall plan to carry out the unit test activities. The lead tester prepares it and it will be distributed to the individual testers, which contains the following sections.

What is to be tested?

The unit test plan must clearly specify the scope of unit testing. In this, normally the basic input/output of the units along with their basic functionality will be tested. In this case mostly the input units will be tested for the format, alignment, accuracy and the totals. The UTP will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be exhaustive; but it is better to have a complete list of these details.

Sequence of Testing

The sequences of test activities that are to be carried out in this phase are to be listed in this section. This includes, whether to execute positive test cases first or negative test cases first, to execute test cases based on the priority, to execute test cases based on test groups etc. Positive test cases prove that the system performs what is supposed to do; negative test cases prove that the system does not perform what is not supposed to do. Testing the screens, files, database etc., are to be given in proper sequence.

Basic Functionality of Units

How the independent functionalities of the units are tested which excludes any communication between the unit and other units. The interface part is out of scope of this test level. Apart from the above sections, the following sections are addressed, very specific to unit testing.

  • Unit Testing Tools
  • Priority of Program units
  • Naming convention for test cases
  • Status reporting mechanism
  • Regression test approach
  • ETVX criteria

Integration Test Plan

The integration test plan is the overall plan for carrying out the activities in the integration test level, which contains the following sections.

What is to be tested?

This section clearly specifies the kinds of interfaces fall under the scope of testing internal, external interfaces, with request and response is to be explained. This need not go deep in terms of technical details but the general approach how the interfaces are triggered is explained.

Sequence of Integration

When there are multiple modules present in an application, the sequence in which they are to be integrated will be specified in this section. In this, the dependencies between the modules play a vital role. If a unit B has to be executed, it may need the data that is fed by unit A and unit X. In this case, the units A and X have to be integrated and then using that data, the unit B has to be tested. This has to be stated to the whole set of units in the program. Given this correctly, the testing activities will lead to the product, slowly building the product, unit by unit and then integrating them.

System Test Plan {STP}

The system test plan is the overall plan carrying out the system test level activities. In the system test, apart from testing the functional aspects of the system, there are some special testing activities carried out, such as stress testing etc. The following are the sections normally present in system test plan.

What is to be tested?

This section defines the scope of system testing, very specific to the project. Normally, the system testing is based on the requirements. All requirements are to be verified in the scope of system testing. This covers the functionality of the product. Apart from this what special testing is performed are also stated here.

Functional Groups and the Sequence

The requirements can be grouped in terms of the functionality. Based on this, there may be priorities also among the functional groups. For example, in a banking application, anything related to customer accounts can be grouped into one area, anything related to inter-branch transactions may be grouped into one area etc. Same way for the product being tested, these areas are to be mentioned here and the suggested sequences of testing of these areas, based on the priorities are to be described.

Acceptance Test Plan {ATP}

The client at their place performs the acceptance testing. It will be very similar to the system test performed by the Software Development Unit. Since the client is the one who decides the format and testing methods as part of acceptance testing, there is no specific clue on the way they will carry out the testing. But it will not differ much from the system testing. Assume that all the rules, which are applicable to system test, can be implemented to acceptance testing also.

Since this is just one level of testing done by the client for the overall product, it may include test cases including the unit and integration test level details.

A sample Test Plan Outline along with their description is as shown below:

Test Plan Outline

1. BACKGROUND – This item summarizes the functions of the application system and the tests to be performed.
2. INTRODUCTION
3. ASSUMPTIONS – Indicates any anticipated assumptions which will be made while testing the application.
4. TEST ITEMS – List each of the items (programs) to be tested.
5. FEATURES TO BE TESTED – List each of the features (functions or requirements) which will be tested or demonstrated by the test.
6. FEATURES NOT TO BE TESTED – Explicitly lists each feature, function, or requirement which won’t be tested and why not. 7. APPROACH – Describe the data flows and test philosophy.
Simulation or Live execution, Etc. This section also mentions all the approaches which will be followed at the various stages of the test execution.
8. ITEM PASS/FAIL CRITERIA Blanket statement – Itemized list of expected output and tolerances
9. SUSPENSION/RESUMPTION CRITERIA – Must the test run from start to completion?
Under what circumstances it may be resumed in the middle?
Establish check-points in long tests.
10. TEST DELIVERABLES – What, besides software, will be delivered?
Test report
Test software
11. TESTING TASKS Functional tasks (e.g., equipment set up)
Administrative tasks
12. ENVIRONMENTAL NEEDS
Security clearance
Office space & equipment
Hardware/software requirements
13. RESPONSIBILITIES
Who does the tasks in Section 10?
What does the user do?
14. STAFFING & TRAINING
15. SCHEDULE
16. RESOURCES
17. RISKS & CONTINGENCIES
18. APPROVALS

The schedule details of the various test pass such as Unit tests, Integration tests, System Tests should be clearly mentioned along with the estimated efforts.

Categories: Test Plan Tags: