The DCI study shows that 62% of surveyed people delete an app when encountering any defect in production. Probably, you’ve deleted one this month. No time for bad things, right?

What’s more, the total number of downloaded mobile software reached 218 billion in 2020 while it was 204 billion in 2019. The growth is tangible, just like the competition in the market.

This means companies reinforce their business strategies with mobile apps QA to win the race while introducing various testing types, compatibility testing included.

Alongside a high demand on cybersecurity, performance, automated testing, and others, compatibility checks join the range of mission-critical QA activities that help prevent poor user experience.

In the article, discover the importance of compatibility testing and learn 5 tips to bear in mind to ensure flawless software operation against different devices and platforms.

Compatibility testing: superhero of mobile software

The success of an application. What’s that? The ability to withstand heavy load, strong protection of sensitive data, overall efficiency, and many more. Once having covered all critical bottlenecks, companies are likely to expand their customer base and improve brand image.

Just imagine that the number of gadgets is extremely increasing and is expected to reach 18.22 billion by 2025.

Source: Statista 

Within today’s wide variety of devices, browsers, platforms, and other software and hardware parameters, the risks of defects on different gadgets and configurations are pretty high. To minimize the threats, forward-looking companies implement compatibility testing while avoiding issues that affect the functional capabilities of the app, its performance, and navigation.

Compatibility testing: Top 5 tips to keep in mind

When it comes to compatibility testing, it engrosses thousands of checks to perform. However, it’s impossible to verify all existing combinations. Before embarking on testing activities, the first thing to do is thoroughly analyze the target audience, existing users as well as markets, popular gadgets, product specifics, and business objectives. Having performed this analysis, you may set up the priorities to prevent extra checks and budget loss.

Let’s have a look what tips to bear in mind to bring your software quality to the next level.

1. Operating systems

Well, Android and iOS are the most popular OSs, but there are not the only ones among OSs to be used by the target audience. Each year (or more often sometimes), operating systems are updating while requiring refreshening test cases and constantly monitoring the most popular versions among end users.

2. Browsers

It’s hard to say the exact number of existing browsers as well as predict which one’s customers use the most. You have your analytics, but it’s still unfeasible to check the software behavior against ALL browsers and their available versions. Thus, performing the tests against the most popular browsers and conducting testing on other less pervasive ones would be a win-win decision.

3. Hardware

Smartphones and tablets of all shapes and sizes, different hardware components included, are everywhere. RAM, the CPU power, its number of cores, and others vary notably while affecting software functioning against a range of devices.

Let’s take this example. “Jack and Co” are developing a mobile app with built-in fingerprint sensors features. Considering that not every end user possesses a gadget with such hardware specifics, we’d say it’s vital to adapt the feature to non-fingerprint-enabled devices or make sure that the app operates smoothly against them.

4. Screen resolutions

Within multiple screen resolutions of smartphones and tablets, the most pervasive one, 360×640, is used by 10.04% of people worldwide. However, your target audience is likely to go beyond this size and leverage many different devices requiring due attention to compatibility testing.

5. Configurations

Testing the software under different system configurations embraces a range of users’ settings, including system language, network connection, security permissions, and many more. The number of combinations reaches hundreds or thousands of tests, thus making the compatibility matrix an inevitable part of a QA process.

Let’s just state it here, comprehensive compatibility testing helps delight end users with stable apps working against pre-defined devices and settings while allowing companies to improve ROI, mitigate business risks, reduce QA costs, and speed up the velocity of software delivery.

Mobile app testing: real devices vs emulators/simulators

If you are looking for a one-size-fits-all solution, there isn’t one, as projects vary and have specific requirements, timelines, and budgets. These all are the factors of choice: test against real gadgets or harness an emulator/simulator.

A strong point of real mobile devices is verifying real-life scenarios like financial transactions, display of user interface, system settings, etc. Real devices don’t just provide the possibility to test everything in its current state and within end-user conditions but also show limitations that customers may encounter.

Compared with real devices, emulators/simulators are not so powerful despite their cost-effectiveness. They mimic real gadgets’ behavior with no ability to repeat hardware characteristics, thus increasing the risks of missing defects. It is important to select checks acceptable to simulators/emulators and must-have checks for real devices.

Finally, what to choose then depends on a bunch of factors. Sometimes a good practice is to combine them within the need to get the most of compatibility testing.

In a nutshell

Within a tremendous number of mobile apps and devices, competition in the market is becoming more and more rigorous.

Now, along with essential tests such as performance, cybersecurity, automation, and others, compatibility testing has turned into a requirement.

By applying comprehensive testing and verifying software compatibility with operating systems, browsers, hardware, screen resolutions, configurations, and much more, companies accelerate time to market, increase ROI, optimize QA budget, reduce business risks, and get other business values.

In case you need support on compatibility testing, reach out to our specialists to get a consultation.

The perfect world should have every mobile app tested on all sorts of popular devices. It’s difficult to implement but possible and indeed necessary to accomplish. At the early stage of every QA project, the team should make a choice: run tests on emulators, simulators, or real devices.

Each team has to decide on the strategy to develop and how to base the checks. In this article, we’ll talk about different testing options, and we hope it’ll help you make a choice while checking the quality of your product.

Pros and cons of emulators and simulators

Emulators and simulators are good to grasp the idea of the product quality level at the start of the project. They are also necessary to conduct initial testing in a short time and detect critical defects.

Will emulators and simulators be enough for testing? Unfortunately, not.

Let’s consider their four main drawbacks

1. These solutions cannot follow human logic. Consumers use a mobile app on a real smartphone or tablet, but not on an emulator.
2. It’s impossible to emulate all characteristics of the phones and provide a real mobile environment when running tests on the emulator (e.g. phone’s overheating, battery level changes, conflict of additional applications running in the background, connection to the charger, wireless charging usage).
3. Many user actions cannot be modeled on all emulation systems (GPS, USB sensors, switching between Wi-Fi and mobile internet, etc.).
4. Checking on emulators cannot reflect technical features of each smartphone model and cannot consider the real operating system of the device.

Real devices: advantages and disadvantages

At the end of 2017, the total number of licensed mobile apps for Android and iOS had reached 5.5 million. Every month this number increases and seriously affects the competitiveness of the products.

Therefore, companies are interested in releasing apps that run smoothly on the majority of devices preferred by their target audience. Testing on real devices can help with that.

Even if checks on real devices are more resource-intensive and expensive, this testing has its advantages.

