Notepad Testplan
Notepad Testplan
Index
1. INTRODUCTION
2. BUSINESS BACKGROUND
3. TEST OBJECTIVES
4. SCOPE
5. TEST TYPES IDENTIFIED
6. PROBLEMS PERCEIVED
7. ARCHITECTURE
8. ENVIRONMENT
9. FUNCTIONALITY
10.SECURITY
11.USABILITY
12.TEST TEAM ORGANIZATION
13.SCHEDULE
14.CONFIGURATION MANAGEMENT
Test plan
1. Introduction
This test plan is designed to:
Describe the approach used by tester during testing.
Organize and implement the test process.
Describe the testing strategy and steps.
2. Business Background
The following product is from Microsoft Corporation.
It is a product from Microsoft windows 10 which is licensed under
Microsoft Software License Terms to the respective user.
Following project is available by paid genuine windows 10.
3. Test Objectives
The Objective of this assessment was to check and validate the overall
functionality of the software as per the described requirements. This includes
the functions like smooth error free typing and other create, edit, and open,
save, functions.
4. Scope
As per objectives, the initial scope is to check all
Major/minor functionalities of the ‘Notepad’ software.
Inclusions:
a. Firstly for testing will be done after development so the black box testing
will be done.
b. The ‘Notepad’ itself will be used for testing.
c. The latest version of notepad is used.
Exclusions:
a. The testing approach like white box testing will not be used, because the
‘Notepad’ software is already developed.
b. Since some testing can only be done during the development process but
this software is already developed by Microsoft so some testing like Unit
testing, Integration testing, System testing cannot be done.
6. Problems Perceived
a. Test cases were challenging to design while unclear functional
specifications.
b. It was difficult to identify all possible inputs in limited testing time.
c. It was difficult to identify all possible inputs in limited amount of time.
As result making test case can be slow and difficult.
d. It was difficult to identify tricky inputs because of the test cases are not
developed based on specification.
e. There might be some errors in some internal structure or any logic which
cannot found now by our black box testing.
7. Architecture
The notepad consist of many functionalities and modules, following is the
architecture of the ‘Notepad’ in block diagram format.
8. Environment
The following project was tested in Windows operating system as it is
made by Microsoft Windows. Except that no other special tools or
framework were used for the testing.
9. Functionality
Sr. no. Scenarios
Test strategy
Scope:
• Reviewing documents, approving documents and carrying out tests
are done by testers, Pratiksha Jadhav
Test approach
• Process of testing:
The first individual module was taken for testing and analyzed. The
module was reviewed and specifications were noted. According to the
main functionality of the module test cases were created and executed.
The output was acknowledged and its status was updated in test cases.
• Roles and responsibilities of each team member
1. Pratiksha Jadhav: Analyzing the module and the specifications
of the product.
2. Pratiksha Jadhav: Creating the test cases as per the
requirements and the specifications of the modules.
3. Sakshi Shinde: Executing the test cases provided by team
members and getting the results.
4. Sakshi Shinde: Reviewing the test results and setting a status in
test cases either pass or fail.
• Type of testing:
The functionality testing was done on this module.
• Testing approach used:
The analytical approach was used for the testing. No extra special
automation tools were used in testing, whole testing is done manually.
Test Environment
Windows operating system was used, any version of windows can be
used. For setup, the ‘Notepad’ is used as it is already installed in
windows. There was no need of backup so nothing for backup was used.
Testing tools:
For testing no special tools were used, only single ‘Notepad’ was
used.
Risk analysis.
No risk or defects were found.
Review
All these activities are reviewed and signed off by the team members.
Everything in this module was perfect and fine. No risks, defects or
bugs were found.
10. Security
Sr. no. Scenarios
1. Verify if user can edit text files in notepad after enabling the
‘Read only’ option.
2. Verify how many users can access files if the file is
accessible for the root user only.
3. Verify if the contents of file are readable after encrypting it.
Test approach
• Process of testing:
The first individual module was taken for testing and analyzed. The
module was reviewed and specifications were noted. According to the
main functionality of the module test cases were created and executed.
The output was acknowledged and its status was updated in test cases.
• Roles and responsibilities of each team member
1. Pratiksha Jadhav: Analyzing the module and the specifications
of the product.
2. Pratiksha Jadhav: Creating the test cases as per the
requirements and the specifications of the modules.
3. Sakshi Shinde: Executing the test cases provided by team
members and getting the results.
4. Sakshi Shinde: Reviewing the test results and setting a status in
test cases either pass or fail.
• Type of testing:
The security testing was done on this module.
• Testing approach used:
The analytical approach was used for the testing. No extra special
automation tools were used in testing, whole testing is done manually.
11. Usability
Sr. no. Scenarios
Test approach
• Process of testing:
The first individual module was taken for testing and analyzed. The
module was reviewed and specifications were noted. According to the
main functionality of the module test cases were created and executed.
The output was acknowledged and its status was updated in test cases.
• Roles and responsibilities of each team member
1. Pratiksha Jadhav: Analyzing the module and the specifications
of the product.
2. Pratiksha Jadhav: Creating the test cases as per the
requirements and the specifications of the modules.
3. Sakshi Shinde: Executing the test cases provided by team
members and getting the results.
4. Pratiksha Jadhav: Reviewing the test results and setting a status
in test cases either pass or fail.
• Type of testing:
The Usability testing was done on this module.
• Testing approach used:
The analytical approach was used for the testing. No extra special
automation tools were used in testing, whole testing is done manually.
12. Test team organization
Our test team is of four members,
1. Pratiksha Jadhav
2. Sakshi Shinde
13. Schedule
The testing should start from day 1 December 2022 to 10 December 2022
by following specified schedule.
2. Planning the test and test Pratiksha Jadhav 2 Dec 2022 4 Dec 2022
strategy. Sakshi Shinde