A system test planning is the first thing that should happen in software testing. System test plans outline the process of testing the functionality of software and systems as well as describes the approach, objectives, resources, schedule, and scope of a software testing effort. It identifies the items to be and not to be tested, who will do the testing, the test approach to follow, the pass/fail criteria, training needs for team, etc. Use a test plan to eliminate bugs and other errors in your software before it becomes available online and/or to customers. 
Follow these steps to create a system test plan.
What Is a Test Plan?
A test plan in software and system testing is the document that outlines the who, what, when, how, and to do of a testing project. The plan highlights the projected resources, risks, and personnel involved in the test. The plan typically contains details of the strategy to be used to verify that a system meets its design specifications and other requirements. Depending on the product and organization’s mission, a test plan may include any of the following strategies:
· Unit Testing: tests whether individual units of source code, sets of one or more computer program modules, usage procedures, and operating procedures are fit for use.
· Integration Testing: combines and tests individual software modules to see if they are fit for use as a group.
· System Testing: is conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements to detect any inconsistencies between the software units that are integrated together and the hardware.
There are three elements in a test plan:
· Test Coverage: the requirements that will be verified during which stages of the product life.
· Test Methods: how test coverage will be implemented and used to verify hardware design requirements.
· Test Responsibilities: who will perform the test method and at each stage of the plan and what data will be collected and how that data will be stored and reported (i.e., deliverables).
Why Create A Test Plan?
So, why is it necessary to invest so much time and effort to create a test plan? Testing is important when creating website applications; it determines and controls the quality of deliverables. If you want to deliver a bug-free product, you need a good test plan. A test plan offers several benefits:
· It is the guide for the testing process approach and describes the testing practices to follow.
· It outlines the requirements and equipment needs essential to carry out the testing process.
· It helps to determine the time and effort required for testing the product.
· It contains details of the testing scope and clearly defines roles and responsibilities of every team member.
· It provides schedule for testing activities, providing a baseline schedule to control and track testing progress.
How to Write a Good Test Plan
A test plan drives a successful testing process. Now, you must think about how to write a good test plan. A good test plan is written by following these steps:
1. Analyze the Product. To create a successful test plan is to analyze the product, features, and functionalities (scope) to gain a deeper understanding of the application and target users.
2. Define Roles and Responsibilities. A good test plan clearly lists the roles and responsibilities of the testing team and manager (i.e., telling everyone what to do and when to do).
3. Develop Test Strategy. Your test strategy for each test levels can be composed of several testing techniques (see our Checklist section below).
4. Develop a Schedule. Divide the work into testing activities and estimate the required effort and resources for each task.
5. Anticipate Risks. Your test plan is incomplete without anticipated risks and risk responses. The types of risks in software and system testing that need to be accounted for include schedule, budget, expertise, and knowledge.
A checklist will come in handy to help identify what stage the project is in as well as standards and success measures. This will aid in the testing plan and provide the best feedback. There are nine types of testing:
1. Functionality Testing: test for all the links in web pages, database connection, forms used for submitting or getting information from user in the webpages, etc.
2. Cookies Testing: test if the application cookies are encrypted before writing to user machine and check effect on application security by deleting the cookies.
3. Database Testing: check for data integrity and errors while editing, deleting, modifying, or doing any other related functionality.
4. Usability Testing: test navigation, meaning how users surf the webpages, use different control functionalities, and how consumers use the links.
5. Content Checking: Content needs to be logical, meaningful, and easy to understand. Check for spelling errors, color usage, fonts, anchors, etc.
6. Interface Testing: Check that the interactions between servers are executed and errors are handled properly (e.g., if a user interrupts any transaction in-between, or if the connection to the web server is reset).
7. Compatibility Testing: Compatibility of your website is very important. Browser compatibility checks for configurations and settings the webpage should be compatible with. OS compatibility tests for functionality of your web application with operating systems. Mobile browsing tests your webpage compatibility on mobile browsers. Printing options tests that the fonts, page alignment, page graphics, and pages will be printed properly.
8. Performance Testing: Web application should sustain to heavy load. Web performance testing should include web load testing (how an application handles many users accessing or requesting the same page at the same time), web stress testing (performed to break/crash the site and checks how the system reacts and recovers).
9. Security Testing: tests the login security of your website by: pasting internal URLs onto the browser without logging in (these pages should not open), using username and password to browse internal pages then trying to change URL options directly (access should be denied), check the systems reaction on all invalid inputs, web directories or files should not be accessible without the download option, test the CAPTCHA for automates script logins, and test for if SSL is used for security measures.
The ISO/IEC/IEEE 29119 Standard
ISO/IEC/IEEE 29119, the updated Standard for Software Test Documentation, specifies the defined stages of software testing. The process approach is fundamentally risk-based testing and can support test planning and strategy development. ISO/IEC/IEEE 29119 has specified five stages in the documentation process.
Part 1 - Concepts and Definitions
Concepts and Definitions facilitate the use of the other parts of the standard by introducing the vocabulary on which the standard is built and provide examples of application. Part 1 provides the definitions, descriptions of the concepts of software testing, and ways to apply the software testing process (defined in Part 2).
Part 2 - Test Processes
Test Processes defines a standard process model that is intended for use when performing software testing. It contains test process descriptions that define the software testing processes at the organizational, test management, and dynamic test levels.
Part 3 - Test Documentation
Test Documentation includes templates of test documentation produced during the testing process. The templates support Test Processes in Part 2 by the test process in which they are produced. The documents defined in Part 3 are:
· Organizational Test Process Documentation
- Test Policy
- Organizational Test Strategy
· Test Management Process Documentation
- Test Plan (including a Test Strategy)
- Test Status Report
- Test Completion Report
· Dynamic Test Process Documentation
- Test Design Specification
- Test Case Specification
- Test Procedure Specification
- Test Data Requirements
- Test Data Readiness Report
- Test Environment Requirements
- Test Environment Readiness Report
- Actual Results
- Test Result
- Test Execution Log
- Test Incident Report
Part 4 - Test Techniques
Test Techniques offers standard definitions of software test design techniques that can be used during the design and implementation process defined in Part 2. The following are examples of test design techniques:
1. Specification-Based Test Design Techniques based on the (functional) specification of the system under test (e.g., equivalence partitioning, boundary value analysis, and syntax testing); also known as black-box testing.
2. Structure-Based Test Design Techniques based on the (internal) structure of the system under test (e.g., branch testing, decision testing, data flow testing); also known as white-box testing.
3. Experience-Based Test Design Techniques rely on the experience of the human tester (e.g., error guessing).
Part 5 – Keyword-Driven Testing
Keyword-driven testing is used to specifying software tests already widely used in the software testing industry. This is intended for users who want to build test automation based on keywords, create corresponding frameworks, and create keyword-driven test specifications.
A good test plan also helps you plan for resource support for all your projects, and creating a working test plan is easy. Identify the information you need for strategic planning and you’ll have created an updated reference for your team. To increase the value of your test plan, have it periodically reviewed by members of the project team. This can be done by agreeing amongst yourselves or through an internal approval process.