1.TEST PLAN

1.1 What is the Test Plan?

Test plan is a document describing the goal, scope, approach and focus on software testing efforts. The process of preparing the Test Plan is a useful way to think about the efforts needed to confirm the acceptability of a software product.

The general structure of a test plan usually includes the following information:

• Project name
• List of modules to be tested
• Start date, end date
• List of test cases
• Personnel involved
• Resources used
• Implementation plan

1.2. Why write a test plan?

• To guide thinking
• As a means of communication of the test group with the project team and as a tool for assigning work in the test team
• Support management and adjustment when changes

1.3. Types of test plans

1.3.1. Master test plan :

A single high-level test plan for a project / product that combines all other testing plans.

1.3.2. Testing Level Specific Test Plans :

Plans for each test level:

• Unit Test Plan:

  Unit Testing ( unit testing ) is a level of software testing that aims to verify that each unit of software is developed as designed. Unit testing is the smallest test level of any software. Functions, procedures, classes, or methods can all be considered units. It usually has one or several inputs but the output is unique.

  Unit testing is done by the developer and is white box testing. This is done as soon as possible during the coding phase and throughout the software development process.

  Purpose:

  Increase security when code changes

  The code is easy to use, easy to understand and reusable

  Repair costs are lower than the following periods

  Easier to correct errors

• Integration Test Plan:

  Integration Testing ( integration testing ) is performing testing integrating a group of individual modules together. A software system consists of many modules coded by different people. Integrated testing focused on data transfer between modules.

  Integration tests are performed to detect interface failures or during interactions between integrated systems or components.

  Component integration test: check the interaction between components provided that the components passed in the previous component test.

  System integration test: check the interaction between different subsystems and the systems have passed the previous test.

  This is done by a developer, a specialized test team, or an integrated developer / tester group, including non-functional testing, and is performed after Unit Testing and before System Testing.

  Purpose: The purpose is to find errors in the process of integrating components and modules together

• System Test Plan:

  System testing is testing a system that has been fully integrated to make sure it works properly.

  System testing is a black box test and is focused on the function of the system. Test the functions and interfaces, the behavior of the system completely to meet the requirements.

  Purpose: The purpose of this stage is to evaluate whether the system performance is in accordance with the specification document and performed by the tester.

• Acceptance Test Plan:

  Official acceptance test relates to business requirements and processes to determine whether the system meets the acceptance criteria and allows users, customers or other authorized organizations to determine whether to accept receive the system or not.

  Acceptance test is the fourth level conducted after the system test is completed and before the product is put into official use. With the purpose of ensuring the software meets customers’ requirements. Products received acceptance from customers / end users.

  The acceptance test is divided into 2 different levels:

  Alpha testing : conducted at a software development site by people in the organization but not involved in software development.

  Beta testing : performed by customer / end user at end user’s location.

  Purpose: To assess whether the system complies with customer requirements and whether or not to accept product delivery.

1.3.3. Testing Type Specific Test Plans:

• Performance Test Plan
• Security Testing Plan

2. Objectives to be achieved

Identify the following requirements:

• Increase team work efficiency
• Determine the type of test
• Determine the test strategy
• Specify the responsibility
• Determine the deadline
• Time to stop testing
• Constantly updated

3. Test Plan template

Test plan template The format and content of the Test plan vary depending on the processes, standards, and test management tools being implemented. However, the following format, based on the IEEE standard for software testing documentation, provides a summary of the Test plan.

3.1. Test Plan Identifier:

Provide a unique form for the document. (Follow the Configuration Management System if you have one.)

3.2. About :

• Provides overview of test plan.
• Specify goals / goals.
• Specify any restrictions.

3.3. References :

List relevant documents that link to them, if any, including the following:

• Project Plan
• Configuration Management Plan

3.4. Test items

List test items (software / products) and their versions.

3.5. Features to be tested:

• List the features of the software / product to be tested
• Provide references for Requirements and / or Design specifications of the features to be tested

3.6. Features not tested :

• List the features of the software / product that will not be tested.
• Specify why these features will not be tested.

3.7. Approach :

Refers to the holistic approach to testing. Specify test level (if it’s the main test plan), types of tests, and test methods (manual / automatic test, white / black / gray test)

3.8. Pass / Fail Criteria :

Specify criteria that will be used to determine whether each test item (software / product) has passed.

3.9. Criteria for delay and request to continue:

• Specify the criteria that will be used to suspend the test operation.
• Specify the test activities to be repeated when the test is continued.

3.10. Plan results:

List planned results and links to them, if any, including:

• Test Plan
• Test Cases
• Test Scripts
• Defect / Enhancement Logs
• Test Reports

3.11. Test environment:

• Specify the properties of the test environment: hardware, software, network, etc.
• List any testing tools or related tools.

3.12. Estimate:

Provide a summary of test estimates (cost or effort) and / or provide links to detailed estimates.

3.13. Schedule :

Provide schedule summaries, specify milestones, and / or provide links to detailed schedules.

3.14. resources and training if needed:

• Assign personnel needs according to the roles and skills required.
• Identify the training that is needed to provide those skills, if not already available.

3.15. Responsibilities :

List responsibilities of each group / role / individual.

3.16. Risks :

• List the identified risks.
• Specify a mitigation plan and contingency plan for each risk.

3.17. Assumptions and related issues:

-Statement of assumptions made during the preparation of this plan.

• List related issues

3.18. Approve :

• Specify the names and roles of everyone who must approve the plan.
• Provide signature space and date. (If the document is printed)

Note:

• Concise planning. Avoid redundancy and redundancy. If you think you do not need the part mentioned in the sample above, go ahead and delete that part of your test plan.
• Be specific. For example, when you specify an operating system as an attribute of a test environment, also refer to OS Version / Version, not just the name of the Operating System.
• Use lists and tables if possible. Avoid long paragraphs.
• Plan to review the review a number of times before facility it or submit it for approval. The quality of your test plan indicates the amount of quality of the test that you or your team will take.
• Update the plan as needed. An outdated and unused document is corrupted and worse, there’s no document in the first place.

Conclude

This article only hopes to help you understand the basics of Test Plan. Hope that you can understand and apply flexibly into your work appropriately, especially those who are new to Tester (QA). under to be able to learn, learn the best way

Reference: http://softwaretestingfundamentals.com/test-plan/