Proper Testing Scenarios

Question

Created Sep ’20

Replies 1

Boosts 0

Participants 2

I am new to iOS development and have inherited a few apps. As part of going through the current set up and trying to improve it for future development, I have questions about what methods of testing are available/best practices.

We have some apps that have QC/testing resources (endpoints, databases, etc) associated with them. According to the documentation I have, the previous developers tested this locally with a device/USB/XCode. However, they also have Dev and QC apps in AppStoreConnect (I assume for deployment/testing) that have never made it through review.

We now not only have a team of testers, but also have them working remotely. They all have designated devices for testing and I would prefer to have a method set up of completing a build, having them be able to remotely access the app and test, then be able to submit the app for review.

My main assumption is that we will need to complete two separate builds, one for QC and one for Production.

There are steps in between there, but my main questions revolve around:

1) How do I efficiently test our apps using our QC endpoints instead of our production endpoints?
2) How do we get our non-dev team members access to these apps remotely? (less than 100 team members)
2a) We have Microsoft App Center that should be able to fill this gap I think?
3) Is there a step I'm not thinking of? Can this all be done using TestFlight or some other one-stop?

Thanks in advance for any thoughts!

Boost

Answer 1

KMT OP

Sep ’20

We now not only have a team of testers, but also have them working remotely.

If you're asking here, TestFlight is perfect, and is perhaps the only thing in your future at this point.

My advice at this point is to create a small/Tiger team that commits to an all Apple IDE, training them as trainers for the larger group.

we will need to complete two separate builds, one for QC and one for Production.

Seperate only in the sense that the basic difference in those two would be to strip test-centric code, comments, then, how they are signed.

The closer one is to the other, the better. I'd take a debug/QC build, wash it clean, then use it to generate a store signed build. Resist a dual path otherwise.

Don't bother generating production/release builds until you've locked down QC builds post-test.

Don't get creative...Apple provides a tightly controlled IDE that is only your friend when you adhere to it.

Look into using GIT for source control.

Good luck.

1