• It’s carried out in real conditions. During manual testing, the tester interacts directly with the device and can control the user interface in the same way the real consumer does (scroll, double tap, etc.).
• Such testing recreates the actions that consumers perform while using the app (e.g. hardware interrupts such as SMS, calls, push notifications).
• Payment gateway testing is also impossible to be performed efficiently on emulators. A QA engineer won’t understand whether the money was written off when one has subscribed to the service. The informative results of such a test can only be obtained with the help of a real SIM card.
• Another recent example is related to testing Pokemon Go. A simulator won’t show the location of a Pokemon in a 100.000 crowd. To perform high-level testing of AI games, the tester will have to use a real device.
• The accuracy of rendering up to each pixel can only be fully verified on a real device. It also allows testing the brightness and screen resolution, using different lighting scenarios. This is especially true for game apps.
• When releasing a product for new versions and models of smartphones and tablets, testers primarily use real devices.

Summing up

The success of the product influences the reputation of the brand and affects the number of downloads, users’ relevance, rating, and reviews. Therefore, before releasing the product, check it for the compliance with all the criteria of app quality.

End users trust the applications that run quickly and without errors. That’s why it’s important to find a balance between emulated testing and testing on real devices.

It goes without saying, it’s very сonvenient when all verification resources are available, and they just need to be scaled to fit your budget and product.

At a1qa, we run a proprietary testing lab with 300+ multiple devices – smartphones, tablets, wearables – that will cover the needs of any project.

Request a free consultation with a1qa experts and find out how we can ensure the quality of your mobile application.

We continue our mobile app testing series of articles. This time let’s discuss how testing team shall support the product at the release stage.

Once the first round of testing is over, it’s important to realize that it’s hardly ever enough to ensure outstanding quality of the product. The first round is usually followed by at least two more where bugs fixing and application stabilization should be verified.

Testers’ activities after the first round of testing

1. Defects validation. After the defect was marked as Resolved in the bug tracking system, the reporter should check whether it can be reproduced again or not. If not – the bug is closed. If the problem still exists – reopened.
2. New feature testing. If a new feature was added to the application, testing team should check it on all devices and compare the app performance with the previous build.
3. Regression testing is a type of testing performed to verify the previously developed software still functions correctly despite the implemented changes (software enhancements, configuration changes, software deployment in new environment, etc.)

In most cases the app will gain high quality after several test iterations and can be shipped to the market.

The app should meet the following criteria to be fully ready for release:

• Lack of critical and major defects that will affect user experience.
• App compliance with online stores requirements. Non-compliance may result in the publication deny even if the app is 100% perfect.

Depending on the mobile platform you build your app on, the release checklist may contain the following issues:

Android

• APK Extension files should comply with the requirements in the Dev Guide.
• The application interface should be developed according to the User Interface Guidelines.

iOS

• The application should possess a unique title and fall into one of the categories in the store.
• The application shouldn’t contradict the Human Interface Guidelines.
• The application can be published unless it contains banned materials or it duplicated the functionality of the already existing product.

Taking into account these and many other aspects you’ll ensure that the app is ready to be shipped.

That’s it. Now let’s briefly sum up the main peculiarities of the mobile apps testing:

• Strategy and selecting devices make a much bigger difference than for web and desktop systems testing.
• It’s a “must” to include specific mobile checks into test documentation.
• Utility programs can significantly facilitate your testing process (gathering stats, taking screenshots, etc.).

Make everyone feel the part of success

And the last tip that some managers neglect: thank your team once the project is over. It’s very important to know that you are valued. At the end of the day, the app’s release is the success of the whole team.

We are done! Thanks for taking your time to read the entire cycle of articles. We tried hard to compress the information we wanted to share in readable publications.

In the last post we’ll show you how we applied all this knowledge to ensure quality of one of the best-loved and best-known apps of 2016.

Sure you’ll enjoy the read.

The strategy is developed, test documentation is prepared, the team is ready to begin.

Time to run tests. As we’ve previously said, mobile apps should be tested against multiple devices. However, we’ve noticed that the majority of defects are not sensitive to the environment and will be reproduced on any device. Accordingly, it’s not necessary to perform all tests on every device.

The first testing round shall include the full test and compatibility test.

• The full test is aimed at checking the entire functionality of the application. Testing is carried out in two different ways: applying positive and negative test cases. At this stage an engineer should check how the app interacts with the supporting back-end infrastructure. Specific mobile checks should also be performed in full. Moreover, during the full test the app’s compliance with iOS and Android Interface Guidelines should be verified (iOS Human Interface Guidelines, Android User Interface Guidelines).
• The compatibility testing includes checking of the main functionality and testing for displays of the devices with rare software and hardware specifications. This test presupposes only positive test cases and checking the most common use cases. It doesn’t include testing against unthinkable usage scenarios.

Mobile apps testing is a widely discussed topic. As our article is targeting QA managers, we won’t go into the most obvious issues and better specify some of the tips that can be neglected or undervalued at times.

1. Set up Wi-Fi hotspots

It’s very important to check mobile apps at different connection types and speeds.

Setting up multiple Wi-Fi spots will help save time for testing, emulate real-world working conditions and discover defects that could have been missed otherwise.

Have a look at the spots examples:

2. Perform testing on more than one device at a time

This done, you’ll check two or more interfaces for the same aspects simultaneously.

3. Conduct education of the project specialists

For example, at a1qa company there’s a Mobile Applications Testing Center of Excellence. It provides regular trainings and workshops for the in-house team.

More experienced senior testers share their expertise, talk about differences in mobile operating systems, show real bugs detected in real software. It’s also useful to learn how to apply utility software that will help gather logs, take screenshots, install build, etc.

4. Take advantage of the technical audit services

Do not have the complete certitude in your testing process? If not, take advantage of the technical audit services to assess “technical health” of your project.

To put it simply, experienced consultants will arrive to examine your workflow, ask relevant questions on how you test, report results, assign people, etc. As a result, they’ll come up with recommendations for improvement.

Solving ongoing issues

The project proceeds as it was planned? The customer doesn’t interfere and let you do your job? Great! However, it’s a rare case. More often, you’ll have to deal with customer’s questions, proposals, new requirements. Do you know how to cope up with them?

For example, you’ve offered the customer to perform testing on too many devices and asks you to cut the number down. You should explain the possible consequences and fulfil their requirements. Using the collected stats, remove the less popular configurations from the list.

Another case that may require discussion is the customer’s request to run tests against a device that you don’t have at your disposal. Find out the reasons of such a need and try to offer another option that has similar software and hardware specifications.

The customer’s development team can’t reproduce the bug you’ve reported? Sometimes it happens. If you reset the device, the bug may not be reproduced on your device as well. But it doesn’t mean it doesn’t exist. To avoid such disputable situations, accompany defects with video or screenshots. It will ensure that the defects won’t be returned to you marked as “To be reformulated”.

Test ending

At the end of every test iteration, the following artifacts should be generated:

• Defects submitted to the bug-tracking system.
• Completed test documentation and quality report. The quality report usually contains estimation of the application current version quality level and is based on the number of defects and their severity.
• Most critical issues description (from the point of view of the end user).
• Statistical data on the number of defects and their nature. Statistics helps to monitor product quality dynamics and estimate the quality of developers’ work.
• Recommendations for improvements.
• Conclusion on the product’s readiness for release.

