The purpose of this test plan is to provide a high-level overview of the testing functions and features that will take place during the testing of the iOS app development services. Testing can be automated/ XCUI/XCT test cases where developer or testers can write the test cases and do the end to end testing to achieve the quality of the product. let’s learn more about Testing strategy in iOS app development.
Benefits Of Testing Strategy In iOS App
- Performance improvement for Users.
- Bugs and Error finding and resolution.
- Testing can find the missing requirement from actual expectations.
- Actual Requirements need to fulfill all the test cases.
- Crashing and lacking any requirement can be traced.
- Memory leakage and heavy task operation can be traced.
Testing Type :
There are many types of testing that can be done that identify the issue and then developers can resolve all the issues after testing.
- Manual Testing
- Automation Testing
- Performance Testing
- Usability Testing
- Load Testing
- Security Testing
Testing Objective & Scopes
|Test Phases||Definition||In Scope||Our Scope||Comments|
|App Testing||Application testing deals with tests For the entire application which is driven by the requirements.||yes|
|Performance Testing||Performance testing is the process of determining the speed, responsiveness, and stability of a computer, network, software program, or device under a workload.||yes||Tested on local mode so much deviation cannot be noticed as there is not Remote mode currently for the app.|
|Automation Testing||Automated testing or test automation is a method in software testing that makes use of special software tools to control the execution of tests and then compares actual test results with predicted or expected results.||yes|
|Non- Functional||Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability, and portability.||No||Not in scope for the Testing team.|
|Production Assurance (UAT)||Allows the user to perform a final check and confirm functionality volume, accuracy, interfaces, etc. based on business requirements, using production data.||No||Not in scope for the Testing team.|
Out Of Scope For Testing
- Non-Functional testing is out of scope for the Testing team.
- User acceptance testing(UAT) is out of scope for the Testing team.
- Testing will be done in n sprints. Timelines are given below:
- App, Performance, and Automation testing will be carried out for this project by the Testing team, whereas UAT testing by the GEO team.
- Unified testing will be carried out in the below environment and are aligned with the release timelines.
- Sprint1 – App, Automation (XCUI) Testing Timelines
- Sprint2 – App, Automation (XCUI), and Performance Testing Timelines
- Sprint 3 – Deploy
- Automation testing and Performance testing would be aligned with Sprint1 and Sprint2.
- JIRA Tool will be used to manage test scripts and defects under the Project Name: Redesigning
- All the open defects in Sprint1 will be carry forwarded to Sprint2.
- End to end functional and UI testing will be done on Device only for all the sprints.
- Test Cases for each in-scope requirement are prepared and executed during the Validation phase and are housed in JIRA.
Test Entry & Exit Criteria
Testing the Entry & Exit Criteria Checklist
- Test Plan Document
- Test Cases
- Test Result Report
- Defect Report
Schedule timeline for every functionality test for Sprints
Test Environment Requirement
There should be a continuous environment availability for all the sprints. The development team needs to Install in the devices with the below iOS versions and make those available before Sprint testing :
Test Data Set
- Test data requirements for App testing, Automation Testing, and Performance testing will be coordinated for special data needs, based on test data shared by Team.
- Test data should be available.
- Test data should be sent in JSON format.
All defects from all test phases will be housed in JIRA and JIRA will be configured to allow for filtering and metrics extraction by phase/severity/category/owner/dates/etc.
All issues will be managed to a closed status or mitigated with the assistance of the project team. Defect severity will be considered when assessing production readiness and drive exit and entrance criteria. All the Sev-1 and Sev-2 issues need to be fixed. Mobile App Development Services
Risk Identification & Mitigation
- Handoffs: As each sprint is planned for only two weeks of testing no delay in the Handoffs should happen.
- Resources: Onboarding, all of the planned resources will be delayed due to different levels of the approval process. Most resources can be onboarded after a week the testing start date.
- Devices: Procurement of the planned devices as per the testing strategy will take 2 weeks or more to be fulfilled.
- Defects: Defects might be big in number for the initial sprints and may reduce thereafter.
- Environment Downtimes: There could be a possible downtime during offshore and onshore hours. Weekend work may be planned on a need basis.
- Test Data: Availability of test data is dependent on the on-shore team. Delay in test data may impact the testing timelines.
- Handoffs: PM to ensure that the Handoffs are received when the testing activities are minimal and Handoffs are done as planned.
- Resources: To mitigate the delay, plan to utilize a part of the BAU resources.
- Devices: To absorb the delay in procurement, we will be loaning some of the devices from the 2Operations team.
- Defects: Proper SLA’s should be followed as below.
- Environment Downtimes: Dev ops team needs to maintain an additional test server and they need to provide support in the weekend to mitigate this risk.
- Test Data: Sample test data can be used until the customer test data is received from the on-shore team.
|Sprint code needs to be delivered for the testing team to complete quick sanity and offshore can start the testing.||Dev Team|
|There should be no negotiations on the planned features for each sprint.||<CLIENT>|
|The test environment should be available throughout the testing phase, if not delivery of <CLIENT> dependent features needs to be prioritized.||Dev Ops Team|
|Dev team to analyze the defects raised by the testing team, after a day to avoid the rework of data creation.||Dev Team|
|<CLIENT> on-shore team needs to provide test data in JSON format prior to each Sprint testing timeline.||<CLIENT>|
|Devices with IOS 12 &iOs 13 versions should be available before each Sprint testing.|
Read more about Mobile App Development Services.