iOS App Deployment Options

iOS App Deployment Options for BusinessClients often ask ‘how can I deploy my app internally so just our staff sees it?’ Or ‘how can we sell our app to other companies without listing on the App Store?’ This article explains the different iOS app deployment options and pros/cons of each.

There are basically three ways to deploy your application. Either it goes into the public App Store where everyone can see it, a B2B deployment, or an Enterprise deployment where it is only available to your internal staff.

Option 1: Public App Store

The App Store is the huge marketplace for apps that we’ve all grown familiar with. As of this writing, there are over 1 million apps in the App Store. This is where we download all the major publicly available apps from Salesforce to Angry Birds. Every iOS user has access to the App Store and has their credit card setup with their iTunes account.


  1. Exposure to largest user base
  2. Opportunity to be ‘Featured’ or in the top rankings


  1. Competing against 1 million+ other apps
  2. Goes through Apple’s approval process prior to each release
  3. Can only filter user groups by OS version and country

Option 2: B2B Deployment

B2B deployment is where you can sell your app directly to businesses by registering their Apple IDs or providing them with redemption codes. B2B apps cannot be listed in the App Store (and vice versa) so it’s one or the other. There are opportunities to make different versions with different functionality, but B2B apps go through the same approval process as regular App Store apps.

Apps distributed via B2B have the same pricing model as the public App Store meaning they can be priced anywhere from free to $999.99. They are also created using the same Apple Developer account that is used for App Store deployment.


  1. Easy distribution directly to specific users via Apple’s Volume Purchasing Plans for Business or Education
  2. Ability to heavily customize the app for specific organizations beyond what would be suitable in the public App Store


  1. Goes through Apple’s approval process prior to each release
  2. Restricted to using public APIs and functionality

Option 3: Enterprise Deployment

If you’re looking to launch an app that is explicitly for your employees then Enterprise Deployment is ideal. This allows you to create a completely custom app that doesn’t have to go through Apple’s approval process. This means you don’t have to worry about their policies and can push the limits of your app beyond what is suitable for the public app store.


  1. Doesn’t go through Apple’s approval process meaning there are no delays and you aren’t limited to typical policies
  2. Can distribute the app internally without first registering devices
  3. Utilize advanced enterprise features for enhanced encryption, VPN, and MDM integration


  1. No exposure to users outside of your organization
  2. Requires an Apple Enterprise Developer account to publish apps internally

(image credit: florianplag)


Do and Don’ts When Creating a Mobile Website For Your Restaurant

We’re just wrapping up a project for a restaurant chain and I wanted to share a few good practices and lessons learned.

For this project we wanted to leverage their existing content and content management system (WordPress) as much as possible. We also weren’t going to redesign their existing site to be responsive, instead design a streamlined user experience for mobile visitors using the mobile app.

We also wanted this website to really shine. It was a goal from the beginning to make a mobile website that was really unique for this group of restaurants and didn’t look like the cookie-cutter style mobile website many brands have used.

With those two goals in mind we started with an almost blank slate. Our first objective was to make sure that when hungry people were walking down the street, it’ll be easy to find the location, phone numbers, and make reservations. For these three actions we created a clear call-to-actions that were persistent throughout the site.

On top of that we updated the CMS so that administrators can easily update the content, theming, and add additional restaurants as needed.

Here are a few of the key points you should consider when building a mobile website of your own.

What to Do When Designing a Mobile Website

  1. Make the call-to-actions clear. People are hungry and often walking down the street while they look for a place to eat. It’s important that when they’ve arrived at your mobile website, they find the information they’re looking for quickly and easily. Too many restaurants have their contact info, hours, and addresses buried behind too many taps.
  2. Make the page SUPER fast. Hungry people aren’t very patient so make sure the pages load lightning fast – even on a slow connection. Optimize as much as realistically possible. Use sprites, text instead of images, and mobile optimized graphics wherever possible.
  3. Integrate analytics: just like on a desktop site, be sure you’re tracking usage patterns and optimize accordingly. Try call-to-actions in different places and see which users respond best to.
  4. Ensure promoted links link to mobile friendly pages. If you’re pushing a link to your network, chances are they’ll be opening the link on a mobile device – especially if you’re posting links to social media or email.
  5. Keep every page branded and identifiable. Mobile websites aren’t like mobile apps – users can enter a mobile website from any link on the web and may end up 2, 3 or more pages deep in the site. This means that every page should have some type of branding so users know where they are.

