Test Plans / Process Documentation

Making a Test Plan is the most important task of Test Management Process. Follow the seven steps below to create a test plan:

1. Analyze the product
2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables testing / optimization

Test Plans can provide very important information. That information must be documented. Network Architects at Block2AI have a minimum of 10 years experience documenting the results of test plans and making recommendations whether on modifications required or the best deployment methods. 

You must learn a product thoroughly before testing it.

You should research clients and the end users to know their needs and expectations from the application

• Who will use the product?
• What is it used for?
• How will it work?
• What are the protocols / hardware the product uses?

Review of product documentation helps you to understand all the features as well as how to use it. If you are unclear on any items, you might interview customer, developer, designer to get more information.

Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is a high-level document, which is usually developed by Test Manager. This document defines:

• The project’s testing objectives and the means to achieve      them
• Determines testing effort and costs

Before the start of any test activity, scope of the testing should be known. You must think hard about it:

• The components of the system to be tested (hardware, software, protocols, monitoring, etc.) are defined as "in scope"
• The components of the system that will not be tested also need to be clearly defined as being "out of scope."

Defining the scope of your testing project is very important for all stakeholders. A precise scope helps you:

• Give everyone a confidence & accurate information of the testing you are doing
• All project members will have a clear understanding about what is tested and what is not

A Testing Type is a standard test procedure that gives an expected test outcome.

Each testing type is formulated to identify a specific type of product bugs. All Testing Types are aimed at achieving one common goal “Early detection of all the defects before releasing the product to the customer”

Risk is future’s uncertain event with a probability of occurrence and a potential for loss. When the risk actually happens, it becomes the ‘issue’.

In the QA Test Plan, you will document those risks.

You may not know exact names of the tester who will test, but the type of tester can be defined.

To select the right member for specified task, you have to consider if his skill is qualified for the task or not, also estimate the project budget. Selecting wrong member for the task may cause the project to fail or delay.

Person having the following skills is most ideal for performing software testing:

• Ability to understand customer's point of view
• Strong desire for quality
• Attention to detail
• Good cooperation

Test Objective is the overall goal and achievement of the test execution. The objective of the testing is finding as many software defects as possible; ensure that the deployment or service under test is bug free before release.

To define the test objectives, you should do 2 following steps

1. List all the features (functionality, performance, …) which      may need to test.
2. Define the target or the goal of the      test based on above features

Test Criteria is a standard or rule on which a test procedure or test judgment can be based. There’re 2 types of test criteria as following:

Pass/Fail Criteria

Specify the critical suspension criteria for a test. If the suspension criteria are met during testing, the active test cycle will be suspended until the criteria are resolved.

Example: If your team members report that there are 40% of test cases failed, you should suspend testing until the development team fixes all the failed cases.

Completion Criteria

It specifies the criteria that denote a successful completion of a test phase. The exit criteria are the targeted results of the test and are necessary before proceeding to the next phase of development. Example: 95% of all critical test cases must pass.

Some methods of defining exit criteria are by specifying a targeted run rate and pass rate.

• Run rate is ratio between number test cases executed/total test cases of test      specification. For example, the test specification has total 120 TCs, but the tester only executed 100 TCs, So the run rate is 100/120 = 0.83 (83%)
• Pass rate is ratio between numbers test cases passed / test cases executed. For example, in above 100 TCs executed, there’re 80 TCs that passed, so the pass rate is 80/100 = 0.8 (80%)

Test Deliverables is a list of all the documents, tools and other components that has to be developed and maintained in support of the testing effort.

There are different test deliverables at every phase of the software development lifecycle.

Test deliverables are provided before testing phase.

• Test plans document.
• Test cases documents
• Test Design specifications.

Test deliverables are provided during the testing

• Test Scripts
• Simulators.
• Test Data
• Test Traceability Matrix
• Error logs and execution logs.

Test deliverables are provided after the testing cycles is over.