A1QA Blog

QA Core for Executives

Assuring Quality of Mobile App. Stage 2: Test Planning

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.

Documentation type

What does it specify? When shall we use it?

Example

 

Acceptance Sheet

Modules and features of the app that should be tested In short-term projects with simple business logics  

Website login form

 

 Test Survey

 

Specific checks of a single feature

 

In medium-sized projects with clear business logics

Website login form:

  • Correct data input
  • Wrong user’s name input
  • Wrong password input, etc.
 

 Test Cases

 

A sequence of steps to test the correctness of  functionality behavior

 

In huge and long-lasting projects that require deep in-field expertise from the testers

Website login form:

  • Open the login form
  • Enter the following user’s name: test1
  • Enter the following password: test1
  • Press Enter button

The expected result: the users get to the Home page.

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!

Share this: