Keep in mind that a major goal of the test plan is to communicate details of the test to readers in all areas of an organization. Therefore, anything that enhances communication in the test plan helps connect with readers. In fact, there is no definitive answer to that question since the length of the test plan is driven by the specific context of the project. Obviously, projects that are large and complex will require more information to convey details of the testing effort than simpler and smaller projects.
A principle that is helpful to remember is that the longer the test plan, the less likely people are to actually read it. As mentioned earlier, many people scan instead of read. In addition, the longer the document, the more prone people will be to scan it. If the test plan is perceived to be too lengthy, people may ignore it entirely.
My personal guideline for test plans is to keep them less than fifteen or twenty pages, if possible. It is very helpful to have a software test plan template or standard with which to start. However, I often advise caution in following just any test plan example you might find online.
Test plans, like any document, can be flawed — in some cases, greatly flawed. In this standard you will find both traditional and agile test plan standards, as well as examples of both types of test plans. While some people feel standards are constraining, standards can also be your friend. Standards can provide guidance and examples based on many years of industry experience and practice, while eliminating the need to start your test planning efforts from a blank page. Standards must be tailored to meet your needs.
Therefore, it is perfectly fine to tailor and adapt the standard. Sometimes, industry groups also share test plan templates. It is worth the time to investigate this possibility if you are in an industry such as defense, finance, automotive, or medical.
One reason why people may tend to avoid test planning is that they know any plans will likely change. Test plans are no exception. However, the prospect of changes should not deter you from creating a test plan. The answer is actually based on a simple principle. The more detailed and specific the plan in terms of things like names, dates, risks, and technical details, the more brittle the test plan becomes when changes occur. But, what about the details that need to be conveyed in a test plan?
What value is the test plan without details? When it comes to things like test objectives, scope, other more solid details, those things typically survive change better than other details. For schedules, people and other details that are more change-sensitive, a good practice is to reference them in a way that changes can be recorded without prompting a new version of the test plan. Today, many people create test plans in content management systems that allow easy references to other items, such as schedules and estimates.
Test planning is an essential activity of testing, regardless of the project lifecycle approach. Step 2. Define your objectives. Your test plan should clearly define what you will test and why you will test it. These should always be based on industry standards. Step 3. Write a section on required resources. This section describes all of the resources needed to complete the testing, including hardware, software, testing tools, and staff.
Step 4. Write a section on risks and dependencies. Detail all the factors that your project depends on and the risks involved in each step. The level of acceptable risk in your project will help determine what you will and will not test.
Step 5. Write a section on what you are going to test. List what new aspects you will be testing and what old aspects you will be re-testing. Make sure to detail the purpose of each test. Step 6. Write a section on what you will not be testing. List any features that will not be tested during the current project.
Reasons not to test features include:. Step 7. List your strategy. This section outlines the overall test strategy for your test plan. It will specify the rules and processes that will apply to the tests outlined above. Step 8. Suspension Criteria: Here you specify the critical suspension criteria for a test.
When the suspension criteria are met, the active test cycle is suspended. Exit Criteria: Exit criteria specify a successful completion of a test phase. These are retrieved from Test Metric documents. The exception can be considered in case a clear and eligible reason is mentioned for a lower run rate. The pass rate can be variable depending on project scope.
But certainly, a higher pass rate is always a desirable goal. Step 6. Planning Resources As the name suggests, planning resources are the task of having a detailed summary of all the resources required to execute the project. Resources can include anything from people, hardware and software resources, or any other materials to be used. Resource planning is indeed important as it specifies all the resources that will be required to run the project successfully.
This will help the test manager to make a correct schedule and define accurate estimations needed to run the project. Step 7. Define test Environment The test environment is nothing but the combination of hardware and software on which the test team is going to execute the test cases. The test environment is a real-time instance that includes the user and the physical environment which includes servers and front-end interface.
Step 8. Create Test Logistics The two major points you will have to consider while creating test Logistics are:. Who will test? You should be aware which Testing is to be performed by which tester and their skill set.
When will the test occur? You should be strict on the timeliness to avoid any delays and all testing activities should have their set time. Step 9. So it is better to know the risks well in advance and to document clearly to avoid any issues during the later stages. Step Estimation and Scheduling In the test environment phase, the test manager has already used techniques to come to the conclusion of estimating the project.
Many IT firms break down the development into small tasks and add estimation of each task. Also, to have a proper estimation to execute test cases, the test manager needs various inputs like employee and project deadline, project estimation, and project risk.
Govern test deliverables Finally, the test deliverables consist of all the documents, components, and tools that have been developed in support of the various testing efforts carried out by the team. Many times, the manager decides to give the deliverables at specified intervals of the development.
In this post, we will learn how to write a Software Test Plan Template. Before that we see what is a Test plan. Test plan document is a document which contains the plan for all the testing activities to be done to deliver a quality product. It is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, what not to test, how to test when to test and who will do what test.
Also, it includes the environment and tools needed, resource allocation, test technique to be followed, risks and contingencies plan. A test plan is a dynamic document and we should always keep it up-to-date. Test plan document guides us how the testing activity should go on. Success of the testing project completely depends on Test Plan.
Test plan is one of the documents in test deliverables. Like other test deliverables , the test plan document is also shared with the stakeholders. The stakeholders get to know the scope, approach, objectives, and schedule of software testing to be done.
Some of the measures are to start preparing the test plan early in the STLC, keep the test plan short and simple to understand, and keep the test plan up-to-date.
0コメント