I remember when I purchased my first phone in 1996.
I was studying for my A Levels at college in London.
In those days a phone was just that, a phone!
There was nothing fancy about a mobile phone apart from the fact you called people and sent the occasional text/sms. Even then there was a limit of 160 characters…I think!
Not many people actually had a cell phone.
How the world has changed since then.
Anyway.
With the introduction of smartphones your phone is essentially a personal computer in your pocket.
That means mobile phones are much more complicated and allow you to do all kinds of things.
In fact you can run your entire life and business from the palm of your hands.
In this article I will give you some generic test cases for a mobile application as well as considerations when testing mobile apps.
Table of Contents
How do you write test cases for a mobile app?
Consider the type of application you are testing, consider the end user, operating system, the device and don’t forget security, performance and infrastructure testing.
Context and Scope
Software testing for a mobile application is almost, if not the same process as testing any kind of software application.
There are however a number of key considerations you need to make for your mobile application which I’ll mention below.
Scope of this article
Because there are dozens and dozens of mobile applications, I like to really make it clear what we are testing as part of this article.
Let us use the example of a banking application where a user can login, carry out transactions and successfully log out.
Key Considerations Mobile App Testing
You may want to think about some of the considerations mentioned below when building a test scenario for your test plan.
Type of Application and It’s Uses
Is the application used for gaming, business, entertainment or banking as an example.
If for example the application is useful banking, there may be more security features incorporated that may need additional testing.
A gaming app may take longer to load.
An application that connects to the cloud may require internet connectivity as a prerequisite.
Operating Systems
Is your mobile application developed for Apple iOS, android or a custom bespoke operating system?
Depending on how each operating system behaves will determine how you test your application.
This may be a combination of functional and user experience behaviour.
Mobile Device
The above point ties nicely in with this point.
Certain mobile devices only run certain kinds of operating systems so the tests will need to be designed accordingly.
Even though both are quite intuitive, Android apps have a slightly different UI to Apple IOS.
Also keep in mind that “mobile applications” are not always for your phone.
They also encompass tablets such as an iPad, so this is something you also need to consider when developing your test cases.
Screen resolution is a good example of this.
Minimum Requirements for Performance
Some mobile applications are resource heavy than others.
Mobile games as well as video editing tools are a good example of this.
Don’t forget to test this as part of your testing strategy.
Security
When using any kind of banking application, security has to be of the utmost importance.
You should conduct functional testing on all aspects of security features.
For example, logging in via the mobile keyboard input, fingerprint ID, face ID or a combination of all of the above.
Test Scenarios and User Journeys
In terms of coming up with test cases, my thought process is firstly to come up with the end to end user journeys and then breaking these down into functional/non-functional areas.
From here we can then write the test cases.
Below is a high level overview of how I see this..
Install Mobile application
- Complete installation
- Pause/Resume installation
Mobile Application is installed correctly Icon is present on screen
- You should be able to confirm the application has been installed properly.
Open Application for first time
- Is it loading correctly?
Performance of mobile app when opened for the first time.
- Is it fast or slow (depends on the type of app, e.g. game may take longer)?
- Is the performance within the accepted tolerance SLA/levels?
UI Verification
- Does the User Interface of the application look as per the requirements specification?
- Check UI Layout
- Check typefaces;
- Are the correct typefaces used?
- Are the typeface size(s) correct.
- Are typeface colours correct?
- Check Colours
- Check branding
Authentication
- First Time Authentication success
- Takes the user to the main screen.
- First Time Authentication failure
- What happens after “x” number of failed logins?
- Successive Authentication
- What methods will the device allow? Face ID, Password, fingerprint, two factor authentication or something else?
- Account Unavailability
- What happens when a user’s account is unavailable? This may be due to no connectivity or account suspension?
Visual Check of Pages
- Navigate through screens and check they render correctly
Transactions
- Initiate and complete and end to end transaction and ensure it works
- Negatively test transactions.
Performance Testing
- How does the app perform when under heavy user load? For example thousands of concurrent users? Focus is on the hosting infrastructure testing.
- How does the application perform when under heavy load locally. The focus here is the device and local resources.
Connection Type Test
- WiFi
- Data Connection
User Experience Tests
- Is the mobile application intuitive?
- How easy/difficult is it to carry out a particular task?
Test Cases for a Mobile Application – Banking Domain Example
Test case ID | Test case description | Precondition | Expected result | post condition |
---|---|---|---|---|
TC-0001 | Verify application install commences. Purpose of test: To verify that the application starts to install (we are not testing the entire installation process) | Must have connectivity to download app source file. | The application will start to install. | |
TC-0002 | Verify application can be paused | The application pauses | ||
TC-0003 | Verify application can be resumed. Note:The purpose is to check that the application can continue from where it left off and doesn’t need to restart the install. | The application resumes the installation process. | ||
TC-0004 | Verify application has been installed successfully on the device. Note: this is prior to you running the application just to check whether or not the application installed successfully. Not only is this a functional test, but something that would be tested as part of user acceptance testing (UAT). | The application would install on the user’s device. The applications icon will now display on the screen confirming the application has been installed. | ||
TC-0005 | Verify application icon design is as per the user specifications. | The application icon is as per the design specifications. | ||
TC-0006 | Verify mobile application opens and loads successfully. Note:If your application has been developed from multiple operating systems and devices, then this test should be repeated for each variation to ensure the application behaves as expected. | The application will load successfully as expected. | ||
TC-0007 | Performance Testing: Verify the application loads within the specified time tolerances. Note: The time taken will depend on your requirements or any service level agreements you may have as part of the project. | The application loads successfully within the expected timeframes / tolerance levels. | ||
TC-0008 | User’s First Time AuthenticationVerify the application takes the user to the login page Note: logging into the application may take one or several forms, for example fingerprint ID, face ID or password input via the keyboard. This test presents the first time a user uses the application. Once the login has been validated, the application may not require the user to enter these credentials again. | It is assumed that the account has already been registered at the bank. A banking user cannot register the account using the mobile banking app. | The user is taken to the first page which is the login screen. | |
TC-0009 | Authentication ScreenVerify the login page displays credential fields | User Login page displays; username fieldpassword fieldSubmit passwordForgot username/password hyperlink text | ||
TC-0010 | Authentication (Security Test):User enters incorrect credentials. Note: I’m not going to talk about all possible security testing scenarios. You can check out test cases for a login page which gives you a lot of detailed info. | User authentication fails. Multiple authentication failures will require the user to request a reset from their banking institution. | ||
TC-0011 | Authentication (Security Test):Verify user is able to enter the correct user credentials | User is allowed access and is navigated to the preceding screen. | ||
TC-0012 | Verify face ID recognises user Note: This is an optional test case depending on the end user’s device. The test case will need to include steps on how to set up Face ID for the application for the device. | The user will have already logged into the mobile application. | The mobile app recognises credentials and the user is successfully authenticated. | |
TC-0013 | Verify face ID does not recognise user Note: This is an optional test case depending on the end user’s device. | Authentication failure. System does not allow the user to proceed. | ||
TC-0014 | Verify fingerprint ID recognises user Note: This is an optional test case depending on the end user’s device. | The mobile app recognises credentials and the user is successfully authenticated. | ||
TC-0015 | Verify fingerprint ID does not recognise user Note: This is an optional test case depending on the end user’s device. | Authentication failure. System does not allow the user to proceed. | ||
TC-0016 | Account Unavailability Verify account cannot be accessed when there is no connectivity. | Account cannot login. User is presented with a meaningful error message. | ||
TC-0017 | Account Security – Automatic Lockout Verify app logs out when not using the app. Note: THis can be as a result of switching to another mobile app, answering a call or the phone timing out. | The mobile banking app logs the user out. A meaningful error message is displayed on screen | ||
TC-0018 | User Interface Verification Verify the layout of each screen is as per the design specification. Note: You may want to create a separate test case per screen or include it within a test case. Either way, ensure you have full coverage. | The UI layout is as per the design specification. | ||
TC-0019 | User Interface Verification – Typeface Verify correct typeface(s) have been used. Navigate to each screen or a handful to verify this. | Each screen uses the correct typeface(s). | ||
TC-0020 | User Interface Verification – Typeface Size Verify the typeface size(s) are as per specification. | The typeface sizes are as per the design specification. | ||
TC-0021 | User Interface Verification – Typeface Colour Verify the typeface colours(s) are as per specification. | The typeface colours are as per the design specification. | ||
TC-0022 | User Interface Verification – Branding Verify the UI branding is as per the specification.. | The branding items are on point. For example, the organisation logo is displayed in the correct location. | ||
TC-0023 | Functional Testing – Check balance Verify the application displays account balance. Note: refer to the requirements on how to do this. | The application displays the account balance to the user. | ||
TC-0024 | Functional Testing – Create new recipient Verify mobile app allows you to create a new recipient.. | The user is able to successfully create a new recipient. | ||
TC-0025 | Functional Testing – Make a payment Verify mobile app allows you to make a payment. Note: refer to the requirements on how to do this. You should add more detail to this test case on the user’s journey through the system. | The user is able to successfully make a payment. | ||
TC-0026 | Functional Testing – Make a large payment that the system does not accept. Verify mobile app allows you to make a large payment BUT the system overrides and suspends this payment as a fraud risk. Note: Even after the user has been verified via their phone sms or 2Fa code, the system still overrides and suspends the payment. UK Banks like Halifax do this so this is a valid test case. | Payment is not processed. User is locked out of Application and error messages displayed. User is required to go into the bank to unsuspend and prove payment. | ||
TC-0027 | Functional Testing – Transfer Money Verify app allows you to transfer money to an account. Note: refer to the requirements on how to do this. You may want to try national and international payments. | The app allows the user to transfer money. | ||
TC-0028 | Functional Testing – Setup a recurring payment Verify the app allows the user to make a recurring payment. Note: You should go through the requirements to understand the way to do this. This would be something along the lines of Direct Debit payments and standing orders. | System allows user to make a recurring payment. | ||
TC-0029 | Functional Testing – Check Standard Orders and Direct Debits Verify user is able to track their DD’s and SO’s. | The user is able to see their DD;’s and SO’s. |
What Types of Mobile Applications are there?
You might remember those annoying ads where the caption was “there’s an app for that”!
Well, it’s kind of true.
There is literally a mobile application for almost anything
Whether it’s for business, a hotel booking system, banking or for fun, you can guarantee that you’ll find something that you’re looking for.
Future Proofing your Testing Efforts
One of the many roles of a QA Tester (or anyone involved in test design) is to continuously work on improving your processes.
I have always found that the overwhelming majority of manual test cases that I have worked on can be used again.
Creating a Regression Testing Suite
Most of my career has focussed on manual testing and I have built many regression test packs.
We have an article that discusses this topic in more detail.
Employing Automation Testing
Having a regression test pack is good.
However, if your mobile web app is a long term project then you may want to employ automated tests.
The downside with automation testing is that it can be quite time consuming and expensive.
However, if this is a financially viable option then there is an opportunity to save a great deal of time and effort.
If your app requires continuous testing as a result of constant updates then you may want to consider this option.
Wrap Up
Mobile application testing can be quite a complicated undertaking.
As I mentioned above, whether it’s a game, a utility or a banking mobile application, consider it like any other web app or software you have tested in the past.
Ensure you adopt good best practices, governance and have plenty of fun.