Project 1 - V&V SW Analysis - I
What is Test Plan?
A test plan is a detailed document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform testing for a software product. Test Plan helps us determine the effort needed to validate the quality of the application under test. The test plan serves as a blueprint to conduct software testing activities as a defined process, which is minutely monitored and controlled by the test manager.
Importance of test plan
A test plan is the foundation of every testing effort. It helps set out how the software will be checked, what specifically will be tested, and who will be performing the test. By creating a clear test plan all team members can follow, everyone can work together effectively.
Whether you’re building a phone or developing open-source software, a test plan is essential to delivering the final result.
The test plan usually includes the following information:
1. The overall objective of the testing effort.
2. A detailed outline of how testing will be conducted
3. The features, applications, or components to be tested.
4. Detailed scheduling and resource allocation plans for testers and developers throughout all stages of testing.
Black box testing:
Black box testing is a technique of software testing which examines the functionality of the software without peering into its internal structure or coding. The primary source of black-box testing is a specification of requirements that is stated by the customer.
In this method, the tester selects a function and gives input value to examine its functionality, and checks whether the function is giving the expected output or not. If the function produces the correct output, then it is passed in testing, otherwise failed. The test team reports the result to the development team and then tests the next function. After completing the testing of all functions if there are severe problems, then it is given back to the development team for correction.
White box testing
White box testing is an approach that allows testers to inspect and verify the inner workings of a software system—its code, infrastructure, and integrations with external systems. White box testing is an essential part of automated build processes in a modern Continuous Integration/Continuous Delivery (CI/CD) development pipeline.
White box testing is often referenced in the context of Static Application Security Testing (SAST), an approach that checks source code or binaries automatically and provides feedback on bugs and possible vulnerabilities.
Test Plan Attributes:-
attributes in Test Plan as follow,
Objective: It describes the aim of the test plan, whatever the good process and procedure they are going to follow in order to give quality software to customers. The overall objective of the test is to find as many defects as possible and to make software bug free. The test objective must be broken into components and sub-components.
Test Strategy: It is a crucial document that is to be performed and usually designed by the Test Manager. It helps to determine Test Effort and Test cost. Test strategy helps to determine the features that are going to be tested and the features that will not be tested. The scope can be divided into two parts:
In-Scope: The modules that are to be tested rigorously.
Out-Scope: The modules that are not to be tested rigorously.
Testing Methodology: The methods that are going to be used for testing depend on application to application. The testing methodology is decided based on the feature and application requirements. Since the testing terms are not standard, one should define what kind of testing will be used in the testing methodology. So that everyone can understand it.
i.Approach: The approach of testing different software is different. It deals with the flow of applications for future references.
ii.Assumptions: In this phase, certain assumptions will be made.
Example:
The testing team will get proper support from the development team.
Risk: All the risks that can happen if the assumption is breaking. For Example, in the case of wrong budget estimation, the cost may overrun. Some reason that may lead to risk is:
i.Test Manager has poor management skills.
Backup/Mitigation Plan- If any risk is involved then the company must have a backup plan, the purpose is to avoid errors. Some points to resolve/avoid risk:
i.Test priority is to be set for each test activity.
Roles and Responsibilities: All the responsibilities and role of every member in a particular testing team has to be recorded.
Example:
Test Manager: Manages the project, takes an appropriate resource, and gives project direction.
Tester: Identify the testing technique, verify the test approach, and save project cost.
Scheduling: Under this, it will record the start and the end date of each and every testing-related activity. For Example, writing test case date and ending test case date.
Defect Tracking: It is an important process in software engineering as lots of issue arises when you develop a critical system for business. If there is any defect found while testing and that defect must be given to the developer team.
Test Environment- It is the environment which the testing team will use i.e. the list of hardware and software, while testing the application, the things which are said to be tested will be written under this section. The installation of software is also checked under this.
Example:
i.Software configuration on different operating systems, such as Windows, Linux, Mac, etc.
Entry and Exit Criteria: The set of conditions that should be met in order to start any new type of testing or to end any kind of testing.
Entry Condition:
- Necessary resources must be ready.
- The application must be prepared.
- Test data should be ready.
Exit Condition:
i.There should not be any major bug.
ii.Most test cases should be passed.
iii.When all test cases are executed.
Test Automation: It consists of the features that are to be automated and which features are not to be automated.
- If the feature has lots of bugs then it is categorized as Manual Testing.
- If the feature is frequently tested then it can be automated.
Deliverables- It is the outcome from the testing team and that is to be given to the customers at the end of the project.
Before the testing phase:
- Test plan document.
- Test case document.
- Test design specification.
During the testing phase:
- Test scripts.
- Test data.
- Error logs.
After the testing phase:
- Test Reports.
- Defect Report.
- Installation Report.
if(owner switch on the phone)
{
(Company logo at the center of the screen)
}
else if(customer switch on the phone)
{
(All my icons of the APPS shall be present in the grid)
}
else if(owner powered on the phone)
{
(the "call the phone" icon is the first icon and the "Dictionary" icon is the second icon at the bottom bar of my screen.)
}
else if(owner clicked on phone icon)
{
(All the contacts shall be visible based on chronological order.)
}
else if(owner access the dictionary icon)
{
(Search bar shall appear at the middle of the screen to let me search the meanings of the words I desire)
}
else if(owner switches off the phone)
{
( "Good-Bye” Message should appear with font Calibri (Body) and font size shall be 12.)
}
else if(customer)
{
(I need my UI must be touch responsive)
}
else
{
(Mobile phone should not have hard buttons.)
}