5 Ways to Test Your Mobile Apps

Ula Rustamova on 04 April, 2020

When developing a software product, there comes a moment when you need to test a new feature, make sure the application does what you want it to do, and that it doesn’t crash in the middle of you inputting your name to test registration.

It is quite hard, though, to balance between quality and the release date of the software product. Teams constantly face obstacles on their way to implementing new functionality, pushing themselves to test quicker and more efficiently. It is estimated that 20-30% of development time goes into testing any software project at best.

Correctly prepared testing process can speed up the process, and most importantly, ensure that the released software will not end up crashing and worsening their reputation in the eyes of the user.

A 100% bug-free software is nearly impossible to develop. But a team can dream, and thus work their hardest to come as close as possible to this goal.

Here, we give a summary of possible ways you can go about testing, from efforts you can put yourself from the beginning, to stress testing your application using outside resources. We also give advantages and disadvantages of each approach, and scenarios when each of them can benefit your testing the most.

In-house testing

Testing your application using your own resources and capacity within the team of developers is perhaps the most commonly used approach. Even if other methodologies are applied within testing, in-house testing tends to happen first, quite naturally flowing during and after the development process.

There are, however, several ways developers usually can go about testing the applications.

While testing can be manual or automated, many methodologies include both and usually are categorised into functional and non-functional testing.

QA non-functional testing looks at vulnerability, compatibility, usability and performance. You can read more on non-functional testing here (an article on non-functional testing?).

Without the problematic aspects, verifying that the application works the way it should falls into functional testing methodologies.

Some of the methodologies widely used by teams are (but not restricted to) the following:

  • Iterative testing
  • Monkey testing
  • Regression testing

Iterative testing

Quite commonly, big projects are divided into smaller chunks. The parts can therefore be seen as an iteration, each being developed sequentially. At the end of each iteration, a new part is developed or an existing part is enhanced. As soon as an iteration is completed, the whole system can be tested.

When the results from testing and feedback is available, it gets incorporated into the next iteration. One of the things that typically happens, is that the experience from past testing phases speeds up the process, resulting in quicker implementation process and better system understanding.

When does this work best?

Iterative testing can serve well a team, which already works in an iterative fashion. If the project is already laid out with iterations in mind, this testing methodology can provide powerful means of gradually improving software, while avoiding disruption to user experience.


  • Immediately available results
  • Gives good overview as the development goes on
  • Beneficial for documentation


  • Increases communication overhead due to delivery of feedback
  • Bigger projects require much more time

Monkey Testing

Most things that are common sense to you, might not be that common to the users. When exposing your application to the world, you can expect some users to do what you would expect them to do. But sometimes, if not most of the time, users can provide strange inputs you would never expect.

Hence, making sure your application can face any sort of oddness is good practice.

Monkey testing is an interesting alternative to old school, structured testing. Its whole purpose is to expose the program to the most random conditions you could possibly think of.  It does not have rules, and does not follow any predefined strategy.

Although, it might seem like Monkey Testing would be done in chaos, this technique is commonly automated. Programmers write short scripts that can generate random inputs and feed the application to analyse behaviour.

When does this work best?

This technique works very well when you are just starting off with the testing, before going into testing critical functionality, e.g. transactions, server communications. Your goal is to try breaking your application by providing non-stop random inputs.


  • Easy to set up and execute
  • Not costly
  • Helps identify unexpected errors
  • Can find relatively small bugs, which have high impact on user experience


  • Can find only relatively small number of bugs
  • Reproducing the bugs (depending on the scripts) can get quite hard

Regression Testing

Regression testing sounds much more complicated than it is. It simply means re-executing some or all previously developed test cases to ensure that old code still works after recent changes. It is also worth noting that some teams prefer manual regression testing to automated ones due to higher flexibility.

When does this work best?

Regression testing works very well when you are working by Agile methodology and/or there is a slight change in the requirements for your application. It can also be used after performance issues have been fixed, and you need to check that the application still complies with the tests.


  • Helps to make sure that small changes/bug fixes don’t cause new bugs
  • Ensures previously found bugs are not creatable
  • Can be done using automated tools
  • Promotes product quality throughout development


  • Can be tedious if done without automated tools
  • Even small changes need regression testing, which can be time consuming

Outsourcing company/tool

Many teams nowadays lean onto software separate from the software being tested, to see if their applications produce any bugs and meet the requirements. These tools run internal algorithms and produce methods, some of the mentioned above, reducing the amount of testing and effort the team itself has to put in.

Tools available online provide access to testing within many areas, such as web application, database and scripted testing.

When does this work best?

Automated tests, especially those outsourced to other companies can work well in companies, which are busy with documentation and have the resources to do the initial set up. If the running of the tests is an issue, and the team does not have the capacity to think of all testing scenarios, they can refer to the available tools, which have construction of those cases as their main priority. This can work especially well when the automated tool focuses of tests suited for the kind of domain you are interested in. For example, if the application needs a lot of security testing, a tool that already contains the exhaustive scenarios might be just what the team needs.

From the first glance, this approach might seem like a perfect solution, but as always, there are some tradeoffs. You can see the overview of advantages and disadvantages below to make your call.


  • Faster feedback and results
  • Reduced expenses
  • Higher defect coverage, more test scenarios


  • Requires more initial developer time to set up
  • Complex analysis for failed tests, takes a lot of time to decide the cause of the bug
  • Additional deployment costs
  • Increased tooling needs (frameworks, test runners, etc.)

External focus group

Focus groups, previously used predominantly in market research, have recently been growing in popularity within user research and software testing as well. The group usually consist of 5 to 10 people who work with a facilitator or a researcher. Focus groups are usually run offline, although online research can be conducted, too.

When does this work best?

Focus groups provide a useful method to investigate complex behaviour and how it changes over the duration of the ‘experiment’. If you are looking into understanding how users feel, and what their initial subconscious reactions may be (e.g. facial expressions, opinions), focus groups can be a great source of information that may not be available otherwise.


  • Useful to obtain qualitative information (behaviour, feelings, perceptions, etc.)
  • Can provide a broader range of information
  • Offer a two-way conversation and an opportunity to seek clarification


  • Group participants may not be representative of users
  • Results might be subjective to the facilitators
  • Can be tricky to quantify and analyse
  • Costly
  • Takes a lot of time

Crowdtesting with Buglance

Buglance is a crowdtesting platform that provides a testing approach that does not fit entirely into any of the categories given above. Buglance is a platform that crowdsources its testing to more than 40,000 testers on about 10,000 devices.

In some ways, it is similar to Monkey testing, but without the developers’ biases.

In other ways, it is similar to focus groups, but the focus group consists of thousands.

How is it different from an outsourced automated testing tool? Well, superficially it sounds like one. However there is a caveat to it. There are no predefined set of tests and no compliance to fit to be able to run tests. It gives access to thousands of testers around the world, that are using the application and reporting bugs, most of the time as early as in 24 hours.  Importantly, it differs from automated tools in the variety of devices you can test your application on. And even more importantly, the crowd of Buglance reveals bugs that the developer teams might have not ever even though of.

Read more about how you can better your testing methodologies and to learn more about Buglance on the website.