What Not to Do When Designing a Mobile Website

  1. Some people using very small screens are hungry too. Make sure your website is designed well for screens ranging from 240px high and up – especially the call-to-actions!
  2. Forget to test on a wide variety of devices. Mobile websites are a challenge because they are expected to work on “every” device. This means that prior to deployment be sure to test on a wide variety of devices, OS versions and variants like Android and iOS, and yes… even browsers
  3. Link to desktop only content. If you’re placing any links on your mobile site, make sure they go to mobile friendly pages. The last thing a user wants to do is end up on a desktop site or huge PDF version of your menu.
  4. Make buttons and links too small. Since it’s a mobile website people are using their fingers to navigate so ensure that links have large tappable areas and aren’t too close to each other.
  5. hrink the desktop site without considering what content is/isn’t needed on mobile. A mobile website is an opportunity to simplify. There is likely a lot of information on a desktop site that either isn’t needed or at least doesn’t need to be prominent on a mobile site. Links to this kind of content can be placed at the bottom of a menu or in the footer.

We hope that helps you design your mobile website. If you’d like to learn more about our experiences we’re happy to meet for a 1 hour consultation.


Optimus Information Breakfast Event: Mobile Development Outsourcing Presentation

Thursday, November 27, 2014

Optimus Information Breakfast Series
Mobile Development Outsourcing: Do’s & Don’ts

This breakfast event will bring together high-level IT and marketing professionals. After breakfast and a chance to network with your peers, Rod Hsu, Chief Experience Officer, from nTrust will present on his experience working with multiple outsourcing vendors. Whether an organization has a “mobile first“ philosophy or is still defining their mobile strategy, this session will provide attendees valuable insights on working with a mobile development partner.

Location: Downtown Vancouvermobile-application-testing
Audience: CIOs, CTOs, CMOs, VPs – Technology, VPs – Marketing
Breakfast & Networking: 7:30am – 8:00am
Presentation & Q&A: 8:00am – 8:50am
Networking & Wrap up: 8:50am – 9:00am
RSVP: Email for availability and location details.

Rod Hsu is the Chief Experience Officer at nTrust, his focus is establishing the product road-map of nTrust’s systems and applications. With over 10 years of experience in the technology sector, Rod has successfully executed projects for companies in the telecommunication, finance, entertainment and software development industries. Rod will discuss his experience working with multiple outsourcing partners and touch on the following points:

  • Decision to Outsource
  • Advantages & Benefits
  • Disadvantages & Challenges
  • Advice & Takeaways
Mobify Video Thumbnail

Mobile Test Automation: Tools & Techniques

The mobile device ecosystem has exploded over the past few years and, with new devices entering the market every week, it shows no signs of slowing down. Because of this growth, it has become increasingly difficult to target specific devices as well as provide adequate test coverage for both new and existing platforms. By taking a breadth first approach, Mobify employs industry standard tools and protocols to achieve test coverage that compliments and enhances their fast-paced work environment.

In this interactive session, you will learn about ways to automate Mobile Testing, tools, techniques and good practices. We will also be sharing the step by step approach to start and institutionalize mobile test automation.

Speaker Highlights
Steve Calvert is the Engineering Manager on Mobify’s Customer Success team. He assists and mentors a group of Software and QA Engineers creating high quality mobile sites for some of the world’s biggest e-commerce companies. Steve has utilized countless testing frameworks and tools, and has depth of experience solving common testing problems using an engineering approach.

Reasons to Outsource

4 Common Misleading Beliefs about Outsourcing

Many people can find outsourcing topics misleading, as many folks do not have all of the facts or they are only looking at an industry that stands out and is giving the rest of the outsourcing crowd a bad name. We will go over a few points that will show you that many of the outsourcing techniques employed today use good practices and actually make sense for business and the economy.

Reasons to Outsource

FALSE: Outsourcing takes jobs away from Americans

