Roadmap for a Stress-Free Mobile App Testing

13 Jan 2015
Alt text. Roadmap for a Stress Free Mobile App Testing. Lemberg Solutions

Just started your journey in the app business and don`t know if you need mobile application testing?

Looking to have your app tested, but don’t know where to start?

Testing your app is a complete headache?

Searching for a reliable support partner for your software and want to get a clear understanding of the Quality Assurance aspect?

We`ve been facing lots of these questions in our day-to-day work as mobile app development professionals for years. Here is a simple guide for you, based on our own experience, for a stress-free application testing and your app`s clockwork performance.

We are well aware how much stellar performance is important for mobile app success on different stages of its life cycle. Having been a tech partner for over 8 years, we are confident that the right approach when dealing with the new mobile app project is to test it first, to have a clear understanding of any possible problems with it. This helps to manage expectations on both sides. Whether it’s a case of QA for its own sake, or software audit before maintenance, there’s Quality Assurance to be carried out. 

You probably need quality testing services if:

  1. until now, you were your own tester, but would like to save your time, or
  2. you could use a second opinion on the quality level of your app
  3. your app is getting bigger, and it’s getting difficult to test the app in the same couple of hours
  4. you want to test a particular area of the app, but would rather not spend time on getting familiar with it
  5. your checklist consists of 100 test cases, and these tests should be run on a range of devices, which makes QA time consuming and complicated.
  6. you don’t have any feedback to your app, and would appreciate an expert opinion on how it performs, how it is compliant with the latest UI guidelines, etc.
  7. You are looking for UI/UX porting, OS upgrade, or making your app compatible with the newest devices. SEE: Mobile Application Porting.

At Lemberg, we provide mobile application testing services/ Quality Assurance (QA) both to apps we develop as a part of the development process, and as a separate service. The second option presupposes some preparation on the client’s side. 

What is needed for a start?

When a Customer reaches out with a request, the Quality Assurance team will certainly need some background information for a start:

What? Why?
Brief overview of the App This is needed for having a general understanding of the system, what parts it consists of. So we have understanding of a test environment that should be created.
App’s Specification More details will help us understand standard app behavior and what is deviation from it. These could also be user stories.
UI Specification Wireframes with comments and designs of app’s views.
List of your concerns about the app You may have concerns about particular areas of your application. And we can focus more on them if you tell us what they are.
The actual Application APK for Android or IPA files for iOS
Focus Of QA Security, performance, UI, implementation of all user stories - what is your first priority?
Device List Often customers know their audience and target devices that should be definitely supported. Sometimes, this information differs from what is popular on the market.

Lemberg is flexible when it comes to providing mobile application testing services. We don’t need a lot of data from you and can work with any project materials you have. Also, we can offer separate QA activities like checking the UI only, or just testing communication with the server, data migration, etc.

Scenarios

The typical testing scenarios for general Quality Assurance or specific Quality Assurance go like this: 

Scenario Input materials
A Lot of documentation to perform solid QA (*RARE CASE)
B The app only (**MOST COMMON CASE)
C Customer’s concerns
D Visual designs
E Customer’s Test Plan
F List of features that should be checked
G Source Code

The only asset that is required for EVERY testing is the actual app.

Scenario A

What is required? - General QA

Customer provides us with:

  • UI/UX specification
  • User Stories
  • Server API specification

What do we do:

That could be only one of the specs listed above. Lemberg will prepare a checklist based on it. Other details can be discussed with the Customer.

QA based on UI/UX specification is the simplest. If the project doesn’t have any UI/UX specification, Lemberg considers that OS UI guidelines should be standard UI requirements. And Lemberg’s QA engineers will provide their feedback on how the mobile platform’s UI guidelines have been met.

A list of User Stories that in detail describes what the app should do. This list will help us find out everything about the app.

Server API specification will tell us about how the app should communicate with the server. Just visual observations may not show you all the picture, while traffic analysis can tell you the truth about network interaction with your app.

A list of answers we may obtain about app’s network communication:

  • is it carried out as expected?
  • does the app communicate too much/too often?
  • how does it behave in cases of internet instability?
  • what does it do if updates are available on the backend?

Scenario B

What is required? - General QA.

Customer provides us with: - Nothing

What do we do:

Lemberg can check your mobile application without any provided specification just based on common sense.

  • General feedback will be provided on the discovered issues.
  • It will be based on the different Guidelines and features of the OSs.
  • These could be just usability thoughts, feeling of performance, brief security checks, user experience, impressions of how the app performs in different states of internet availability.

Scenario C

What is required? - General QA.

Customer provides us with: - Concerns.

What do we do:

Lemberg is provided with customer’s list of concerns only.

The customer may know that the app has certain issues, for instance, with memory while processing big images, or with app’s offline work, or problems with server communication.

In this case, the Customer can save time if he provides us with this information. Lemberg will focus first of all on QA of these specific areas.

Scenario D

What is required? - Check app’s UI or general QA.

Customer provides us with: Visual designs only.

What do we do:

The task is only to check the UI, compare original designs with the actual implementation.

Scenario E

What is required? - General QA.

Customer provides us with - Ready Test Plan.

What do we do:

Lemberg is provided with customer’s test plan or any form of a checklist.

Based on this, Lemberg creates its own version of a checklist.

A checklist can and will save lot of testing time.

Scenario F

What is required? - General QA.

Customer provides us with: A list of features that should be checked

What do we do:

Lemberg is provided with a list of features. QA of other application features will be skipped.

Availability of a checklist can save lot of time. In case checklist is not available, Lemberg will create it.

Scenario G

What is required?

  • Check sources quality
  • Identify possible issues based on code review

Customer provides us with: source code.

What we do:

Lemberg is provided with application’s source code. In this case, we can give our feedback on the source code quality.

Summary

To put it in a nutshell, if you have made up your mind about mobile application testing, follow these simple steps:

  1. Set up your priorities and choose the best testing scenario.
  2. Decide what should be treated as normal application behaviour versus what is a bug.
  3. Have your mobile application tested.
  4. Receive your software quality report.

That’s it, as simple as that.

Questions or comments? Please, do add them in the comment section below. We would love to hear your thoughts!

SEE ALSO: