A Test Plan is a document which describes a scope of testing, test strategy, objectives, effort, schedule and resources required. Its main purpose is to guide the whole testing process and used mostly by Project Managers or Tests Engineers. The example of Functional Test Plan you can find here.
The scope of work is defined at the beginning of the testing process. A project team should clearly understand what features and functions to be tested and which ones are out of scope. To determine the scope of testing a Manager must take into consideration the project specification, budget and customer’s requirements.
This section contains the documents which support test plan and can be referred during the testing process. Commonly, among them are:
- project plan
- system requirements
- specification design documentation.
1.4 Acronyms and Abbreviations
All the acronyms which are used in Test Plan are explained and described. For example,
- DDD - Database design document
- QMS - Quality Management System
- SLC - Software life cycle.
2. Test Plan and Strategy
2.1 Unit Testing
The main objective of unit testing is to verify whether every single unit operates as intended. For a separate unit, an engineer can take a function, procedure or method. Sometimes, it can even be the whole module of the application. Unit testing can be conducted manually, but more often automated testing is applied.
2.1.2 Entry Criteria
- planning phase has been finished
- testable units are available
- all functional requirements have been defined
- a unit testing environment has been set up.
2.1.3 Exit Criteria
- all planned test cases have been covered
- all the bugs found have been reviewed
- performance of key modules has been tested.
2.1.4 Logging Tests and Reporting
Developers fix the defects found in each unit. If these defects are related to other modules and units, they must be reported.
2.2 System Testing
System testing is generally conducted after Unit Testing. The objective of System Testing is to evaluate compliance of an integrated application with its requirements. During this stage engineers usually encounter issues which appear when the system has been integrated.
2.2.2 Testing Procedure
- test cases preparation
- test executions
- bug reporting.
2.2.3 Types of System Testing
220.127.116.11 Performance Testing
Performing testing is conducted to detect issues related to:
- memory consumption
- power utilization
- network connectivity
- operating in the background
- switching between applications
- memory leakage.
18.104.22.168 Interrupt Testing
As far as mobile devices have a huge range of functions, the work of the application may be interrupted by various reasons, e.g., an upcoming call, message, other apps notifications, mail, low memory warning, inserting a cable, etc. The application should be suspended and afterward launched from the place it was stopped without losing unsaved data.
22.214.171.124 Usability Testing
Usability testing is applied to check whether the application is easy to use and understand from the user’s point of view.
126.96.36.199 Installation and Launch testing
During installation testing, an engineer checks whether there are any issues during the installation, uninstallation, and updating of the application. Once the application has been installed, an engineer checks launching process. The application must be loaded quickly and correctly. Closing the application should not require much time as well.
188.8.131.52 Functional Testing
All the functions and features of the application are tested to verify whether they operate according to the specification.
184.108.40.206 Security testing
Security testing is conducted to find the application vulnerabilities and prevent private data losses.
220.127.116.11 Regression testing
Regression testing is a re-execution of tests that had been done before the code changes. Its purpose is to verify whether a new functionality has affected the existing one. It is also conducted after a new product release.
2.3 Pass/Fail Conditions
All the conditions when tests pass or fail are defined and described.
2.5 Test Report
Test Report helps to summarize testing activity in a formal way. It should contain:
- application name and overview
- testing hardware and software environment
- the number of tests cases executed/passed/failed.
For each issue that has been encountered, the following information is provided:
- bug description
- bug status (open, fixed, etc.)
- bug location
- steps to reproduce an issue.
3. Schedules for Testing
A test schedule is elaborated by Project Managers and helps to monitor the testing process.
4. Risks and Assumptions
The following risks exist while testing a mobile application:
- availability of devices
- new features and modification which have not been planned in advance
- changes in requirements
- delays in schedule.
- each release is accompanied by a note with information about implemented features and their impact on the system
- all “bugs-blockers” receive high priority
- all the bugs found are fixed before the next software release
- all documents are up-to-date and delivered to the testing team in time
- all necessary equipment and tools are provided and ready for testing
- tests schedule is reviewed in case there are any obstacles for testing activity.
5. Entry and Exit Criteria
5.1 Entry Criteria
- development phase has been finished
- requirements have been defined and approved
- test design and tests plan have been created
- test environment has been set up
- all necessary resources are available.
5.2 Exit Criteria
- tests cases are executed
- the rate of tests cases passed is satisfactory, e.g., 95%
- failed test cases are not related to crucial functionality
- tests results have been accepted
- critical defects have been fixed.
6. Test Metrics
Test metrics are quantitative measures which help to estimate the testing effort. The most common metrics are:
- requirement coverage
- test cases coverage
- number of tests executed
- number of defects found (taking into consideration their priorities and severities)
- tests design effort
- total test effort.
7. Logging Tests and Reporting
Each found issue should be properly reported using special tools and applications.
8. Roles and Responsibilities
Roles and responsibilities on the project must be clearly defined and divided among the project stuff. Commonly, the roles are as follows:
8.1 Project Manager
Project Manager is responsible for managing the whole testing process. He/she approves all test documentation, considers budget and time terms, and provides necessary resources.
8.2 Test Lead
Test Lead is responsible for collecting requirements, planning process, test activity monitoring and project reporting.
8.3 Test Engineer
Test Engineer is responsible for tests case preparation and execution as well as issue reporting.
The list of testing deliverables usually contains:
- tests plan
- test cases documents
- test strategy
- test results
- test summary report.