Once testing is finished, don’t rush saying goodbye to the customer. Product release is coming and it won’t happen without quality assurance and control specialists’ participation.

Next week we’ll talk about how testers should support the product release.

After developing testing strategy, we move to the next step and start planning test activities. Test planning involves describing tests that should be carried out in test documentation and allocating resources.

Before starting to write test documentation, define who will be conducting testing. List the individuals and indicate their areas of responsibility.

While this stage can be a tutorial in itself, this portion of the article aims to bring out the tips that will enable you to appoint the rights specialists.

• Assign the tasks to the engineers with the real-world experience in testing mobile apps.
• If you lack resources with the needed skills, conduct preliminary education of the team.
• If it is possible, address experts to consult you on the peculiarities of testing mobile apps.
• Advise your team to get familiar with the similar apps before testing. It will help to get an overview of the functional patterns and interface peculiarities of such apps.

Creating test documentation

After you’ve appointed the team to test the app, start preparing comprehensive test documentation.

Proper documentation can significantly improve the product quality due to clarification of details and check lists. Once testing is over, test documentation help to estimate how successful it was.

There are several types of test documentation:

The Acceptance Sheet contains a list of all product modules and features that should be tested, as well as the results of their testing. Generally, the Acceptance Sheet also contains statistics on the most important build performance indicators that will determine its overall quality.

The Test Survey contains the list of the specific checks of each feature and expected results.

Test Cases (test suite) is a set of input data, preconditions and postconditions, under which a tester will determine whether an application, software system or one of its features is working as it was originally designed to.

Whatever documentation type you use, it should contain all tests for any usage scenario.

Don’t forget about the specific mobile tests. We advise checking the following aspects:

• Installation, launching, deletion and application upgrading
• Screen orientation changes
• Working with various connection types and switching between them
• Responding to interruptions
• Graphical user interface and navigation
• Notifications
• Working with physical buttons
• Data control: saving, usage and deletion
• Application functioning in power saving mode

Let’s mention and explain some of these checks separately.

If you test an app using different types of Internet connection (2G/3G/4G/Wi-Fi) you may discover wrong handling of connection loss and incomplete files downloading at slow connection, which can be very frustrating.

Another example is testing of an application reaction to interruptions and switching to other apps. At times it may cause a disorderly shutdown and loss of the input data.

Too many checks to keep in mind? Make use of the mind maps. They efficiently structure information and will help mobile testers not to miss the points that should be taken into account.

Distributing builds to testers

At the stage of writing test documentation, negotiate the app distribution from the customer to your team. The easiest way is to send files by email. However it may be quite challenging as the security policy of your company may block the incoming letters with the attached files.

If the customer prefers to provide you with the build directly, ask them to use any sharing service (Dropbox or Google Drive) or distribution services like HockeyApp, iTunes Connect, Crashlytics, Ubertesters. The latter allow to upload apps, see previous builds and generate crash reports. The price of these services is very reasonable and it will definitely pay off.

Also it’s possible to upload the app from the online store if it’s already there.

Now we’ve completed another vital stage of our testing project.

Let’s make a list of what we’ve already done:

• Discussed all questions with the customer.
• Selected the devices for testing.
• Agreed on the type of documentation.
• Estimated the project duration.
• Negotiated on the builds distribution.
• Assigned QA engineers to perform testing.

This was our attempt to bring out the most specific issues of test planning. Everything is ready to start testing, which will be the subject of our next article.

Stay tuned!

a1qa Company specializes in assuring quality of software products. Mobile apps testing is one of the main services with more than 220 company’s employees certified to engage in mobile testing projects.

Today we offer you a series of articles prepared by Pavel Novik, head of the Mobile Testing Center of Excellence. The series will be made up of 5 articles. One article is mapped to one project stage. We’ll start with the proper strategy development. Then we’ll touch upon test documentation preparation and testing itself. Product release and associated testing activities will be the subjects of the fourth piece. And to make it more interesting for you to cope with all this amount of theory, we’ll tell you how we’ve decided to test the popular mobile game of 2016 and what bugs we’ve discovered.

So let’s imagine that we’ve been addressed to assure quality of some mobile application. The customer’s goal is to release the product to the market without defects.

We’ll start with a strategy. In our context strategy is the selection of testing devices and planning of all testing activities. The strategy should be presented and agreed upon with the customer.

The first step is to analyze the product and get answers to the following questions:  

• What are the project goals?
• What is the target audience of the product?
• What are the app’s technological specifications?

The answers to these questions may help estimate the project scope and assign it to the employees with the right set of skills.

What devices to test on?

Once we’ve received questions to the answers listed above, we have to compile a list of the rights devices to test on.

Consider the following factors:

• Customer’s preferences
• Target markets/regions
• Target audience
• Application specs (oldest and latest OS versions supported, app requirements to hardware, etc.)
• Budget limits and timeframes.

Let’s analyze every point separately.

1. If the app is already available live, the customer may have gathered stats about the user’s devices. Some customers also have their own preferences about the testing devices. Check if there are any in your case.
2. Target region also matters. If the app is aimed at the Asian region, give attention to the Chinese smartphones Xiaomi and Meizu. In Europe Samsung devices are more popular, while in the USA Google (Nexus) and HTC devices hit the market. However, making guesses isn’t a good way. Analyze statistics to make the informed decision.

There are numerous free resources that enable to see, compare and analyze the list of the most and least popular devices. Consider several of them and compile the final list. Some of the most popular are Antutu, Akamai, DeviceAtlas, Futuremark, etc.

For example, the most widely used in North America in December 2016 are the following:

3. Knowing target audience will help to limit the number of devices according to their “age”. Statistically, the youth prefer to use the latest devices, while the elder generation is loyal to the smartphones and tablets of 3-4 years on the market.
4. Analyze the hardware and software specifications and remove the outdated or, vice versa, most recent devices that aren’t supported by the app from the list.
5. And the last but not least important point is to comply with the budget and time limits. Sometimes you’ll find it necessary to test on 10-20 devices to provide full testing coverage. However, it may be impossible due to tough deadline or limited budget.

At this first stage you may come to face some odd questions from the customer. You’ll have to deal with them to avoid misunderstandings and make sure that the final results respond to their expectations.

Most commonly the customer will ask you about testing devices. “Why do you need so many devices?” “Why will it take you so long to click through the app?” Don’t grudge the time to answer them. A brief presentation about testing process, number of checks and the consequences of reducing the number of devices may be of help.

Initiate discussion on other options if you don’t have the required device for testing. Can the customer provide you with it? Can it be replaced by something else?

After addressing all the questions and gathering stats, we start drawing up a schematic matrix of configurations we want to test on. A test configuration is a combination of variable values (type of device, operating system, browser, CPU, database, etc.)