Not all outsourcing projects are outsourced to other countries. Outsourcing simply means bypassing the in-house hiring process and hiring an individual or a business that does not work in your office.

FALSE: Outsourcing takes away employment from less skilled American workers

With the American economy the way it currently is, many Americans have been out of work and are willing to train to learn new skills then work from home at a very competitive rate. Again, jobs and money remain in America which include instructors required to train these new outsourced employees keeping people employed in America. This is a popular option many are taking rather than moving to a minimum wage position.

FALSE: Outsourcing hurts small businesses

Small business accounts for the majority of job creation in America and what we are seeing is “out with the old and in with the new”. Those small businesses that can no longer keep up with modern technology will be replaced by new businesses who started as an outsourced employee working from their living room and developed a successful business due to competitive rates and quick turn around. These newly developed businesses often employ like minded young people willing to work hard and spend their money on their new families keeping money in America with mortgages, car payments, raising children, etc…

FALSE: Outsourcing only leaves minimum wage jobs for the rest of us

Companies are waking up and have realized that they have been duped into paying someone $100,000 a year to type a few lines of code. This is when the layoffs start and instead of asking you to take a pay cut of $50,000 a year then advertising that position with a wage that would historically pay top dollar for nowhere near the industry standard, they have no choice but to outsource. Many of these employees who are now out of work are not willing to work for less than $100k. Times are changing and you need to change with the times. This often means working for less than what you are used to working for.

As you can see, not all outsourcing fears are valid, and many beliefs are simply not true. Outsourcing has been a touchy subject for many but when we take a few steps back we realize that we are all just looking to save a few bucks.


Using JMeter To Load Test Your Web App


Apache JMeter is a simple, free, open-source load-testing and performance tool for web applications. The latest version (1.1.3) was released in February 2014.

Load testing simulates and in many cases, exceeds production loads, performing many requests at the same time for extended periods of time.

Simply put load testing helps to detect the maximum number of users that can access it without interruption and help identify the stability of the app.

How to Download JMeter

JMeter helps you to figure out how your web app will behave when it is being stressed with large numbers of users or on various networks.

  1. Before downloading JMeter, confirm that you have Java Runtime Environment (JRE) installed. JMeter will not work without Java.
  1. Download JMeter from the Apache Software Foundation website. The Apache Software Foundation recommends using a mirror to download their release builds.
    1. When you arrive at the Apache Software Foundation website, click on Download Releases
    2. Choose the zip file under Binaries. The download will begin.
    3. Once downloaded, extract the zip file – you can rename the parent folder, but do not rename the sub-folders.
    4. Extract the archive and then run the JMeter batch file (jmeter.bat)  – this will bring you to the application.

Download Complete, Now What?

Once you have the JMeter up and running you’ll need to create a Test Plan. A Test Plan describes a series of steps for JMeter to execute when run. Your Test Plan should consist of at least one of each of the following: Thread Group, Logic Controller, Sampler, Listener, Timer, Assertion, and Configurator.

Thread Groups

A Thread Group is the first thing you’ll want to create in your TEST PLAN. The Thread Group is the main test-controlling element. It executes the same scenario over and over again, based on the number of virtual users you wish to simulate accessing the app at the same time.

Some Tips to Configure a Thread Group:

  • Limit the number of THREADS (users) within a thread group otherwise you’ll choke the server immediately
  • The odds are, a large number of simultaneous users will not access the app at exactly the same time, so set a RAMP-UP PERIOD (in seconds) of greater than zero… a one or two second delay should be fine
  • The longer you run your test, the longer you have to identify issues – but you don’t want it to run too long… that’s not realistic. If you set your LOOP value at 10 and you have 10 threads, your test plan will run 100 times
  • Rather than entering the server name and port on every single sampler, use the “HTTP Request Default” configuration element
  • To gather visible data you will need to add a Listener – the two most useful are “Aggregate Report” and “View Results Tree.” The Results Tree will provide details of each request generate by JMeter

