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.
|What does it specify?||When shall we use it?||
|Modules and features of the app that should be tested||In short-term projects with simple business logics||
Website login form
Specific checks of a single feature
In medium-sized projects with clear business logics
|Website login form:
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:
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
- 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.