Every device type (smartphone, tablet, wearable devices) should be represented by various screen sizes and operating system types. Most commonly specific defects will depend on the operating system type. That’s why we recommend including the latest versions of OS in configurations (9.0 an 10.0 for iOS, 4.0, 5.0 and 6.0 for Android). Also don’t forget about beta updates. Include them into test plan.

Questions to ask the customer before testing

Is the app integrated with the third party services? What is the application monetization strategy? If it’s applicable, schedule integration and payments testing.

Was the application tested before? Previous testing results will be useful to estimate the quality of the app and to analyze the problems that were addressed by the predecessors. Moreover, ask the customer whether he was satisfied with those results.

Does the app support multiple languages? Then it may be worthwhile to perform localization testing. Negotiate it with the customer.

Finally, don’t forget to request access to the back-end and test accounts. It can be especially useful if you’re engaged in testing game app. Very often it’s not enough to pass the game to the end. Accessing the backend, you’ll be able to generate various playing scenarios and in-game events, say nothing about saving time.

When we’ve discussed all questions it’s time to start planning future testing activities, i.e. preparing of test documentation and assigning QA engineers. This is what we’ll clarify next week.

Mobile testing is a multi-faceted and complex subject area. A wide range of platforms and devices, as well as constant application updates make testing process complicated even for seasoned professionals, to say nothing about those who’re just making their first steps in assuring quality of mobile apps.

We’ve decided to help the beginners and give them a number of tips to keep them from getting lost in the mobile testing world. All pieces of advice were provided by Pavel Alekseev, mobile applications testing specialist.

Here are the 10 points we offer you to take into consideration to make the process of testing first of your mobile apps or features easier.

1. Heuristics and mnemonics

It’s very difficult to keep in mind all aspects of mobile testing. What we recommend is to use heuristics and mnemonics not to miss anything crucial. All of them were invented by professional testers. SFDPOT, I SLICED UP FUN and COP FLUNG GUN are one of my favorites. Do you know what they stand for?

2. Mind maps

The excellent tool that combines all advantages of test cases and checklists is mind maps. They efficiently structure the information and help you not to miss the points that should be considered by a mobile tester.

3. Screenshots, logs and videos

Prove your testing results with screenshots, logs and videos. What can be more reliable than the documented proof of the detected defect? For various reasons, some bugs can’t be reproduced on the developer’s machine. So it’s always worthy to support the found defects with screenshots, video or client logs (especially if there’s a critical application failure). By doing this, you’ll avoid doing one task twice and your defects won’t come back with a “To be reformulated” or “Incomplete” mark.

4. Test “monkeys”

Release your time for more difficult functional tests. Test “monkeys” can replace you in detecting crashes and hang-ups. These utilities imitate users’ simple actions, such as pressing OK button or taking a screenshot. After all, these simple steps take a lot of time and attention.

5. Screen orientation

Consider the screen orientation. Many applications are designed to support portrait and landscape formats. If this is the case, pay attention to how the application behaves when the screen orientation changes. Sometimes it may cause memory leaks or crashes.

6. Real users

Involve real users in testing the app. A couple of experts will definitely not be enough to go through all possible combinations of test scenarios, not to speak about all checking all kinds of devices (especially for Android). What is more, no one has denied the eyes fatigue. Obviously, the shortcomings that you’ve missed after a week of testing will likely be noticed by attentive end users. Approach volunteers from all over to examine the app during the beta testing stage.

7. Debugging menu

Simplify your testing process by using a debugging menu. Functions of such a menu make life of testers and developers much easier. Its functions may include the following:

• Simulating server responses;
• Setting particular parameters for a server;
• Cleaning sessions;
• Clearing cash, etc.

8. Developer options

Enable “Developer Options” menu. The hidden developer menu offers a wide variety of settings, especially for Android, from showing CPU usage to allowing mock locations.

9. Stress tests

Conduct stress tests. Determine the maximum abilities of the app before launching it. The stress testing will help to determine whether you can save the app stat how fast the app can recover after an adverse event.

10. Testing on emulators

Don’t overlook (but do not abuse) testing on emulators. Of course, nothing will replace the real hardware and software system. But in some cases it may be appropriate to use emulators. If the device is rare or expensive and your funds are limited, for example. Or it may also happen so that the client has put all the devices on sale and won’t let you conduct tests on real items. In should be noticed that the Android and iOS emulators are mainly designed for native applications. However, their default browsers will be able to accurately reproduce how the site will look like on a real device.

Of course, all these tips and tricks are not the full realm as there are many more tools that can mobile testing more efficient and tester’s life easier. We would appreciate to hear your opinion in the comments below!

Most people believe that mobile application tester’s work is rewarding and easy. Nevertheless, all mobile testers do face difficult tasks and challenges. This fact gives reason to state that mobile testing is not as simple as it might seem at first glance.

Zombie apps

Mobile testers always need to be aware of the latest trends in mobile applications. There is a list of applications (such as Facebook, YouTube, Facebook Messenger, Google Play, etc.) that have become the sample in their field. They set up standards of application design and functioning. Along with top applications it is worth mentioning so-called “zombie applications”.

The applications that are available on the store and have hardly any downloads are called “zombie apps”. In short, it is all the useless programs that are collected in application store and prevent new applications from reaching the top. At the moment, 84% of apps in Apple’s App Store are considered to be lifeless. The question is: how can a tester help the application be really effective and not turn into a “zombie”?

Tip 1. Efficient onboarding

In the mobile apps sphere onboarding is a set of instructions for new users, including hints, wizards, context help, etc. Modern users have neither time nor desire to read large and complicated manuals. They want to download an app and use it straightway. If you want the users to run the application, it’s necessary to organize mobile onboarding properly. The most common mistake is to write a lot of instructions at the very beginning. Think of yourself running the application for the first time. If you see a huge instruction, you a looking for the Skip all or Next button, don’t you?

There are some rules of efficient onboarding:

1. presenting only the real benefits that users can obtain from the application;
2. showing the process of work instead of describing it in plain text;
3. giving step-by-step instructions.

Tip 2. Plain notifications

Notifications are also noteworthy. If the application requires special settings, including an access to your camera, microphone or information about the location, the absence of the access makes it worthless. Notifications should have the following characteristics:

• clear to all users statements;
• user-friendly manner;
• behavior based text.

Tip 3. Timely feedback request

Feedback is very important for developers of mobile applications for several reasons. Firstly, it is one of the most significant elements in the applications promotion. Secondly, it is one of the best ways to find out application drawbacks.

Statistics say that only 5% of users leave feedback. The application rating directly depends on how and when the application requests the feedback. There are several ways to ask for feedback.

1. The most common and risky way is a dialogue or splash screen. Although it is one of the most effective ways, since users can’t but see, it usually leads to an app disruption.
2. Another popular but less effective method is a request for feedback via a banner, hyperlink, or notification. It does not lead to a disruption, but at the same time users are likely to ignore it.
3. The last option is to place the request in the application settings. It does not affect the application, but users will hardly leave a feedback using it.

The time when the request for a feedback appears is equally important. Let the user gain benefit from the application ant then call for a feedback. A good example is to ask users whether they like the app first. If the answer is “yes”, then a request should be displayed.

Tip 4. Well-structured login form

A crucial part of many applications is a login form. If the application has the opportunity to use a login through social networks (such as Facebook, Twitter or Google), then it will be a great way to prevent users from the login failures.

Quite common and annoying problem is the passwords and username restrictions. If the application has additional requirements, it is better to place them directly on the form.

Finally, you need to focus on the buttons location. It affects the efficiency of task performing. If users do not find the button, where they expect it to be, they can quit the application. Thus, the Send or Registry button should be near the last field.

As has been noted only 16% of all applications can be called successful. The above-mentioned tips are intended to help improve applications design and functionality and as a result reach the top of an App Store.

The article by Nadia Knysh was published on RCR Wireless News. Read the full version here.

We are witnessing the biggest technological turn in history where the very human is involved. Now, in a time when almost everyone has a smartphone, when all you need to reach anyone or find out anything is to tap your touch phone’s screen, we can proclaim the birth of a new type of human – Homo Tapiens.

Smartphone religion

Gadgets and devices have become a sort of religion in modern society. Kids are not dreaming about new books or new “Kinder surprises,” which was common for kids 20 years ago. Modern kids want a new iPhone, same as their fathers and mothers have.

This is where we are finding the new technological and psychological turn. In the 1990s, Andrew Bromfield translated a novel, “Generation “P,” where the term “Homo Zapiens” was used for the first time. According to the novel, TV had changed the human mindset. Once people got the opportunity to zap channels while seating or lying on the sofa in front of the display, the way of thinking was changed. The new turn of the 2010s has been tapping – hence Homo TAPiens.

Who maintains the new civilization?

Think of how you start your day. You wake up switching off or pressing snooze on the alarm of your smartphone. Then some of you are calling a taxi via a special taxi app or checking the bus schedule on another app. When on the bus, people all around you are playing games, posting “Good morning” photos on Instagram, answering emails and chatting via WhatsApp. The majority of people starts their day using their smartphones in one way or another.

As a tester, I know the hidden side of Homo Tapiens. To ensure the best performance and convenient interface of applications, millions of picky testers like me put all the apps through the wringer, testing for security, performance, usability, compatibility, localization and functionality. If you have an app on your phone that you love, chances are there were several developers and testers that worked very hard behind the scenes to get it that way.

Although it might sound odd, testing software is all about psychology and anthropology. When testing a new application, pretending tester must put himself/herself into the end user’s shoes and think of how a user who downloaded the app would respond.

Read the second part of the article here.

The article by Nadia Knysh was published on Software Testing Magazine.

There is a specific approach of completing the mobile park and its maintenance. One of the key factors is the proper usage of gadgets. This article provides some simple tips that will help your company to optimize testing on different devices, save your time and expenditure on these pricey resources.

Common rules of keeping your mobile park

The majority of QA managers are dreaming to have a unique mobile park for every project. However, they realize how expensive it is, so just a few companies can afford it. This is why most companies will keep only one mobile park for all departments and all projects. If it consists of up to a dozen devices, you don’t really need a strict control of who and where uses them. But if you have a greater number of mobile devices, you should have detailed regulations about borrowing and returning them back.

Mobile testing: how to maintain your mobile devices

We recommend starting with sharing a document the rules for your mobile park usage. Once a tester accepts the rules, he or she is allowed to take the devices. The document should define the rules for usage mobile testing devices, usage time limits, and penalties for breaking the rules. It’s a good idea to set the access priority for different testers. Don’t forget also to prohibit taking devices out the office.

It would be just perfect if all devices could be kept secured. If you trust all your colleagues, you can avoid these costs and equip a stillage for devices. In addition, you can also order a special stand for every device, which also enables charging them.

What else can you do to provide a safe and convenient storage for mobile testing devices? It is becoming a common practice to keep devices in plastic bags with zippers. Thus you can put some accessories such as USB cables, power adapters and headsets together with the device. Unlike standard paper boxes, plastic bags occupy less space.

When returning the device, the whole set should be checked so that none of the accessories is missing and the device is in its previous condition. When a tester returns a device, its charge level should be at least 80%. If not, a tester should be denied to return the device until it is charged enough.

All devices should have stickers with detailed information about the firmware version and its technical characteristics. The mobile park rules should state that any unauthorized updates and changing firmware versions are strictly prohibited.

The simplest way to watch the current device user is keeping a register of check-ins and check-outs. If you have money and your budget allows that, you can automate the process. To accomplish it you can use such tools as Sharepoint or Google Drive, for example.

How to properly use devices while testing?

Ideally, any device should keep the same settings during its entire life. This is why we strongly recommend fixing the device settings every time a tester takes it. When he is done with testing, he should restore the device to its previous settings. Resetting the device to factory settings each time would solve that problem, but we find it just as a waste of time.

Any new applications, uploaded files and changed settings might have an impact on the way a tested application performs. Keep in mind that the majority of users are purchasing mobile apps, rather than using Jailbreak or Root. These actions could influence the app performance and some bugs could be missed because of that.

When testing, it is also not recommended to have the phone connected to PC through the USB cable, since working like that adversely affects the device accumulator. Connect the phone to the computer only when you have to install a build, delete logs or upload files. The best way of charging the phone is mere using the standard power charger.

When you are done with testing, restore all the setting to the previous condition. You should delete files you have uploaded and applications you have installed, as we mentioned before. Double check whether the cache is also deleted. Then, clean the display and panels using microfiber or a special cleaning liquid, put all accessories and the device in the plastic bag. If it is charged enough, now you can return the testing set to the mobile park.

Benefits of regulations

If you follow these simple rules during testing and maintenance, the mobile park of your company will last the way longer and tracking a tester who uses the device at any time would be easier. Managing a well-organized and regulated mobile park is the key to successful and transparent work with mobile devices. It provides also a peaceful atmosphere in the company and the perfect project coverage by all kinds of mobile devices.

Mobile devices are growing in popularity daily and it is becoming more likely that software and Web applications will be run on tablets and smartphones. The importance of mobile testing is becoming increasingly crucial as a result.

My goal with this article is to provide some practical advice to keep you from getting lost in the world of mobile testing.

What first comes to your mind when you hear “mobile testing?” Yes, it is all about devices.

How to choose a proper device for testing?

If you begin by answering the following questions, you will significantly decrease the number of required devices and avoid spending extra time and money:

1. Smartphones or tablets? Or both of them?
2. What is the earliest operating system (OS) version supported?
3. Which devices could be the most popular for the target audience?
4. What screen sizes and OS versions are not covered by the devices from the points 1-3?

When working with iOS, you need no more than 10 devices to test. No more than 20 Windows Phone devices are required – for most of projects, you will need just five to 10.

As for Android, you will need a thorough approach while selecting, because hundreds of devices exist. Thus, it is really important to pick out the optimal combination.

How to test?

1. Analyze

Check the documentation and try to understand the business idea and application architecture properly. This allows you to find the most important basic defects to be fixed by developers first.

2. Functionality first, graphics later

Take the most popular device and perform the full test on it. You will notice all the application specs not covered by the documentation.

Ask questions regarding functional solutions you consider controversial and identify the most serious defects and bottlenecks of the app. Pay special attention to these issues during the compatibility test performed with less popular devices.

3. Include basic usability checks

Yes, we are testing the functionality, but basic usability issues could be easily “caught” and submitted without even applying the usability standards and special checks.

For example, is the application logic too complicated? Are the help sections easy to understand? Can we confirm that tips and labels are marked well and easily seen given the application’s background color? These and many other questions could help to make the application more user-friendly.

4. Do not forget about the real environment

Ensuring the gathering of real environment results is the most important thing, so do not forget to check all the specific conditions device could experience during its usage. This process guarantees that users will not have problems with the application in the event of issues caused by:

• Unstable network connections.
• All types of interrupts (SMS, notifications from Calendar and other applications, calls, alarms and low battery notifications).
• Low battery or small free space volume available.
• Working with different time zones and GPS.
• Different combinations of sound and notifications settings.
• Various test sizes, blind mode and specific restrictions to the data usage.

5. Exploratory and ad hoc testing – last, but not least

Even if you are convinced that all of the functions and possible environments have been covered properly, give yourself some time before deeming the results final.

Make some coffee, sit back and try to break the application first, or even ask someone from another team to take a fresh look. These types of steps can help to uncover sudden defects you missed before.

How to submit results?

The more information and descriptions you submit in your report, the more likely you are to fix and reproduce the defect.

1. Preconditions

The memory is almost overwhelmed? Or maybe five different accounts have been prepared? Or something is wrong with preinstalled applications? All of this information should be accurately mentioned.

2. Steps

This is the easy part – just describe scrupulously what you do and what you see without missing steps.

3. Environment

Include surroundings and settings you used while testing:

• Device type and version.
• OS version should be indicated for each device.
• If the simulator/emulator was used to reproduce the defect that should be pointed out.
• If the defect was reproduced on every device except one or two, you should specify that fact, as it could be extremely helpful for the developer when finding and fixing the defect’s cause.

4. Expected result

This is where you explain the way the application is behaving or should behave after the bug is fixed.

Basically, this section provides actual instructions for the developer, details of how the application should work in the correct case and why in any case where the defect’s cause is not clearly identified.

5. Additional information

This section of the report allows you to give a complete picture of what has been done by the tester and the results that he or she achieved. The below items help the developer better define the battlefield:

• Screenshots
• Screen videos (if the screenshot is insufficient)
• Application logs: necessary to be attached to each graphical defect. All log types should be enclosed (collected by the device itself, collected by additional applications such as CatLog for Android, collected with help of SDKs or other utilities, including Console in the iPhone Configuration Utility)
• Additional items that were used to reproduce the defect: all of the files, images, videos, provisioning profiles used to reproduce the defect must be affixed; sometimes one symbol in the file may cause the defect, and even logs could not reflect this.

THE ABOVE TIPS are merely large strokes – not the full realm necessary for functional mobile testing.

However, they should help provide a basic understanding of the structure and substance for the mobile testing process.

You can also rean this article on MobileMarketer.

It is well known that the sale of mobile devices has exceeded the sale of desktop computers and laptops for a few years running. And don`t forget about the declining cost of mobile devices, resulting in greater accessibility for the consumer.

These two facts have not only led to the current high number of sales for mobile applications, but also lead directly to the growing need for app development.

According to the International Data Corporation (IDC), there will be 76.9 billion global downloads of mobile apps by next year at a value of $35 billion, according to sourced mobiThinking. As a point of reference, 300,000-plus mobile apps were downloaded 10.9 billion times in 2010.

With the continued high demand for mobile apps, marketers, retailers and developers in 2013 will face many challenges and opportunities, mostly associated with new devices or new versions of existing devices. So what exactly awaits us?

All about size

It is likely that mobile phone manufactures will continue to increase the diagonal size of their phones. As a result, developers will need to adapt existing apps to fit the new screen sizes, while addressing optimum performance within the new format. The good news is that these larger screens are becoming more informative, which means the consumer clicks or touches the consumer to access apps and, therefore, less tweaks needed by developers.

Rise of new platforms

Recent Windows Surface launch has become an important event in the world of mobile app development. This is a significant step towards the adaptation of desktop apps for mobile operating systems, both in terms of the availability of the tablet as a full desktop operating system and the ability to use a desktop OS for touchscreen devices.

The main challenge with this device is that there are two versions of the operating system: Microsoft Surface Pro and Windows RT Microsoft Surface, which means that two more versions of any given app should be developed.

Speaking about HTML5

In terms of new technology, the introductions of Mobile HTML5 and Near Field Communication (NFC) are the most important developments for the mobile app industry. Having become popular after the “death” of Microsoft Silverlight, Mobile HTML5 has gained ground in numerous ways.

Most devices already support Mobile HTML5, there are no significant competitors since the abolition of Silverlight, and the high level of performance from current mobile devices allows HTML5 to take the full advantage.
HTML5 is also the most obvious way to create a universal app that supports various mobile operating systems, which doesn`t mean that “native” apps will disappear, as they are a mainstay of connecting users to a particular mobile platform. Despite this fact, understanding of HTML5 is a must for mobile app developers.

NFC is a relatively new word in the world of mobile devices that refers to the ability to exchange data between devices at a distance of approximately four inches. Current leading mobile OS Android devices, such as the Samsung Galaxy S III and Motorola Droid Razr Maxx HD, already have the NFC-chip built-in and the next generation of Apple’s iPhone may likely include the chip.

The quick deployment of NFC technology means new opportunities for mobile interaction with various other devices and, as a result, the emergence of new and improved services, such as one-time ticket authorization and faster bar code/QR code recognition. With these advancements, developers get new challenges with existing payment systems and creating separate niche-oriented apps for miscellaneous services and goods.

Moreover, this technology can be used in services and devices for personal identification by the owner of the mobile device and, therefore, involves the development of customized apps for data services. Currently, there is no protection from a third party in the implementation of NFC standards, which means that the developer should apply to cryptographic algorithms to provide high level security. This implies an increase in the time and effort for app development.

What is all the hype?

Gartner’s Hype Cycle neatly represents the maturity and adoption of apps and technologies. Among those noted in 2012 are HTML5 and NFC. Both surrounding the peak of inflated expectations, it is still unsure how far these technologies will progress over the next five to ten years. Will the other technologies noted provide the most feasible and efficient methods of adapting and creating mobile apps? Only time, and successful apps, will tell.