Other Requests Within the Test Plan:

  • SAMPLERS perform the actual work of JMeter. The majority of samplers generate sample results, each with various attributes that can be viewed using Listeners
  • LOGIC CONTROLLERS determine the order in which samplers are processed
  • LISTENERS, in addition to “listening” to test results, provide the ability to view, save, and read saved test results.
  • The CONFIGURATOR element should be used to set-up defaults and variables for later use by samplers
  • You will need to perform additional checks on samplers using ASSERTIONS
  • TIMERS are processed before each sampler – each sampler, regardless of how many, will be performed before each sampler

When load-testing a web application, consider the following:

  • What is the testing intended to achieve?
  • What is the normal load (average number of users)?
  • What is the peak load (most number of users)?
  • When is the best time to load-test (testing may cause one or more of your servers to crash)?
  • Will use of any third party tool (e.g. BlazeMeter) provide more realism?
  • What is a realistic system load distribution across different modules?
  • What is the best way to isolate the system from external influences?
  • What limitations are imposed by CPU and RAM availability?

The JMeter Wiki is a valuable resource for all things JMeter. This link will help you to create regular expressions.


Areas of Focus in Web Browser Testing


Web browsers are arguably the most widely used computer applications around the world. Web browser testing thus becomes a vital part of any browser transfer or upgrade process. This is our approach to web browser and compatibility testing.

Compatibility Testing: What does it mean?

Compatibility testing is done to evaluate the user’s visual experience and the functionality of a browser in different conditions. Browsers are essentially translators – they translate data from HTML into a formatted, discernable web page. Since each browser has a different process for this conversion, results of the same HTML data can slightly vary from browser to browser. Testing must be done to check the browser capability when data is converted. When faced with this problem we call upon our expert testing team, which consists of professionals who are thought leaders in fields like test strategy, compatibility testing, performance testing and test automation. Our testing is a mix of manual and automated, with a keen focus on real world user experience.

Compatibility Testing for Browser Upgrades

Browser manufacturers generally release upgrades on a fairly regular scale. Browsers like Chrome and Firefox go through a six week release cycle for their upgrades. Most of the usual upgrades include routine bug fixes, and it is fairly uncommon to see major browser upgrades in regularity. Nonetheless, when a browser does undergo a major facelift, like the transition from IE9 to IE10, rigorous testing is required on the interface and behavioral level. The HTML language is defined by the World Wide Web Consortium, and undergoes regular updating. The major difference between old and new versions from the same browser is support for the newer portions of HTML. At the same time, additional features like email integration, instant messaging and cloud support might be added. Sometimes, the browser GUI or design is upgraded, which changes its look and feel. In all these cases, testing is required to assess the usability and user experience of the browser, and whether the upgrade is capable of supporting web applications designed for the previous version of the browser.

Areas of Focus in Compatibility Testing

These are the general areas of focus while testing web browsers. It is not an exhaustive list, and additions and deletions are done to it on a case by case basis. But on the whole, these are the areas where compatibility testing is required during browser upgrades.

  1. Font size validation
  2. Date formats
  3. Special characters with HTML character encoding
  4. Page layout in different resolutions
  5. Page content alignment to center, LHS or RHS
  6. Page Styles
  7. Page zoom-in and zoom-out functionality
  8. All images and their alignment
  9. Header and footer sections
  10. Mouse hover and cursor changing verifications
  11. Certificates
  12. Submit button handling
  13. Plugins – Flash, Real Player, Quicktime
  14. Audio and Video working
  15. CSS, HTML or xHTML validation
  16. Page validations with and without Javascript enabled
  17. Ajax and JQuery functionality
  18. DOM property settings
  19. RSS feeds and xml forms parsing
  20. Text padding

Get in touch with OptimusQA to know more about these areas of focus in compatibility testing of web browsers. We have vast experience in dealing with tricky situations, hard deadlines and challenging problems in GUI and compatibility testing of web browsers. We provide testing services that cater to cross-OS, cross-browser and cross-hardware platforms with a focus on creating a well designed and easily customizable compatibility testing matrix.


How to Make Your Test Automation a Success

Automated-Testing In a previous post, we wrote about the need for test automation, its pro’s and con’s when compared to manual testing. After providing this analysis, we felt it would be helpful to give a little more context. Here we discuss a few strategic tips for creating successful automated tests. The idea of automated testing is very simple – let the computer do the annoying, time consuming and mundane testing tasks while you focus on truly unique and interesting challenges without worrying about the thousands of test cases that require a mouse-click or a keyboard input. Its good for the programmer because it saves time and rids them of the mundane work that requires inhuman levels of patience, and its good for the project because the margin of error is greatly reduced. The real question revolves around how you approach automated testing. Many testing projects stall because developers cannot decide whether they should opt for automated testing and if they choose this route they become inundated with additional questions around where should they apply it and how. Here’s a few tips that will help you out in that difficult initial decision-making stage.

Tips for Successful Testing Automation

Automation is not Always Advantageous

Welcome to the other side of the myth. While many testers are scared that automated testing might take away their jobs, a few rely on it completely. Both practices are wrong. Like most things in life, automation works best when applied in moderation. Deciding how much of your project must be automated is the first step to a successful testing process. A few cases when automation testing might be a bad idea:

  1. When there is a chance of the automated tool quickly becoming obsolete because of drastic changes in the application
  2. When the test cases are manageable through manual testing.

The decision to go for automation is more strategic than technical. The expected ROI, time frame and costs involved in either cases must be thoroughly consulted.

Choosing the Right Tools

There are many test automation tools available on the market, a number of them open source: Selenium, QTP by HP, SilkTest by Borland, Calabash, Ranorex are some of the better known and trusted names. Some tools are designed to work with specific browsers and test conditions, while others are built to suit a more general environment. Many open source tools have easily available patches that make them suitable for a wide number of test cases. Be careful while choosing the right tools for the job, depending upon the scope, necessity and requirements.

Building a Stable Testing Code

Do not make the mistake of being lax while designing your testing code. This is a pitfall that many testers find themselves a victim of. Don’t be lazy about this; it affects the complete testing process. Look at the code development like any other software development life cycle. A thorough, quality design for your testing code will make your testing process a success, and can also become a viable asset for the future. Your decision to automate is going to save you a lot of time and resources. Try to employ some of them into building a good testing code.

Cross Team Code Development and Usage

You can make your testing code more robust and versatile by sharing it. Let different development teams come up with automated testing codes for different scenarios and create a code bank for your testing projects. The developers’ dream is creating a program that does their job. Unfortunately, that’s currently impossible, but we can at least create an army of programs that do all our mundane tasks for us and leave us with ample time to focus on bigger problems. The best part about this practice is that after some time passes, you’ll only have to regularly man and upgrade your testing codes and not have to start from scratch with every new project, saving more time and money. Get in touch with OptimusQA if you want to know more about the automated testing process. Automated testing ends up making life easier for you, the developer, the tester and your customer. But to avail this opportunity, you must carefully understand the process. Our professionals are always happy to help you solve your testing needs.


Regression Testing Mobile Apps

Cross-Platform TestingMobile app development is fast paced. In the last few short years, smartphones have exploded in popularity and user’s expectations of their software have dramatically increased. Release cycles have shortened and if apps aren’t regularly improving, users will start to look for alternatives. With this comes a pain: regression testing. It’s fun to design, develop, and deploy new features but it’s important to make sure your new changes don’t break existing functionality, introduce new bugs, or reintroduce previously resolved bugs. This kind of work can be tedious and less exciting that working on the new stuff. That’s why we do a mix of manual and automated regression testing before any major release. After establishing a testing strategy, the regression testing can be optimized to get the most value out of the efforts. Specifically, there is rarely a need to test every possible combination of platforms, operating systems, and devices – so the strategy is to identify the high risk areas and focus on those. Those areas will uncover 90% of defects.

Manual Regression Testing VS Automated Regression Testing

