What Are the Basic Steps in System Planning?

Test Plan
In software testing, there are many levels at which software gets to test. So to test software, a software tester has to first plan the whole process of testing. A responsible test lead receives the test strategy document and then prepares the master and detailed test plans with respect to that strategy document. Every test plan defines the following:

What to test?
How to test?
When to test?
Who to test?

Inputs	Process	Output
BRS,S/WRS & Design documents	Testing team formationT
Development Plan	Identify tactical risks	Test plan (s) document.
Test Strategy	Review Test Plan

Jump to Section

Test Approach:

This is a very important field in the test plan document. It indicates the overall process to be followed by the testing team during system testing, and that process is termed as Test Strategy.
Furthermore, the test approach in test plan document refers that the strategy document and usually considered an integral way of this Test Plan. Generally, a Test Strategy document deals with the following concepts:

Scope and objective of the testing process
The business issues for system testing
Applying reasonable tests
Involving roles and their corresponding responsibilities
Mode of communication and status reporting
Producing test deliverables

Testing Team Formation:

Basically, The test plan should initiate with the team of the testing formation. The capability of the testing team greatly affected by the success, or failure, of the testing effort. Therefore, A smart testing team involves a mixture of technical as well as domain expertise relevant to the requirements. This is not much better for a team of testing to be technically proficient with the testing tools and techniques desired to operate the real tests. In Additional, based on the simplicity of the domain, a testing team must also include an employee who has a brief and clear understanding of the requirements that enable a team to build effective test deliverables and test data and to implement test scripts and another various test mechanisms.

Identify Tactical Risks:

The test lead analyzes risks and tries to define. We describe some of the risks usually encountered:

Lack of knowledge on a domain for a selected test engineer.
Lack of budget and time.
Improper documentation.
Lack of resources.
Delay in delivery
Lack of development process rigor.
Lack of Communication.

Prepare Test Plan:

Furthermore, The test team prepares test plans. Most of all tester normally uses IEEE format(829) or like that formats. They are:

Test Plan ID:

It is a unique company which generates a number to identify the test plan and, the generated number helps to identify either the master plan and that plan level it represents. Therefore, it assists in coordinating the software as well as testware versions within the configuration management repository. By keeping this in mind test plans will have revision numbers, like other software documents, as they are dynamic in nature and must be kept up to date. If there is a need for including the revision history information as a part of, either the identifier section or the introduction.

Test Items:

Here I want to inform that, These are the most important things that you intend to test within the scope of this test plan. You can develop it from the software requirements and other resources of documentation and information. Remember, what is to be tested and what you intend to deliver to the client. Basically, this type can be oriented to the next level of this test plan. For higher levels, this may be through application or functional area, for the lower level it may be to program, module, or build.

Features to be Tested:

Here, we are discussing the functional area that we should test in the respective system. It will be discussed from the perspective of the end user, but not in pure technical orientation and will prioritize as critical, major and minor based on the risk analysis complete each functional area of the system.

Features not be Tested:

Here we discuss what functional area, not the test of the respective system and those will be discussed in perspective of the end user. You must keep remembering that which parts of the machine are functional areas to be excluded from testing is usually based on the many numbers of reasons? It may be either because that feature is not included in the current version of the software or because of less impact of that exclusion on the system as it bears the minor risk and is relatively considered as stable.

Test Environment:

It defines whether there are any special requirements for test plan:

Special hardware, such as simulators, static generators, etc.
How will the test data be provided? Are their special collection requirements or specific ranges of
data that must be provided?
How much testing will complete on each component of a multi-part feature?
Special power requirements.
A specific version of other supporting software.
Restricted use of the system during testing.

Test Deliverables:

System Testing deliverables that are to be specified as a part of the plan are:
Test case titles or test scenarios
A master plan and detailed test plan
Test case design specification
Simulators and data generators
Test automation scripts
Execution Logs and Defect Logs

Responsibilities:

Responsibilities are based on the question of who is the in-charge of a particular activity. Especially when we assign some activities to an individual:

Risk analysis and assumptions
Selection of features which you want to test as well as not be tested.
Selection of reasonable tests to be applied to the features
Making sure the availability of all required resources and their collection in the Test environment.
Handling change as well as configuration management issues.
Handling communication between development team and testing team.
Scheduling and arranging training programs

Review Test Plan

After test plan preparation to estimate the fullfillness and accuracy of that document, the test leads category people reviews the document with the help of the project manager, In this review, the test leads category people uses coverage analysis:

Requirements based coverage (What to test)
Strategy based coverage (How to test)
Risks based coverage (who to test and when to test)
After completing the test plan review, the testing team gets involved in the training session as soon as possible to understand the customer requirements or business logic.

Conclusion

With this, we come to an end of this article and I just want to add that the Test plans outline is the technique of testing the basic functionality of the software. So it is very important to make an accurate test plan for system testing, last but not the least system planning plays a very important role in developing a software application. So You should use a test plan if you are seeking to eliminate defect and other errors in your software before it becomes available to customers.
However, suggestions and queries are always welcome, so, do connect with me through the comment section.

Thank You for Reading.!!!

About
Latest Posts

Follow me!

Maneet Kaur

QA Engineer at Loginworks Softwares

I am a Quality Assurance Engineer who loves to work hard and make sure that the quality specifications and technical design documents are highly detailed, comprehensive, and well structured. Estimating, prioritizing, planning, and coordinating quality testing activities are the few responsibilities that fall under my purview as a QA Engineer. Now when I am not busy scrutinizing the digital documents, I spend my time flipping through the more traditional pieces of texts. Yes, I love to read and by that, I mean read a lot, whether it be novels, magazines, blogs, or just a random newspaper article. I make sure that in my leisure time too I am doing something meaningful and enhancing my knowledge of worldly stuff. And yes my favorite author is Khaled Hosseini, and I would recommend his beautifully written books to be read by each and every one.