IOS Application Testing Systems

Where it all begins

Consider the steps that an iOS application developer and a tester need to take in order to establish a channel for developing, testing, and receiving reports without using specialized testing systems.

Application delivery to testers

The tester needs the application you are developing to be installed on its device. As a rule, you do all the preliminary work yourself: at best, you set up an automatic assembly with an AdHoc certificate, the tester downloads the assembly per hour X and installs it on your device by synchronizing via iTunes or using the Configuration Utility . In the worst case, you yourself send the assembly by writing or downloading to a specific resource.

Testing

The tester should carefully check the application, postpone the device and get a couple of bugs in the bug tracker and, if the application crashed during the testing process, attach a couple of crash files. The tester may not be one, and then the number of tasks created in the tracker will increase if the testers do not interact with themselves. And it happens.
')

Revision

After reading everything that was created after this in the bug tracker, you proceed to the correction. And the process is repeated until you correct everything.

Problems of this approach

At the first stage of the problem, this is all that is between your final commit to the repository before installing the application on the tester device. Manual downloads by testers of assemblies, synchronization with aytyuns, installation via the Configuration Utility, are all a routine that needs to be removed.

In the testing step, the problem is as follows. The tester spends time creating a task in the tracker, attaching a crash log to it. The crash logs can be due to one error, which can lead to duplication of tasks in the tracker.

I am sure that some of you are developing applications right now.

What will help?

During the development of the modern mobile development industry, no means were invented to minimize the costs described above, if not completely remove them. What if a couple of clicks "publish testers" and "install" the application will be installed on the devices of all testers?
There are such solutions.

The main such solutions at the moment include TestFlight and HockeyApp .

How to get started

Getting started with such systems is about the same and consists of the following steps:

• You create an account on the site of the system and get your unique key that must be used in the code;
• Download system SDK, connect it to your project;
• Insert a couple of lines of code that initializes the system within your application;
• Build the application and upload it to the system website. It is also possible to upload the assembly with a post-request to the site; this can be part of your automatic build system;
• Send all your testers invitations to the development team on the system site;
• When registering their devices, testers will automatically enter the UUIDs of their devices, which you can receive in a separate file that can be downloaded in the Devices section of the Provisioning Portal ;

It takes five minutes. Now, from the final commit to installing the application on the tester device, there are two steps.

Testers in the hour X comes letter:



Clicking on Install , the tester starts the installation process of the application from the server, after which it can begin its work.

An example of what you need to add to your source code for the minimum and necessary work of TestFlight:

[TestFlight takeOff:@"YOUR_KEY"]; 

It's all. You need to insert it into the UIApplicationDelegate method:

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 

This is all that your application as an SDK client needs to do in order to:

• It was the account of the sessions of the tester with the application;
• Session contains tester name, device and system version, start and end time;
• On the server system came crash-files in the case of "departure". They can be conveniently viewed directly on the site.

Difference systems

By mentioning the network, perhaps the most popular system - TestFlight. But HockeyApp has several advantages over TestFlight:

Opportunity	Testflight	HockeyApp
Ease of use	+	+
Free	+ Paid functionality will only be in the future.	- There is a free trial period
Upload API	+	+
Connecting bug tracker to create tasks	-	+ JIRA and Redmine et al.
Site speed	± Often it slows down even when there is night	+
Open source	- SDK is available as .a - and .h - files	+

TestFlight is the most popular solution in this niche. Maybe because of the load, maybe for other reasons the service is not available, especially in the late spring, when many developers voted in favor of HockeyApp with their feet.

I hope we managed to show how such systems allow you to completely rid you of the routine that your team eats, simplify the collection of information during testing, simplify the creation of tasks in a bug tracker, group the same problems. In general, do everything to make your life easier.

When confronted with such systems for the first time, people usually shrug their shoulders and say: “Magic.”