Automating regression tests can be very beneficial. It will give your team the ability to move faster, run through huge amounts of test scripts/test data in short periods of times, and get a higher percentage of the functional components and edge cases tested. However, testing directly on mobile devices can be challenging, but there is low hanging fruit when it comes to automating the testing of the backend/API. API test automation is not challenging and can be setup using open source tools. This level of testing makes it possible to ensure that at least the backend is working as expected without having to first troubleshoot from a mobile device. It also opens up the door to performance and scalability testing. And when you do need to test directly on device, there are three good strategies:

  1. Build a device library (or rent from local providers) that consists of a good mix of devices. The library should have the latest and greatest as well as the worst devices being supported. Then automate your deployment as much as possible and capture crash logs remotely.
  2. Get remote access to devices and test either manually or automated using services like TestFlight and Perfecto. These are cumbersome to setup, but in theory give you a great opportunity to automate tests on a very wide array of devices all over the world.
  3. Work with a partner that provides testing services. Either they write their own test cases/plans or you provide them, but at the end of the day you send a build and they return test results. This is the quickest and most reliable way to get consistent test results. The quality here is determined by how invested you and the partner are in the relationship and how closely you work together. In an agile world where things move quickly, the partner needs to have complete clarity on what to test, what’s expected to work, and what is out of scope for testing; otherwise, known issues will be repeatedly reported.

The best approach to regression testing is often a mix of manual and automated, but keep in mind that the benefit of automation isn’t to reduce cost or effort, but to increase the scope of what’s being tested.


VanQ Meetup: The Telus Story of Transition to Agile

images (3)

VanQ recently came together to hear Telus’ Hugo Sampaio talk about the transformation the company went through while transitioning from the classic waterfall to the agile method of testing and development.

Some Key Takeaways

Agile means different things to different people, and because of this lack of structured definition, it is difficult to implement. Often companies adopt a few agile characteristics to their basic waterfall model and convince themselves that they have gone agile. When large organizations decide to adopt agile as their development philosophy, the first thing they need to do is choose a metric that will define their agile development. The metric Telus chose, and recommends, is velocity. For a large organization, especially, velocity ends up being an important metric since it has to battle a lot of inflexibility and inertia from within the organization. The other important metric is quality, because you cannot have fast development that isn’t up to par with industry standards. You have to consider business interactions and portfolio management as markers for progress.

Top Impediments Against Agile

There can be a lot of inertia in a large organization revolving around the transition to agile. Typically, one of the main roadblocks is pre-existing company culture. A large organization is reluctant towards change, and when the change is as massive as completely restructuring the development philosophy, there is bound to be a bit of friction. The other impediments include lack of tools and funding, technical debt, and lack of competition in the marketplace. Adding to this is the trouble of training or hiring new resources and personnel. All these factors contribute to a reluctance towards transition to agile.

Where to employ agile

Telus made a clear distinction between areas, breaking them down by different degrees of agile methodology to be applied. The standalone areas are the ones where the transition is not only beneficial, but a natural consequence of adopting agile. These are completely new areas of development within the organization. The ‘integrated but new’ areas are those that you’ll commonly notice a little more of that opposition to agile, but are still top contenders for transition. The ‘old, integrated but recent technology’ takes a bit more effort for agile transition. For a large organization, a reachable goal would be approximately 80% transition to agile in two years. Hugo advises not to even touch the so-called ‘legacy’ areas of an organization.

Things to consider


The most important thing to consider is that there is no perfect tool. An ideal deployment involves multiple tools that the organization feels comfortable with using simultaneously. Make sure a development manager tool is used to oversee the procedures.


In the case of Telus, agile deployment was delegated to one test architect who worked as an overall project manager and liaison between various teams. They kept a 15-85 ratio between onshore and offshore personnel, with a near shore team stationed in mexico.


Again, the ultimate metric for progress was velocity. Adopting agile for functional testing is a comparatively trivial matter that involves defining test cases and automation. As opposed to that, agile development strategy, performance and structural testing requires a more creative approach towards service virtualization.

The Process

The approach towards agile at Telus involved scrum teams working on unit testing which was then consolidated to systems testing where the user stories were considered. The next step was system integration testing where the feature/application was involved and finally during performance/integration testing, end to end business transitions were completed. The marker for the next step was 80% code completion.


Hugo gave us some valuable pieces of advice for companies looking to transition to agile:

  • Be selective about applications

  • Set strong standards for tools and processes

  • Automate as much as you can.

  • You will still have to integrate waterfall somewhere.

  • Focus on performance testing rather than functional testing.

  • No process is perfect. Learn, try continuously.

Get in touch with OptimusQA to know more about transition to agile. For large industries, agile transition can be a cumbersome process if done inefficiently. With OptimusQA you can get the right help to make your transition a success.