Quality Assurance plays a vital role in the development of mobile applications, but many underestimate how critical mobile app testing services are to the overall success of the app development process.

QA should be involved in all stages of development, starting with concept creation and till the post-development review process, so as to ensure the success of an app. Let`s go through the phases.

Preparatory phase

The phase begins in between the end of app development and before the first assembly of a functioning app begins. During the phase you are to pay special attention to the points like identification of target devices, introduction of functional requirements, test documentation development, test environment preparation. The phase put you through some challenges, like determination of target devices.

Though, if you follow the guidelines the challenge becomes quite clear. So, start with figuring out the devices that the application supports (phones, tablets, other devices – players, navigation). Then you need to determine the earliest version of relevant operating systems that supports an app. Doing this you`ll have to choose between two options: a special restriction, which will further be reflected in installation requirements, or you should select the least productive OS that still can provide perfect app functioning.

For example, for iOS devices it should be the first iPad with iOS 5.1.1 (if the application has no performance problems on it, there should be no problems in later versions of the device); the iPhone 3GS only runs iOS 4.3.5, so it is the least-productive platform to develop for, but the device is still popular globally.

After all that, do not forget to identify the most popular models for the target audience for app verification, and then select additional devices with different screen sizes than the most popular models.

Functional requirements

The next step is introducing functional requirements. It is important to define whether the app is browser-based or installable. Whether it interacts with a Web site or database, other apps or social networks, or maybe it is completely self-contained (does not interact with the Internet and cellular network).The information collected at this stage should focus on important app functions.

Test documentation

Then it is time to develop test documentation. Many mobile apps need high-level documentation, as tasks within the app are typically executed with just a few clicks and do not involve complex tasks.

The simplicity means that there is no need for detailed testing instructions. For non-mobile apps as well, much depends on optimally partitioning app functionality into blocks while creating test documentation, allowing connections between different units to be tracked accurately, and moreover, it requires less time to verify various functions.

User feedback

If the app got updated version from AppStore or Google Play, it is useful to analyze user reviews and feedback that has been posted on social networks and the app marketplace. Problems are often found and documented in these environments by end users, and this information will help to identify and focus on the app’s most important shortcomings.

When new app versions are introduced, users expect to find that specific problems to be fixed. If they are not, it often causes negative reaction, especially if they and others have taken the time to document or report errors. It can be useful to add end-user concerns to the test checklist as a separate category of problems, and pay special attention to them during testing.

Test environment

Preparing test environment typically requires the installation of required apps on the mobile device and on a QA engineer’s computer, which can include apps such as the iPhone Configuration Utility and Android SDK.

Starting from here, the process becomes an iterative cycle. It begins after the integration of the first assembly and ends with the completion of product development, including testing multiple assemblies at regular intervals (once or twice a week, for example). Development and testing are carried out simultaneously after each new build of the app.

The main idea of testing is for the QA engineers to put themselves into the user`s shoes, but with a more profound knowledge of the settings and the principles of a particular device and the features of the app being tested.

Here are the characteristics of different types of apps and operating platforms, along with areas that require special attention when it comes to testing for various mobile operating systems.

Apple iOS testing

1. Verify compliance with UI Guidelines from Apple
2. Apps must be backward-compatible with the OS (a new version of the OS is expected to maintain full functionality of the app)
3. When multitasking, all settings and current progress of the app must be preserved when the app is minimized or when the user switches between apps
4. You must be able to debug the app and collect logs via a USB cable connection without additional operations being performed on the device
5. There is no need to reboot the device while testing

Google’s Android testing

1. The app must support running multiple apps in the background
2. For debugging via USB, you must first select “Enable USB Debugging” in the device settings, and then connect the device to the computer
3. When using the hardware “Back” button, the app should be minimized, not closed. Otherwise, the device may require rebooting to run the app again. You can also use an app such as Task Killer as an alternative to rebooting.

Windows mobile testing

1. The app must support multiple apps running in the background
2. You must be able to close the app through the task manager
3. You must connect the device to a computer via USB to debug the app.

Check these, regardless of the device/OS

1. Input methods, devices and form factors (number pad, qwerty-keyboard, touch screen, side panel, external devices)
2. Different networks (WiFi, Edge, 3G, 4G, GSM / CDMA), including unstable networks
3. GPS functionality
4. Energy consumption
5. Accelerometer
6. Standards Compliance mobile development (AppleHIG, Android principles)
7. External interrupts (calls, SMS, stability in the event of a shortage of disk space, installation and restoration in the background)
8. Memory cards
9. Stability after a crash
10. Using data on the device (address book, calendar)
11. Access rights apps
12. Social networks and other third-party apps
13. Interface (animations, icons, portrait/landscape orientation, Retina (for iOS), the visibility of labels, size, ease of use)
14. Time (server time/phone time, time zones)
15. Redirections (Web → app, app → Web)

Control phase

The control phase is where you prepare the draft for release after product development ends.

This phase includes detailed and complete testing (during early iterative phases, a full test might not have been performed, or more regression tests may be required) to stabilize the app and uncover minor defects.

These are also tests for loss of auxiliary modules (testing in the app can present opportunities to check subsidiary functions such as Log Collector and artificial recharge of game balance, which were added to facilitate or reduce testing time, but that should not appear in the final product).

The approach typically used for testing in this control phase is somewhat like using scaffolding when constructing a building.

We can add features and change settings for the sake of development and testing that will not be in the final version of the app.

For example, an app undergoing control phase testing might be set to provide endless lives or infinite ammunition for the tester.

Once the building is complete, the scaffolding is taken away – much like how settings and features used to test and develop the final version of the app are then taken away before it is made available to the public.

Acceptance testing

The final phase is acceptance testing. The focus here is to check, if the app matches the acceptance criteria (which was defined at the start of the development cycle) or not.

Acceptance testing is performed based on a set of typical test cases and scenarios that are created based on the app requirements. It may specify “no major defects exist in the application,” or “all application labels and functions fully correspond to the rules of the target language.”

This phase of testing is also typically the most important, especially when further support of the app is not provided once it is made public.

Acceptance testing is used to ensure the quality of the app is perfect – or near perfect – and to ensure that the customer is happy with the results of the development process.

At this step, the customer decides if the app is excellent enough to accept it as final, and that decision is primarily based on the test results.

AFTER CAREFULLY tailoring these test phases to the app being developed and meticulously carrying them out, you are certain to end up with functional product.

The author of this blog post, Tatiana Mahlaeva, is an experienced tester and a QA analyst at a1qa. Having started her career 3 years ago, now she manages projects, analytical activities on the pre-sale stage, and runs trainings at QA Academy. Being a well-versed specialist she knows every hardship of the mobile testing process.

Timely, thoughtful and consistent testing is an important part of the quality assurance process. So, what helps to ensure consistency and structure of mobile application testing services? First and foremost, it is well-written test documentation.

When creating a strong application testing plan, you should pay attention to two important aspects. First, all application functions and device features must be tested. Second, it is desirable to expand coverage to previously detected defects and rare scenarios leading to their reproduction.

Before jump-starting to the DOs and DONTs, let us divide all the functions of the application and device features into several large groups. Though, the division is not definitive, it offers quite good classification option:

• Lifecycle issues;
• Audio/video;
• Graphic user interface;
• Network-related issues;
• Hardware/software specialties;
• Data-related issues.

Let`s start with lifecycle issues. This functionality includes un/installing, previous version update, and the initial steps of opening an application – launch and log-in processes. The most common defects here include:

• Blank or corrupted application icon/name;
• No registration function;
• Incorrect or missing application version number;
• Application data not saved during update process;
• User data remains on the device after removing the application;
• When updating, a new version doesn`t fully replace the previous one;
• Issues with updating from a previous version;
• The inability to log out permanently (critical for public devices);
• No synchronization in accounts (when both desktop and Web versions exist).

Next is audio/video group. There are typically not many defects in this part, but it is important to keep them in mind, because defects they can so mush, that a user will forget about the app forever. Among those you face:

• When the application has its own sound, the music player application is not paused;
• The inability to turn off sounds in the application;
• Video does not pause, when another video on the page begins to play;
• Video problems with a device/application having two or more screens;
• Sound lags behind the video or on-screen action, or video/action lags behind the sound.

Graphical user interface defects exist in every application. The reasons vary, for example, remaking the application for another platform and static design leads to problems on devices with different screen resolutions. There are many types of such defects, the most common one are:

• Portrait/landscape mode issues;
• Resizing issues;
• Animations that do not run smoothly;
• Inconsistencies with action elements and their place in the design;
• Non-retina display for devices with retina support;
• Inconsistency with platform standards (e.g. iOS HIG);
• Font size and type issues (cut text and elements overlapped);
• Keyboard issues (e.g. standard keyboard in case of numeric-only field);
• Grammar issues.

When it comes to network-specific issues, most defects are found in case of switches – switching between Wi-Fi points and switching from EDGE to 3G. It is also necessary to check what happens with a poor connection (real or simulated).

Of course, if the application needs to transfer large amounts of data, crashes can be caught during normal EDGE connection, while in airplane mode, or with cellular data switched off.

All of these should be checked at all key points of the application – installation, launching, registering, logging in and submitting forms. The application should react correctly every time – working normally, or displaying a message asking the user to check the connection.

The next group includes potential defects. Hardware and software factors are too different, especially for Android devices, to cover all of them in this article, but let us try to highlight the main areas of concern:

• Low operating memory issues (memory warnings);
• In-app purchase issues;
• Gestures reaction;
• Interruptions (calls, messages and low battery);
• GPS (location services) issues;
• SD card issues;
• External devices issues (display and keyboard);
• Browser, email client and other OS-specific services issues;
• OS compatibility issues.

These are main groups of issues specific to hardware or software. Though, there may be no or very few defects in each of them.

Please remember, that if your application uses any of the device specific functions (e.g. location services) – you must include deep checks of this functionality in your test plan.

Data-related issues are specific to each application type. Games will have data issues that are completely different from enterprise applications. Data types can also be different.

Here are the main points to check:

• Time settings (Does the application use server time or phone time? Is the time determined correctly?);
• Correct application of check-ins/adding friends/sending gifts and other data exchange between the device and server;
• Ensuring that progress is saved in the application;
• Desktop/Web profiles, if any, are correctly synchronized;
• File types – all necessary types are supported, and unsupported types are correctly processed with appropriate messages;
• Large and small files are correctly processed;
• Caching issues;
• Redirecting from the application to the Web and vice versa;
• Social network content.

The groups outlined above are not comprehensive, but they provide a high-level checklist that should be completed with specific checks based on the type of application being tested.

For rare defects, consider conducting research on application reviews in markets or social networks – particularly if this is not the first version of the application or there are similar applications already available. The defects can be detected during ad hoc testing or with special complex scenarios based on prior experience.

Here are several examples:

1. A game crashed if there was a need to download audio files from the server larger than 25MB
2. A blank white space appeared on the Settings screen when the user quickly changed the On/Off setting (five times in a second)
3. “Post to Twitter” posted tweets not to the current account timeline, but to the timeline of the account which was the first used in the application

This is the basic tips to start writing a test scenario, they define the process, though it`s not a complete solution for the creation of test documentation. Remember that the point is to include all possible sources of defects – functional specification, your experience and social network reviews.

The final test documentation for each application will be different, and may vary greatly for different projects. Your skills, experience and knowledge of your application will be the key in finding your own best solution.

Users divide almost all popular companies  into those they LIKE them, those they DON`T. The situation with iOS7 by Apple is of no exception. Some users are really amazed by it, others surf trough the Web seeking for the way to roll the system back to iOS6.

Being a professional tester I dare join to none of those two groups, what I can do is to draw your attention to the pros and cons of the OS making an experienced-based insight.

When we got the project comprising iOS7 testing, first things we faced were, of course, the interface changes. Flat design by Jonathan Ive comprises minimalism and strives for perfection. Nevertheless, changes made in the interface entailed applications defects. Bugs arising in lists, menu, pop-ups caused first challenges like inconsistent menu transposition, shift of application forms, unavailable scrolling, lists` cutting.

Functionality changes weren`t left aside, and due to them new OS tracks and remembers user actions searching for necessary content, like fresh tweets and news. Updated task manager allows app-previewing before direct using, which is, certainly, an advantage. But nothing is perfect, when you open several apps and turn over the phone, some screen elements may not follow the screen position. Users also point out that, when you remove an app its icon sticks to the control panel and doesn`t quit. In the same time the app-icon may vanish from the panel, when you need to close an app.

New design made the phone better in use. For instance, you don`t need to reach the left upper corner to get to the superior menu item any more. Now all you need is to run your finger over the screen from left to right, as if you flap away something, though this useful function doesn`t work everywhere.

AirDrop – one more Apple innovation – is a quite efficient way for file exchanging between Apple devices via radio channel. Nevertheless, function using is possible, if you have iPhone 5 and newer Apple devices. There can also be malfunctions, when you try to connect devices operating on iOS and OS X. And to crown to it all, AirDrop function can cause problems for apps installed on iPhone 4s, 4, 3gs.

Going through the testing specifics, I would like to add that a tester should be specifically accurate while localization testing and app internationalization, as users really complain a lot about internationalization of new OS.

Today more than half of all devices operating on iOS got updated. Making the research, I`ve come to a conclusion that improvement of iOS7 calls for better cooperation of developers and testers. As users are not satisfied with the OS, they cannot roll it back to iOS6 and performance of iPhone 5 is quite low. Moreover the apps often fail and crash, which again causes users discontent.

So, you can adjust to iOS7 specifics or go on using iOS6, all is up to you.