High Level Testing Stretegy In iOS App Development

Tech APP

Post Tags

High Level Testing Stretegy In iOS App Development

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 Classes

Test PhasesDefinitionIn ScopeOur ScopeComments 
App TestingApplication testing deals with tests For the entire application which is driven by the requirements.yes
Performance TestingPerformance testing is the process of determining the speed, responsiveness, and stability of a computer, network, software program, or device under a workload.yesTested on local mode so much deviation cannot be noticed as there is not Remote mode currently for the app.
Automation TestingAutomated 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- FunctionalTesting the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability, and portability.NoNot 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.NoNot 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.

Test Approach/Strategy

  1. Testing will be done in n sprints. Timelines are given below:
  2. App, Performance, and Automation testing will be carried out for this project by the Testing team, whereas UAT testing by the GEO team.
  3. Unified testing will be carried out in the below environment and are aligned with the release timelines.
    1. Sprint1  – App, Automation (XCUI) Testing Timelines
    2. Sprint2 – App, Automation (XCUI), and Performance Testing   Timelines
    3. Sprint 3 – Deploy
  4. Automation testing and Performance testing would be aligned with Sprint1 and Sprint2.
  5. JIRA Tool will be used to manage test scripts and defects under the Project Name: Redesigning
  6. All the open defects in Sprint1 will be carry forwarded to Sprint2.
  7. End to end functional and UI testing will be done on Device only for all the sprints.
  8. Test Cases for each in-scope requirement are prepared and executed during the Validation phase and are housed in JIRA.

Testing Strategy in iOS App

Test Entry & Exit Criteria

  • Testing the Entry & Exit Criteria Checklist

Entry Criteria
  • Unit Testing completed prior to Sprint final build testing execution
  • No Sev-1  defects are open as part of Unit testing.
  • All code pushes to servers and the iPad Air is ready for testing.
  • Requirements and Test Plan modules in JIRA have been created
  • Sanity Testing must be successful without any major issues.
Exit Criteria
  • All planned test scripts have been successfully executed and successfully validated or have a defect corresponding logged in JIRA
  • Testing documentation and Defect screenshot(s)have been maintained and retained according to the document retention policy
  • All unresolved defects have been documented and communicated to the project team via the Exit Report 
  • No Sev-1 defects are open as part of Sprint testing.

Testing Deliverables

  • Test Plan Document
  • Test Cases
  • Test Result Report
  • Defect Report

Test Schedule

Schedule timeline for every functionality test for  Sprints 

Test Environment

  • 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

  1. 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.
  2. Test data should be available.
  3. Test data should be sent in JSON format.

Defect Management

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 

Defect Workflow:

SeverityDefinition
Blocker
  • A defect that causes total failure of the software system/subsystem or unrecoverable data loss or severe impact to data integrity
  • Prevents any further test execution
Critical
  • A defect that results in one of the main functionality  
  • It’s a hard block for some other critical functionality.
  • But not a showstopper for the overall testing process.
Major
  • A defect that results in severely impaired functionality  
  • A workaround may exist but its use is unsatisfactory
Normal
  • A defect that causes failure of non-critical function of the system, or produces incorrect, incomplete, or inconsistent results
  • There is a work-around that has been accepted by the business prior to assigning.
Low
  • Defect of minor significance. Generally cosmetic are Non-critical but functional.
  • A work-around exists or, if not, the impairment is slight

Risk Identification & Mitigation

Risks:

  • 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.

Mitigations:

  • 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.

Dependencies

DEPENDENCIESRESPONSIBLE
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.

ajayb

Comments are closed.