Project 1 - V&V SW Analysis - I
LIVE BATCH [PREETI MAM]
Test Plan: -
- It is detailed document that provides infomation about all the necessary resources and activities tat will be a part of Software as well as Hradware testing.
- Test plan are necessary documentation used on both white and black box testing.
- It outlines the test strategy, objectives, test schedule, required resources (human resources, software, and hardware), test estimation and test deliverables.
- The test plan is a base of every software's testing. It is the most crucial activity which ensures availability of all the lists of planned activities in an appropriate sequence.
Types of TEST PLAN
- Master Test Plan
- Phase Test Plan
- Testing Type Specific Test Plans
Master Test Plan
Master Test Plan is a type of test plan that has multiple levels of testing. It includes a complete test strategy.
Phase Test Plan
A phase test plan is a type of test plan that addresses any one phase of the testing strategy. For example, a list of tools, a list of test cases, etc.
Specific Test Plans
Specific test plan designed for major types of testing like security testing, load testing, performance testing, etc. In other words, a specific test plan designed for non-functional testing.
How to Write Test Plan
Making a test plan is the most crucial task of the test management process. According to IEEE 829, follow the following seven steps to prepare a test plan.
- First, analyze product structure and architecture.
- Now design the test strategy.
- Define all the test objectives.
- Define the testing area.
- Define all the useable resources.
- Schedule all activities in an appropriate manner.
- Determine all the Test Deliverables.
Test plan components or attributes
Test Objectives:
It consists of information about modules, features, test data etc., which indicate the aim of the application means the application behavior, goal, etc.
Scope of testing: -
It contains information that needs to be tested with respective of an application. The Scope can be further divided into two parts:
- In scope
- Out scope
Test methodology:
It contains information about performing a different kind of testing like Functional testing, Integration testing, and System testing, etc. on the application. In this, we will decide what type of testing; we will perform on the various features based on the application requirement. And here, we should also define that what kind of testing we will use in the testing methodologies so that everyone, like the management, the development team, and the testing team can understand easily because the testing terms are not standard.
Approach
This attribute is used to describe the flow of the application while performing testing and for the future reference.
We can understand the flow of the application with the help of below aspects:
- By writing the high-level scenarios
- By writing the flow graph
Assumption
It contains information about a problem or issue which maybe occurred during the testing process and when we are writing the test plans, the assured assumptions would be made like resources and technologies, etc.
Risk
These are the challenges which we need to face to test the application in the current release and if the assumptions will fail then the risks are involved.
For example, the effect for an application, release date becomes postponed.
Mitigation Plan or Contingency Plan
It is a back-up plan which is prepared to overcome the risks or issues.
Role & Responsibility
It defines the complete task which needs to be performed by the entire testing team. When a large project comes, then the Test Manager is a person who writes the test plan. If there are 3-4 small projects, then the test manager will assign each project to each Test Lead. And then, the test lead writes the test plan for the project, which he/she is assigned.
Schedule
It is used to explain the timing to work, which needs to be done or this attribute covers when exactly each testing activity should start and end? And the exact data is also mentioned for every testing activity for the particular date.
Defect tracking
It is generally done with the help of tools because we cannot track the status of each bug manually. And we also comment about how we communicate the bugs which are identified during the testing process and send it back to the development team and how the development team will reply.
Test Environments
These are the environments where we will test the application, and here we have two types of environments, which are of software and hardware configuration.
The software configuration means the details about different Operating Systems such as Windows, Linux, UNIX, and Mac and various Browsers like Google Chrome, Firefox, Opera, Internet Explorer, and so on.
And the hardware configuration means the information about different sizes of RAM, ROM, and the Processors.
Entry and Exit criteria
It is a necessary condition, which needs to be satisfied before starting and stopping the testing process.
Entry Criteria
The entry criteria contain the following conditions:
- White box testing should be finished.
- Understand and analyze the requirement and prepare the test documents or when the test documents are ready.
- Test data should be ready.
- Build or the application must be prepared
- Modules or features need to be assigned to the different test engineers.
- The necessary resource must be ready.
Exit Criteria
The exit criteria contain the following conditions:
- When all the test cases are executed.
- Most of the test cases must be passed.
- Depends on severity of the bugs which means that there must not be any blocker or major bug, whereas some minor bugs exist.
Before we start performing functional testing, all the above Entry Criteria should be followed. After we performed functional testing and before we will do integration testing, then the Exit criteria of the functional testing should be followed because the % of exit criteria are decided by the meeting with both development and test manager because their collaboration can achieve the percentage. But if the exit criteria of functional testing are not followed, then we cannot proceed further to integration testing.
Test Automation
In this, we will decide the following:
- Which feature has to be automated and not to be automated?
- Which test automation tool we are going to use on which automation framework?
Effort estimation
In this, we will plan the effort need to be applied by every team member.
Test Deliverable
These are the documents which are the output from the testing team, which we handed over to the customer along with the product. It includes the following:
- Test plan
- Test Cases
- Test Scripts
- RTM(Requirement Traceability Matrix)
- Defect Report
- Test Execution Report
- Graphs and metrics
- Release Notes
Test plan to test features of a new mobile phone (Blackbox test)
if(owner long press the power button)
{
open the company logo at centre;
}
else if(customer press the power button)
{
open the apps in grid;
}
else if(owner power on the phone)
{
shows call the phone icon on first position at bottom;
}
else if(owner power on the phone)
{
shows Dictionary icon on second position at bottom;
}
else if( owner click on call the phone icon)
{
contacts appears in chronological order;
}
else if(owner click on Dictionary icon)
{
search bar appears at centre;
}
else if(owner long press power on button)
{
displays Good-Bye and gets switched off;
}
else if(owners phone font)
{
always in calibri with size of 12;
}
else if(customer requirement touch responsive)
{
reflects on touch;
}
else ( customer requirement no hard buttons)
{
touch screen sensitive;
}
